What does Anthropic's Zero Trust guide give you for securing AI agents, and what does it leave to you?

When I come across new research or a new framework, I bring it into the working model I already keep for agent memory and content trust, and I test one against the other. Anthropic's Zero Trust for AI Agents guide got that treatment. What follows are my thoughts after running it through the model.

What is worth taking from the guide, and what would I add to a Zero Trust architecture built for agents? I am not reviewing Anthropic here. The guide is strong, and I would hand it to any team standing up agents. I am using it as a starting point for a series that goes deeper on the parts a builder designs.

What the Guide Is

The guide is a maturity model. It takes about fifteen areas of agent security, from identity through memory protection, and lays out three levels for each: Foundation, Enterprise, and Advanced. Foundation is the entry level, Enterprise is where it says most organizations should aim, and Advanced is for regulated or high risk environments. The levels are built on a standard Zero Trust premise. Trust nothing by default, verify each request, and design as though a compromise has already happened.

That structure is the guide's main strength. It gives a team a way to answer where am I now and what is the next level, instead of treating agent security as one undifferentiated pile of work.

What You Can Put In Place Now

A good part of the guide is practical today, and a working team can act on it now.

Give each agent instance its own identity backed by real cryptographic material, not just a name in a config file. Issue credentials that expire in minutes and refresh on their own, in place of static keys an attacker can read. Default to deny, so an agent reaches just the specific systems its job needs. Sandbox anything that reads email, documents, or web pages, with limited network and file access. Put a human approval step in front of the actions that carry real consequences, like sending mail or moving money.

Enterprise teams already run most of the tooling these controls need, an identity provider, secrets management, and container isolation. The guide's contribution is saying which of those apply to agents, and in what order to reach for them.

The Test Worth Borrowing

When you look at any control, ask whether it makes the attack impossible or just tedious. Rate limits, extra hops, unusual ports, and text message codes slow an attacker down. They do not stop one that has patience and near zero cost per attempt, which describes an automated attacker well. The controls that survive the test remove a capability rather than throttle it. A network path that does not exist beats a network path that is merely inconvenient.

I like this test because I can apply it to my own work. A screening step that scores incoming text for prompt injection, meaning an attacker hiding instructions inside content the agent will read, is useful. It is friction rather than a wall, raising the cost of an attack without making it impossible. Better to say that than sell it as a guarantee. The real barrier has to be built into the design, and that idea runs through the areas below.

Three Additions I Would Make

The guide is broad by design, so a few agent specific layers get one line where they could use a chapter. These are the three I would add to a Zero Trust architecture for agents, and each gets its own deeper piece later in the series.

Trust is a label that travels with the content

The guide treats incoming content as trusted or untrusted, tells you to validate it at the boundary, and tells you to tag stored memory with its source. It even tells you to quarantine memory that traces back to an untrusted source. That is correct as far as it goes. What it does not spell out is that trust is a property of where the content came from, that it only degrades, and that a summary of an untrusted source is still untrusted. The guide treats that quarantine as integrity checking, tamper detection, which blends two different questions, whether the material was tampered with and whether the agent is allowed to act on it. The rule that does the work is the one the guide leaves implicit. Content from an untrusted source must not drive an action that reaches trusted internal data. I go deeper in the piece on content trust in a RAG pipeline, the setup where an agent pulls documents from a store to answer a question.

Review the whole plan, not one call

The guide names tool chaining as a threat, where an agent combines safe tools into an unsafe sequence, like reading internal customer records and then sending them out through an email tool. Its defenses work one at a time, though. Allowlist each tool, cap what it can do, validate the call's parameters. The harm lives in the sequence, so checking one call at a time can miss it. Review the whole plan the agent intends to run, and that check is deterministic code, not a second model grading the first. It reads where each step's data came from and what the step would do, and refuses any step where untrusted content drives a privileged action. A cheap screening step only thins the volume, the same friction as the input scoring above, deciding which of the remaining plans a person sees. That is the subject of the piece on plan review in an agent workflow.

Output is a set of exits, and the display surface is one of them

The guide's output control scans what the agent produces for sensitive data, and it gates the agent's own outbound connections. Neither one watches the display, where the client fetches and renders what the agent produced with no outbound call from the agent at all. Data can leave through a tool call, a logged field, or that render step, and a scan for secrets is not looking at most of those paths. Exfiltration through a rendered image, with no tool call at all, has already happened in the wild. The useful move is to enumerate the ways data can leave, including the display, and control each exit on its own, apart from any judgment about the input. I take this apart in the anchor piece on the paths data uses to leave an agent.

Where This Goes

Anthropic's guide is a good map, and like any map it has edges. The tier model gives a team a real sense of direction. The three additions above are where the guide points and then hands the design work to you, which is where a practitioner's judgment becomes worthwhile. The rest of this series walks into each one with a working example, starting with the paths data uses to leave an agent.

What I Am Not Claiming

I am not saying the guide is wrong on these points, or that it should have gone deeper. Something that covers fifteen areas across three levels cannot spend a chapter on each. The three additions are where general guidance ends and the design of a specific system begins. I am also not claiming the ideas I am carrying into the series are new. Trust labels, plan review, and controlling how data leaves have prior work behind them. What I can offer is a builder walking each one into a real system and showing where it holds and where it strains.