Three Layers, One Guarantee: What Beyond Zero Actually Changes for AI Agents

In 2014, Rory Ward and Betsy Beyer at Google described an approach to enterprise security that would come to be known as BeyondCorp. Their argument was that the “castle and moat” model, thick walls and a trusted interior, no longer matched how people worked. Once employees carried laptops through airports and coffee shops, the perimeter stopped being a place and the interior stopped being safe by default. Google’s answer was to move trust to the device and the user, verified on every request, regardless of network. The paper closes with a line worth remembering: the authors state they intend to publish follow-up articles explaining why and how Google made the shift, with the explicit goal of encouraging other enterprises to do the same.

On July 27, Google published Beyond Zero, written by Heather Adkins and Archana Ramamoorthy. The post opens by linking directly back to the 2014 paper: this is presented, deliberately, as that sequel.

Beyond Zero is not simply “AI changes everything” repackaged. The claim is narrower and more useful: the layer where security guarantees actually live has to move again, and it is worth being precise about where.

What BeyondCorp actually did

BeyondCorp’s fix was still an application-level decision. A device and a user were authorized to reach codereview.corp.google.com, or they were not. What happened once inside that application was somebody else’s problem.

That gap did not stop the idea from spreading. NIST published its own formal Zero Trust Architecture standard, SP 800-207, in 2020, and the following year a presidential executive order directed every US federal agency to adopt it, citing that same document. The same requirement shows up on this side of the Atlantic too: NIS2’s Article 21 mandates access control built on least privilege as one of the baseline measures every essential and important entity must have, and zero trust architecture is the operating model built to deliver exactly that. What started as one company’s internal migration became, within less than a decade, the assumed baseline on two continents for how a serious enterprise talks about network access. It is exactly that kind of migration, from one company’s fix to everyone’s baseline, that Beyond Zero is positioned to repeat.

Beyond Zero, precisely

It is worth stating plainly what Beyond Zero is, because the framing that spreads fastest online, “zero trust for AI agents,” undersells it. Beyond Zero moves authorization from the application down to the individual action on a specific resource, decided at the moment it happens, for humans and agents alike. Google names five principles:

• Resource and action-based decisions. Authorization is evaluated per action on a specific resource, not per application, applied uniformly across front-end interfaces, APIs, and MCP.
• Blended static and dynamic security. Granular static policy is paired with dynamic controls that engage during high-risk or complex scenarios.
• Automatically enriched context. Every decision draws on context about the action, the data involved, and what mitigations are available.
• Automated investigation. Risk signals can trigger their own security investigation, autonomously.
• Challenges and containment. Policies can trigger real-time verification challenges or containment measures on demand.

The motivating case is agents, since agents act roughly ten times faster than people and the old model of periodic, human-paced review cannot keep up. But the architecture itself is not agent-only. It is what zero trust looks like once you stop trusting the room and start having to justify every action taken in it, whoever or whatever is taking it.

The convergence

Google is not the only one making this argument. A previous post on this blog examined how a Bedrock agent is, underneath the marketing, an execution role in a costume, and how the industry has started calling the fix Least Agency: the same principle of least privilege, applied to something that can be prompted into acting on someone’s behalf. Around the same time, Google DeepMind published its own AI Control Roadmap, built on an assumption worth sitting with: that model alignment, the layer where an agent is trained to want the right thing, should be treated as something that can fail. DeepMind’s own language is that they design for “assurance even if alignment is imperfect,” and they build their internal controls by treating capable agents as potential insider threats, not as trusted colleagues that happen to be software.

Three organizations, working on different problems, converged on the same structure within months of each other: treat the model’s good behavior as unreliable, and build a hard boundary around it that does not depend on the model behaving.

Three layers, one guarantee

Put the pieces together and securing an agent turns out to have three layers, and they do not carry the same weight.

The first is the instructions layer: whatever the agent has been told, formally or in a system prompt, about what it should and should not do. This layer is improving, and it deserves the investment going into it. It is also, by the admission of the people building the models, not something to rely on alone. An agent reading a document as part of its job cannot always tell the difference between the document’s content and an instruction embedded inside it. Guardrails narrow the failure, they do not close it, and the organizations doing the most serious work on alignment are explicit that they are not promising it will hold every time.

The second is the permissions layer: not what the agent was told to do, but what it is actually capable of reaching, given the identity and role it runs under. A permission either allows an action or it does not, and knowing the full graph of what a role can touch reveals the true boundary regardless of what the agent believes its job is. The second layer is the only one where a guarantee is possible at all.

The third is the runtime layer: watching what the agent is doing as it does it, and catching or containing the bad case. This is real, and Beyond Zero’s dynamic controls and DeepMind’s live supervisors both live here. It is also, structurally, the layer that arrives last. We wrote about this in detail a few weeks ago: cloud providers themselves state their detection is not real time, GuardDuty batches its own findings on a six-hour cycle by default, and researchers have shown a terabyte of data can leave a compromised account in under four minutes, faster than the first log entry documenting the theft is even delivered. If the question is “what is happening right now,” in AI’s case especially, it is very often already too late to be asking it.

Where PanIAM lives

PanIAM is built for the second layer. Every agent is folded into its execution role, and PanIAM computes the full reach of that role ahead of time: the buckets it can read, the tables it can write, the roles it can go on to assume, before any of it happens. The granularity is set by the cloud provider, not by us: whatever distinction a provider’s permission model can express, the graph already expresses. As AWS, Google Cloud, or Azure add finer distinctions to what an agent’s role can do, PanIAM is built to pick them up quickly, because the model was never bounded by what we imagined would matter. It is bounded by what the provider lets you configure, which is the correct boundary to be bound by.

The other two layers matter, and both are getting serious investment from people well positioned to do that work. This is the layer where what could happen is answerable in advance, rather than something discovered after it already has.

The layer that’s still just text

One more thing worth saying, because it points at where this goes next rather than where it is. Today, an agent’s instructions are mostly prose: a paragraph in a console telling it how to behave. That is already starting to change. AWS previewed Policy for Bedrock AgentCore at re:Invent in December 2025 and made it generally available in March 2026: agent behavior, expressed in natural language, compiled into Cedar, AWS’s own policy language, and enforced deterministically, outside the model’s own reasoning loop. It governs which tools an agent can call and how, a real boundary rather than a suggestion. It sits next to, not instead of, the execution role and the resource-level permissions that role holds. We are watching that shift closely and building toward a graph that can represent both: the tool-level policy an agent is meant to follow, and the resource-level permission that decides what actually happens if it doesn’t.

Keeping that distinction sharp, what an agent is asked to do and what it is actually able to do, is the whole discipline in one sentence, and it was true well before anyone called it Beyond Zero. What changes when Google puts a name and an architecture behind it is not the idea. It is what happens next: a named reference architecture is what NIST turns into a standard, what a directive or an executive order turns into a legal requirement, and what an auditor on either continent eventually asks a company to prove it has. BeyondCorp took less than a decade to go from one company’s migration to everyone’s baseline. The distinction between what an agent is told and what it can actually do is about to make the same trip.