Google recently published Beyond Zero: Enterprise Security for the AI Era, alongside a blog post introducing it to the wider world. It’s positioned as the successor to BeyondCorp, and the core idea is a big one: shrink the trust boundary from the application down to the individual action on an individual resource. Instead of asking “can this identity access the finance system”, you ask “can this identity export these fifty thousand records, right now, given everything we know about them”. This is what we wanted all along and was the key principle of zero trust, but the reality is we struggled when the rubber hit the road: data tagging was hard, people complained, and many zero trust programs got bogged down in minutiae before we made it to the finish line.
It’s worth being clear about what this paper is and isn’t though. It’s aspirational. Google says deployments are internal-only, the components aren’t all built, and more papers are coming. This is the same playbook as 2014: publish the vision, describe the architecture at a high level, and encourage the industry to build towards it collaboratively. The original BeyondCorp paper came out in late 2014, and it took years before you could buy anything resembling it. The early solutions were charmingly scrappy. Duo Beyond in 2017 was not far off a handful of Python scripts sitting on infrastructure you managed yourself, reading from MDM APIs. It took until roughly 2020 before the mainstream had real options. COVID and remote work were the kick we needed to get zero trust done properly and now AI has finally given the industry the kick it needs to finish what we started all those years ago.
When Duo launched their early zero trust products, they literally marketed them as “BeyondCorp for the rest of us”. That framing existed because everyone knew the gap between Google’s whitepaper and a normal enterprise was enormous. The last time someone promised “for the rest of us”, it took vendors about five years to deliver and ten to turn it into a commodity. This post is about why I think the gap will close faster this time, what you can glue together today, and what extra stuff you need to deal with when you aren’t Google.
You Aren’t Google
Reading the paper, the architecture makes total sense. Then you look at your own environment and it starts to fall apart.
You don’t have one auth system, you have a messy web of vendor relationships. A ZTNA product here, SAML and OIDC apps there, a couple of legacy tools held together with SCIM and hope. Some of it integrates cleanly, some of it doesn’t integrate at all. On the AI front, you’re fielding constant pressure from leadership and users to connect AI tools to everything, while dealing with confused deputy problems, standing OAuth grants, and standards that aren’t up to scratch yet. I’ve written before about how AI tools are eroding zero trust foundations and that’s really just the tip of the iceberg.
You aren’t Google and don’t try to be. The reality is this is a problem we’re all facing and it’s not one you’ll be able to solve alone. With prior zero trust implementations you could hack together something, but now to get to a good state it’s something that involves the industry as a whole, security and SaaS vendors alike.
The SaaS Enforcement Problem
Google can shrink the trust boundary to individual actions because Google owns most of its applications end to end. They control the code that serves the document, so they can put an authorization check on the document. You rent your applications. Resource-level and action-level authorization inside Salesforce, Workday, or NetSuite only works if the SaaS vendor lets an external policy decision point into the request path, and almost none of them do. Google knows this. It’s their third industry ask in the paper: make external, enterprise-operated policy evaluation a first-class citizen in all SaaS services.
In the BeyondCorp era, everything was HTTP, so you could put an identity-aware proxy in front of any application and enforce policy there without the app’s cooperation. That proxy trick is what made the whole ecosystem possible. Beyond Zero has no equivalent. The action being authorized happens inside the application, past the point where a proxy can see anything meaningful. The closest thing we have to a chokepoint today is the agentic access path: MCP gateways and API gateways can mediate what an agent does at the action level. The way I explain this is that OAuth has limitations: with Gmail you can only limit an agent down to read access, which means it can read all your mail. You can’t limit it down to just reading these 5 specific emails, without Gmail implementing a feature to do so.
What’s Different This Time
It’s too early to tell if this cycle runs faster than the original zero trust one. There are some things that make it go faster and some things that make it go slower.
On The Faster Side
First, the hard integration work is already done. In 2017, the actual job of building zero trust was gluing your MDM to your IdP to your applications, and it was miserable when you had three different MDMs. Device posture APIs barely existed, SCIM support was patchy, and every integration was bespoke. Today that connective tissue is table stakes. Device trust flows into your IdP natively, HR data flows into identity via SCIM, everything has webhooks and APIs. Most of the foundations are there, but of course it’s not perfect by any means.
Second, the standards groundwork is further along than it was last time. The Shared Signals Framework and CAEP give us a standard way to push risk signals between systems and act on them mid-session. Microsoft has continuous access evaluation in Entra. The MCP authorization spec is evolving quickly, Okta is working on cross-app access for agents, and NIST has kicked off an agent security effort that the paper explicitly nods to. None of these are finished, but in 2014 the equivalent list was empty beyond “you should probably do SSO and here’s five ways you can do it”.
Third, AI has collapsed the build time. The early BeyondCorp adopters spent years writing glue code. That glue now gets written in an afternoon. I’d bet money there’s already a handful of Beyond Zero startups in stealth, and the big vendors are already building in this direction. The time from whitepaper to usable product should be a fraction of what it was thanks to AI.
On The Slower Side
The difference between BeyondCorp and Beyond Zero is quite stark. With BeyondCorp-like implementations all you had to do was get your device information from an MDM/EDR tool, implement a policy enforcement point at your IdP, and build some custom checking logic. It took vendors so long to build it because they had to navigate working with 50 different IT and security vendors to make their tools work for every combination, but you could easily build a hacky version yourself. In the Beyond Zero world, it’s not as easy to hack things together because the problem isn’t with data, it’s with the technical specs, and the vendor implementations of those specs. This means we need the specs to adapt, and then we need vendors to collectively and rapidly adopt those new specs.
This means even if your core vendors do support things fast, you’ll still be stuck with that weird events SaaS tool built by a 5-person team that doesn’t support it for years to come. It means you’re going to have to deal with an increasingly fragmented ecosystem unless the AuthZ vendors like WorkOS and Auth0 make it incredibly easy for people on the implementation end. You can do things without vendor support, but you’ll be inherently limited by what vendors provide and it’ll mean a world of intercepting requests and proxies which most of us would like to avoid.
Zero Trust Isn’t Dead
None of this means you should stop your zero trust rollout and wait for the shiny new thing.
The original model has cracks. AI tools bridge unmanaged devices into your highest tier applications. Standing OAuth grants bypass your conditional access policies. Ambient authority means agents inherit the full, over-provisioned permissions of their humans. You will hit these issues, and probably new ones, as agentic tooling keeps evolving. But cracked isn’t broken. Device posture, tiered application access, and phishing-resistant MFA still stop the overwhelming majority of real-world attacks, which remain depressingly credential-shaped.
More importantly, zero trust is mostly a prerequisite for Beyond Zero, not a competitor to it. The paper’s architecture sits (mostly) on top of BeyondCorp’s foundational identity. If you don’t have strong device identity, a well-integrated IdP, and decent signal collection today, you have nothing to build the next layer on. If you’re mid-journey, keep going.
Where The Paper Hand-Waves
Before the practical advice, some honesty about the paper itself, because there are a few places where it glosses over problems that will hit the rest of us much harder than they hit Google.
Non-deterministic authorization meets your auditors. An LLM making access decisions is, by nature, not fully deterministic. Your SOC 2 auditor wants to see a policy and evidence it was enforced. Your employees are almost certainly using AI, but that AI is funnelled through a human-shaped hole and the auditors can’t tell it apart. When you start having uniquely agentic identities, it’s going to become problematic if those identities are not enforced to the same standards as humans, which means manual human approvals, painful UARs and all the fun stuff auditors bring.
False positives causing employee friction. When the reasoning engine wrongly contains a legitimate user, someone has to review it. Google can staff a containment-review queue around the clock. A three-person security team cannot. If your dynamic layer denies access at machine speed, it generates problems for your security team at machine speed too.
Intent is messy. A lot of people are talking about Intent at the moment. The idea is that if a person in sales suddenly tries to access customer content in a production database, that’s a weird outlier and may cause containment. The reality is that’s just how companies work; they are inherently messy outside of the structured megaorgs. People’s roles change, people get pulled into incidents and one-offs, and it makes intent impossibly hard when you are a small messy company.
The economics of LLMs. Google explains two models of evaluation: policy checks and inference. Google can run a good chunk of their stuff through GCP-backed hardware running Gemini; for the rest of us, we’ll be waiting until the open-weight models get much more efficient before running all of our logs through them, which means we’re limited to policy checks, which are more prone to false positives.
The hard work required. You could hack your way around certain things before, you can’t in this model. You need every line of data classified, you need every tool in your IdP, you need every piece of infrastructure managed, every contractor accounted for on a device. You could gloss over some of these issues before, but no longer.
What You Can Glue Together Today
The four components in the paper map to tools you already own, which makes Beyond Zero more approachable than it looks.
- The Enterprise Security World Model is your IdP, your HRIS, and your data classification labels. The paper dresses it up in self-driving car language, but it boils down to “know who people are, what they’re working on, and what your data is”.
- Event Intake is your SIEM or data lake. You’re already collecting most of these signals, you’re just using them for after-the-fact investigation instead of feeding them back into access decisions.
- Challenge Infrastructure is the step-up auth you already have. Security key touch, manager approval flows, justification prompts. The new part is triggering them dynamically from policy rather than hardcoding them per app.
- The Reasoning Engine is the one new component, and today’s closest analogue is something like SSF-backed policy enforcement points: signals in, enrichment, decision, action out. With more AI of course.
Finish data classification. Unsexy, I know. Most companies started this project once and quietly abandoned it. But the entire model runs on knowing what your data is. If you do one thing from this post, restart that programme, and this time use AI to do the labelling grunt work that killed it last time.
Enrich your IdP with real-world context. Get HR attributes, team structure, and work assignment data flowing into your identity provider as usable attributes. The paper’s big insight is that pre-computed context is what makes fast decisions possible. Attribute-based access control with good attributes gets you surprisingly far.
Wire risk signals into session decisions. Where your vendors support SSF/CAEP or continuous access evaluation, turn it on. EDR detects something, session gets revoked or challenged mid-flight. This is the “in-the-moment evaluation” pattern from the paper, built from parts you can buy now.
Put a gateway in front of agentic access. An MCP or API gateway is the one place you can enforce action-level policy without the SaaS vendor’s cooperation. Log every tool call with the controlling human and task attached. This is also where you mitigate the remote control and ambient authority problems I’ve written about before. Eventually I still believe this will get moved up to the application layer as a new identity control, but proxies are what we have today, so let’s live with proxies for a while as we’ve got more important issues to deal with right now.
Build a poor-man’s reasoning engine. Start with async, not inline policy evaluations. A scheduled job that reviews yesterday’s access against work context and flags anomalies is a slow-motion version of the paper’s slow inference path, and it’ll teach you what your false positive rate looks like before you ever put anything in the hot path. If you are going down the AI-powered SOC route you’re probably starting to think about this already.
Pressure your vendors. Ask your SaaS vendors when they’ll support external policy decision points. Ask your identity vendor about agent identity and CAEP support. The BeyondCorp market existed because customers kept asking for it by name and they all asked for the same thing. Don’t go and ask Okta for 10 different things please, or they’ll build 10 different things that don’t work together and people like me will have to suffer the consequences.
What Vendors Should Be Building
The zero trust market has stalled. Everyone offers roughly the same identity-aware proxy with roughly the same posture checks, differentiation collapsed years ago, and the category has been coasting on renewals. Beyond Zero should light a fire under you, because agentic enterprises are hitting these problems right now. I’m not likely to churn off my existing vendor immediately, but if they aren’t giving me a plan on how they are going to adapt to this, it’s going to be a conversation that gets more pressing over time.
The opportunity is not building another proxy, everyone has already built MCP and LLM proxies galore. I think there are largely two broad opportunities ahead.
Reasoning Engine - This is basically the classic zero trust “policy enforcement point” but for AI. Ingesting the customer’s identity, HR, classification, behavioural data, and AI registries, and making them usable for access decisions. The identity titans will bolt this on eventually, but they’ll do it slowly and in their own walled gardens.
Making The Rest Easy - Data tagging is hard, working out intent is hard, fine-tuning decision policies is hard. There’s a good opportunity to make these things easier for people with Beyond Zero as the end goal. You can only get so far with a reasoning engine and a chrome extension, just like with zero trust we had pop out policy enforcement points, then built them natively into the IDP I suspect the same thing will happen here.
I think this is an area where the existing players have an unfair advantage and it’s going to be big vendors competing with each other. I can’t see 100s of Beyond Zero-like startups popping up, but there’s an opportunity for a few. I think building on top of the big identity platforms like Kolide did is probably more likely than an “AI-Native ZScaler” but it wouldn’t surprise me if a few tried, and I think they should. The existing vendors have become stagnant in terms of feature delivery. They need some competition to actually encourage them to build systems that work in AI organisations because few are doing that right now.
And if you’re an AI tool vendor: the enterprises adopting your agents are going to demand attributable identity, introspection APIs, and external policy hooks. Building them before your competitors do is the cheapest differentiation you’ll ever buy.
Looking Forward
In 2017, gluing zero trust together yourself felt early, and it was. But the people who did it were the ones who understood the model deeply enough to evaluate the products when they finally arrived, and who had the foundations in place to actually deploy them. The same window just opened again. Beyond Zero the practice, or at least a rough approximation of it, is something you can start assembling from parts this quarter. Read the paper, finish your classification programme, gateway your agents, and start getting signals you can use to make delayed decisions with for when the vendors catch up.
I also can’t help but think what comes beyond Beyond Zero. Naming something Beyond Corp was probably a mistake, just like we’re going to have next-next gen firewalls, we’ll have beyond-beyond zero next.