Reading Anthropic's zero trust guide for agents

Anthropic's Zero Trust for AI Agents came out in May 2026 as a blog post with a PDF guide behind it. Parts I and II are written for security leaders and cover threats and compliance. Parts III to V are for architects and engineers: capability tables in three maturity tiers, an eight-phase workflow for putting an agent into production, and a section on running security operations against attackers who are themselves using models. It is the most specific thing a model vendor has published on the subject, and it reads like it was written by people who have had to defend real deployments.

The zero trust content is the standard version. Three principles, taken from NIST SP 800-207: never trust and always verify, assume breach, and least privilege. The guide adds two terms for agents. Blast radius is the damage an agent could do if it went wrong. An agent with read-only access to one database has a small one, an agent with admin rights on cloud infrastructure has an enormous one. Least agency, a term the guide attributes to OWASP, takes least privilege one step further and constrains what each tool can do, how often, and where. The example given is a database tool that gets read-only queries and an email summariser that gets no send or delete rights.

The test that does the work

Page four has the sentence that organises everything after it: "does this make the attack impossible, or just tedious?"

The argument is short. An agentic attacker has, in the guide's words, "unlimited patience and near-zero per-attempt cost." Rate limits, extra pivot hops, non-standard ports and SMS-based multi-factor authentication all work by adding friction, and friction is what an automated attacker is best at grinding through. The controls that pass the test remove a capability instead: hardware-bound credentials, expiring tokens, cryptographic identity, and "network paths that do not exist rather than paths that are merely inconvenient."

I would put this test above the three principles, because it is the one that fails most often in the deployments we review. A line in the system prompt telling the agent not to send external email is tedious to get around. A rate limit on a payment tool is tedious. A token that expires in a week is tedious. Ask the question of each control in a design and most of the security in a typical agent deployment turns out to be friction.

What Foundation now means

The guide has three tiers, Foundation, Enterprise and Advanced, and says organisations of any size should aim for Enterprise. The change is at the bottom. Foundation has been raised because, as the guide puts it, "friction-only controls no longer qualify." Static API keys with a rotation policy are called out by name as "a known gap rather than a legitimate Foundation posture", on the grounds that a key that can be grepped out of a lockfile costs a model-assisted attacker nothing to find.

So the entry level is now:

• an identifier for each agent instance, backed by cryptographic material rather than a label, and present in every log line and access request;
• short-lived tokens from an identity provider, expiring in minutes and refreshed without a human;
• role-based access with deny by default;
• identity-based isolation of agent workloads, where services accept connections only from named callers and network segmentation is kept as a backstop;
• logs of every tool call, data access and external communication, with a request ID that follows the user's request through every action it triggers;
• an automated first pass over every alert before a person sees it.

Two placements look wrong to me. Sandboxed execution sits at Enterprise, though the text next to the table says it should be "mandatory rather than aspirational" for any agent that processes web content or documents. I would move it down a tier. An unsandboxed agent reading the open web fails the impossible-or-tedious test by itself. Human approval for high-risk actions sits in the Advanced row of the output-controls table, while the workflow section treats escalation triggers as a basic step. The workflow has it right.

The workflow

Part IV is the part to hand to an engineering team. Eight phases: requirements, supply chain, agent boundaries, prompt injection, tool access, credentials, memory, and measurement. Three points from it come up in nearly every review we do.

Tool allow-listing has to be enforced on two fronts. Once at the agent level, through the agent's own permission configuration, and once outside it, "in case the agent or the agent environment is compromised." Enforcing it outside means the tool authenticates the caller, with a certificate or a short-lived token bound to the agent's identity, and refuses anyone not on its own list. The agent's permission file is a policy that the agent's runtime enforces. If the runtime is compromised, the file went with it.

Every agent gets its own identity and its own credentials, including when you split one agent into several. The guide is blunt: "If you break it into multiple agents and provide them all the same credentials, you have failed to compartmentalize the risk." It also has a note on Claude Code's own sub-agents. From the outside they are indistinguishable from the parent and can carry up to the same permissions. The distinction only exists in the telemetry. That is an honest description of how most orchestration frameworks work today, and it is why delegation chains need their own line in a threat model.

Memory is validated on the way out as well as the way in. Hash stored context, tag each element with its source and the conditions under which it was added, check integrity at every retrieval, and put a time-to-live on anything that came from an external input or an unverified tool output. Keep versioned memory so you can roll back when poisoning is found.

The measurement phase ends with a question I have started using in workshops: would we know within an hour if an agent went rogue? If the answer is uncertain, the earlier phases need more work.

Three things to add

The guide is a controls catalogue, and a good one. Three things it does not do.

It does not bind authority to the task. Its policy inputs are the attribute-based ones: agent identity, resource sensitivity, requested action, time of day, source location, risk score. None of them distinguishes "send this email because the user asked" from "send this email because a web page the agent read asked." The agent's identity and permissions are identical in both cases. The one input that separates them is the task as the principal stated it, and the guide never makes that a policy attribute. We think it should be the first one. It is the whole design of Agent Auth for x402: a payment is checked against the task grant the agent was given as well as against its budget.

It gives every threat an attacker. Part II covers prompt injection, tool poisoning, privilege abuse, memory poisoning and supply chain, and each has an adversary behind it. An agent that over-generalises an instruction, or works around a blocker it was not supposed to pass, reaches the same controls with nobody attacking. The mitigations overlap. The attack trees do not, and the difference changes where you put the approvals.

It leaves the approval edge underspecified. "Present clear descriptions of intended actions" is the guidance. If the agent writes the description, the approver is approving the agent's account of what it is about to do. The approver needs the real thing: the actual recipient, the actual diff, the actual amount. Otherwise the approval is a step the agent can talk its way through, which puts it on the tedious side of the test.

The tiers tell you what a control looks like at each level of maturity. They do not tell you which edge of your particular system needs it first, or which invariant it protects. That is a threat model's job, and it is where we start every engagement. The threat-modelling method we use for that is the subject of the next two posts.