Zero Trust Is the Foundation AI Agents Need

Most agent-security advice arrives as a list of separate problems. Watch for prompt injection. Protect API keys. Sandbox tools. Log actions. Add human approval. Secure memory.

All of that is useful, but a list is not an architecture.

Anthropic’s May 2026 guide, Zero Trust for AI Agents, supplies the missing structure. Its argument is straightforward: an agent should not be trusted because it is inside the network, because its model is considered safe, or because it was given a legitimate task. Every identity, request, tool call, and delegation still needs to be verified. Access should be narrow, temporary, and recoverable.

That makes this guide a lynchpin for the way I think about agent security. It joins several ideas that are easy to discuss separately but only work when they support one another.

Why agents break the old assumptions

Traditional software follows code paths written in advance. An agent interprets a goal, chooses tools, reads outside material, and decides what to do next. It may keep memory across sessions or delegate work to another agent.

That flexibility is the point. It is also why ordinary service-account security is not enough.

An agent can cause damage while using valid credentials and approved tools. A poisoned web page can influence a research agent. A compromised low-privilege agent can hand a convincing request to a more powerful one. A useful memory can become a durable attack path. Two harmless tools can be chained into a data-exfiltration route.

None of those examples requires the attacker to break authentication. The system can know exactly which agent made the request and still make the wrong authorization decision.

Zero Trust gives us a better starting assumption: the agent may be mistaken, manipulated, or compromised at any point. Design the surrounding system so that one bad decision cannot become an unlimited run of bad decisions.

Least privilege is not enough

The guide uses OWASP’s term least agency. It extends least privilege beyond which resources an identity can reach.

Least agency asks more specific questions:

• Which tools can this agent use?
• Which operations can each tool perform?
• Which parameters are acceptable?
• How often can the operation run?
• How much data can it touch?
• When does it need a person to approve the next step?

A mail summarizer does not need send or delete rights. A database research tool should start with read-only queries. A file tool can be limited to one working directory. A credential can exist only for the few minutes needed to complete a named task.

This matters because an instruction such as “do not send email” is guidance to the model. Removing the send capability is a control.

The guide offers a useful design test: does a safeguard make the attack impossible, or merely tedious? Rate limits, extra hops, and obscure ports can slow an attacker down. A missing network route, an expired token, or a tool that has no delete operation removes the capability.

Friction has value, but it should not be confused with a boundary.

Identity has to survive the whole chain

Every agent instance needs its own identity and credentials. Sharing one service account across several agents destroys attribution and combines their blast radiuses.

The identity also has to follow the work. A user request should receive a trace ID that continues through model decisions, tool calls, subagents, and downstream services. When one agent delegates to another, the receiving service should verify the new caller and the authority behind the specific task. It should not assume the original agent had permission to delegate everything it could do itself.

This is where identity, authorization, and observability meet. A unique agent label in a log is not enough. The downstream service must enforce policy using that identity, and the trace must show which request and approval led to the action.

Short-lived credentials make the same chain safer. Static keys hidden in a configuration file are still static keys. A token scoped to one agent, one resource, and a short window is less useful after theft and easier to revoke during an incident.

Tools need two sets of guardrails

Tool policy should exist both inside and outside the agent.

Inside the agent, an allowlist limits which tools the model can select. Hooks or validators inspect parameters before execution. High-risk operations pause for approval.

Outside the agent, the tool or receiving service authenticates the caller and enforces its own permissions. It does not rely on the model to police itself. A database rejects writes from a read-only identity even if the agent produces flawless SQL. A network policy blocks destinations that the task does not need. A sandbox prevents a compromised tool from wandering across the host.

The outer control is essential. Prompt injection defenses improve, but no model can reliably separate instructions from data in every untrusted document, message, or web page. Input filtering is one layer. It cannot be the final authority over what a tool is allowed to do.

This is the same idea behind the Agent Trace Lab: describe the permitted actions before the run, separate secrets from the plan, identify approval points, and then compare the trace with the rules. The plan helps the agent behave. The enforcement and review show whether it actually did.

Memory is a security boundary

Persistent memory changes an agent from a session into a system with history. That history needs the same skepticism as any other stored input.

The guide recommends isolation between users and sessions, source attribution for stored memories, integrity checks during retrieval, retention limits, quarantine, and rollback to a known-good state.

Source attribution may be the most important part. A memory derived from a user decision should not carry the same trust as a claim scraped from an unknown page. A tool result should retain the identity of the tool and the conditions under which it was collected. If provenance is stripped away during summarization, later sessions receive a confident statement with no way to judge it.

Memory security is not only about confidentiality. It is also about preventing old, poisoned, or misattributed context from steering future behavior.

Observability must lead to action

Logging every tool call is necessary, but a pile of events is not the same as an investigation trail.

A useful trace connects the triggering request, agent identity, retrieved context, tool parameters, authorization decision, human approval, result, and any later delegation. It should let an operator answer two questions quickly: what happened, and under whose authority?

Anthropic calls out dwell time and coverage as the first operational measures to instrument. How long does it take for a person to learn that something unusual happened? What fraction of alerts are actually investigated?

Those measures keep observability tied to response. A beautifully detailed log that nobody reviews does not reduce risk.

The guide also draws a sensible line for defensive automation. Agents can collect evidence, enrich alerts, pursue parallel checks, and prepare a structured summary. People should retain decisions about containment, disclosure, and customer communication. Automation should remove investigative bookkeeping before it removes accountable judgment.

A practical place to start

The full framework spans three maturity tiers and eight implementation phases. A smaller team can begin with a compact sequence:

1. Inventory every agent. Record its tools, data, credentials, external inputs, and possible blast radius.
2. Give each agent a distinct identity. Do not share credentials between agents or subservices.
3. Remove standing access. Replace static keys where possible with short-lived, narrowly scoped credentials.
4. Deny by default. Start tools as read-only, expose only necessary operations, and validate parameters at the tool boundary.
5. Treat outside text as untrusted. Isolate retrieved content and never let it silently become system instruction or durable memory.
6. Trace the complete action chain. Include the original request, policy checks, approvals, tool calls, and result.
7. Practice revocation and recovery. Confirm that credentials can be revoked, work can be stopped, and state can be restored without improvising during an incident.

This is not the complete Enterprise tier. It is enough to expose whether the architecture has real boundaries or mostly good intentions.

The foundation, not the finish line

The guide is demanding. Its Foundation tier already treats short-lived credentials, cryptographically rooted identity, identity-based isolation, and automated first-pass alert triage as entry requirements. Some teams will need to reach that state in stages.

The direction is still right. Agent capability is moving faster than most organizations’ access models. Retrofitting controls after agents are connected to production data will be harder than building those boundaries while the system is small.

Zero Trust does not solve prompt injection or make model behavior predictable. It does something more practical. It assumes those problems will not disappear and limits what any single failure can reach.

That is the architecture agents need: verify the caller, limit the capability, record the chain, and make recovery routine. The smarter the agent becomes, the more important those ordinary security fundamentals get.