Zero Trust for AI Agents: Stop Trusting Your Agent

In May 2026, Anthropic published a security framework for autonomous agents, and the best thing it brings is a single question you can ask of any control: does this control make the attack impossible, or just tedious? Against a human, friction works. A rate limit, SMS-based MFA, a non-standard port, an extra login hop: every layer discourages someone who eventually gets tired. Against an attacker running an AI agent in a loop, with infinite patience and near-zero cost per attempt, friction discourages no one. It just makes the log longer.

This post is an engineer’s read of the “Zero Trust for AI Agents” document^[1]: what it says, what part of that is brand messaging versus useful judgment, and what it means for the architecture of an agent you’re already running in production.

What Changed? The Attack Timeline Has Collapsed

The document’s thesis is that frontier models are compressing the time between a vulnerability and a working exploit from months to hours, at a marginal cost measured in dollars^[1]. It’s worth being precise here: this is a claim Anthropic makes within its own framework, with no benchmark or external citation. It isn’t measured data you can replicate. It’s the premise everything else in the document argues from.

And as a premise, it matters. If you accept that discovering and weaponizing an exploit stops being a bottleneck, every security model built on “this is too much work for anyone to bother” falls apart. Friction was a bet on attacker economics: you raise the cost, they give up. An automated attacker breaks that bet. It tries thousands of prompt variants while you sleep, and every failed attempt costs it neither frustration nor time.

That’s where the central heuristic comes from, and it’s the one worth memorizing: when in doubt, prefer a control that eliminates a capability over one that merely limits it. A token that expires in five minutes is an eliminated capability. A rate limit of a thousand requests per hour is a limited capability. That difference decides whether you survive someone with infinite patience.

Why Your Own Agent Is an Attack Surface

An agent in production executes actions with your credentials over data you sometimes don’t control. That makes it an attack surface in four ways a traditional web service doesn’t have, and all four rest on one root weakness: LLMs don’t reliably distinguish between informational context and actionable instructions.

The first is indirect prompt injection. You already know the direct version: someone types “ignore your instructions” into the input. The indirect one is worse because it doesn’t go through the input at all. The agent reads a web page or a support ticket, and hidden inside that content are instructions the model obeys as if they came from you. If your agent summarizes an inbox, anyone who emails it can try to give it orders. I broke down the full mechanism in prompt injection: how hackers hijack agents.

The second is a malicious tool, and in September 2025 it stopped being theoretical. The npm package postmark-mcp was an almost exact replica of Postmark’s official MCP server. For fifteen versions it behaved identically to the original and gained adoption. In version 1.0.16 the author added a single line to the send code: a hidden BCC to an external domain on every email the agent sent^[3]. The first malicious MCP server found in the wild didn’t exploit a model bug, and it didn’t hide instructions in the tool’s description (that’s classic tool poisoning, the text the model reads when choosing what to call). It trojanized the implementation: a supply-chain attack on the layer an agent trusts by design. I covered the skills and MCP supply chain separately in skills and MCP supply-chain security.

The third is tool chaining. Every tool the agent uses is legitimate and runs with valid credentials. The damage is in the sequence. Reading a record from the internal CRM is legitimate. Sending an external email is legitimate. Chaining the two together is exfiltration, and your per-host monitoring sees nothing unusual because each call, on its own, is authorized.

The fourth is memory poisoning. An instruction planted in the agent’s persistent memory survives across sessions. There’s no single “malicious” moment a reviewer can point to: it’s slow drift, where no individual change looks like an attack until the accumulated whole is one.

Simon Willison named the combination that makes this lethal: the lethal trifecta: access to private data plus exposure to untrusted content plus the ability to exfiltrate^[4]. Combine all three in one agent and you have a problem, not a risk. Anthropic’s document doesn’t use the term, but it describes the exact same mechanism when it explains why an email summarizer with send permission is a bomb.

And there’s a layer underneath all of these: the model itself can arrive already poisoned from training. A study by Anthropic with the UK AI Security Institute and the Alan Turing Institute found that just 250 malicious documents are enough to introduce a backdoor into models ranging from 600M to 13B parameters, and that the backdoor survives safety fine-tuning^[2]. It isn’t a percentage of the corpus you can dilute by adding more clean data. It’s an absolute count, which is exactly why it scales so badly. If the agent you deploy inherits a model compromised somewhere in the supply chain, none of the runtime controls below will catch it.

Zero Trust, But for an Autonomous Agent

Zero Trust isn’t new. It comes from network security, is standardized in NIST SP 800-207, and rests on a handful of principles: never trust something because of its position on the network, always verify, assume you’re already breached, and grant the minimum privilege necessary. None of this was built for agents. What the framework contributes is translating it to an actor that behaves differently from a user or a microservice.

An agent differs in several ways at once. It acts across multiple steps without human approval at each one, so an early deviation propagates. It has access to real tools, not just data: APIs, databases, files, MCP servers. It interprets instructions with ambiguity, and something benign for a human can turn dangerous once executed. It carries memory and context across sessions, so poisoning persists. And when you coordinate multiple agents, you create trust relationships an attacker can pivot through.

That last point is the one most people underestimate. The moment a manager agent delegates to a worker, you’ve created an internal trust boundary. If the manager hands the worker its entire privilege, you’ve just built a confused deputy: the worker acts with authority it should never have had, and the system sees it as legitimate.

The Controls That Survive the Test

This is where the framework gets concrete, and where the “impossible or tedious” test shows which control holds and which is decoration.

Treat static API keys as already compromised. Rotating them every ninety days isn’t enough if they can be grepped out of a config file, a log, or a process’s memory. The new baseline is short-lived, narrowly scoped tokens issued by an identity provider, expiring in minutes. The difference isn’t incremental:

# Before: the key lives forever and only needs to be read once
agent_credential:
  type: static_api_key
  value: "sk-live-9f3a...b21"   # in config, in process memory, grepable
  rotation: 90d                  # exposure window: 90 days

Against that, the Zero Trust baseline issues a key that expires before it’s worth anything:

# Zero Trust baseline
agent_credential:
  type: short_lived_token
  issued_by: identity_provider   # issued just-in-time
  scope: ["crm:read"]            # only what this task needs
  ttl: 5m                         # exposure window: 5 minutes

Stealing a token that expires in five minutes forces the attacker to use it right away, inside your detection window. That’s eliminating a capability, not limiting it.

Least agency. The term comes from OWASP, which formalized “excessive agency” as a risk, and it extends least privilege into the dimension agents were missing. Privilege answers what the agent can access. Agency answers what each tool can do, how often, and where. A database tool that only reads can’t write even if the agent asks it to under injection. An email summarizer with no send or delete permission is harmless even if it gets hijacked:

tools:
  - name: db_query
    access: read_only          # never INSERT/UPDATE/DELETE
    tables: ["orders"]         # nothing outside this scope
  - name: email_summarizer
    can_send: false            # eliminated capability, not just monitored
    can_delete: false
    rate: 30/min

Sandbox every untrusted input. Any agent that processes web pages, documents, or emails must run in an isolated environment, along the lines of gVisor: a user-space application kernel that intercepts and reimplements the process’s syscalls instead of letting them reach the host kernel. The document treats this as a requirement, not an aspiration, and that makes sense: if you assume the breach, the sandbox is what contains the damage when the injection works.

Dynamic per-task scope. Just-in-time and just-enough: grant the permission the exact moment the task needs it and revoke it when it’s done. The decision doesn’t depend only on identity, but on the resource, the action, the time, and the risk (ABAC). A standing permission leaves that exposure open indefinitely.

The document backs this up with two defenses that actually come with numbers, and the difference between them illustrates the thesis. Microsoft’s Spotlighting, which delimits untrusted content so the model doesn’t confuse it with instructions, drops indirect injection success from over 50% to under 2%^[1]. Anthropic’s constitutional classifiers block over 95% of jailbreaks with few false refusals^[1]. But look closely at the second one: a classifier still lives on the model’s side, it depends on the model correctly evaluating what comes in. It helps, a lot, but it isn’t a hard external barrier the way an expiring token is. Lean on it to raise the bar, but don’t rest the whole system on a classifier.

These controls share one property: they don’t depend on the model behaving well. They’re external and hard. Compare them with their friction-based counterparts:

Friction Control	Hard Barrier	Why Friction Fails
SMS-based MFA	Passkey / FIDO2	The SMS code is a transferable secret: intercepted (SIM-swap, SS7) or handed over in real-time phishing, no retrying needed
API key rotated every 90 days	Ephemeral token (minutes), issued by an IdP	The static key is grepable for its entire lifetime
Rate limit	Eliminate the route or the capability entirely	With infinite patience, an hourly limit just drags out the attack
Least privilege	Least agency (what each tool can do)	Privilege says what it can access, not what destructive action it can execute
Per-host monitoring	Auditing the agent’s action sequence	Tool chaining uses legitimate tools with valid credentials

If you want these controls as application code and not just as principle, guardrails are the piece that implements them: I covered it in how to implement guardrails in AI agents.

Defending at the Speed of AI

If the attacker automates, your manual defense loses on speed alone. The framework’s answer is an agentic SOAR: put a read-only model in front of the alert queue to triage before a human sees it. It classifies and preps the ground before the human steps in.

The tempting mistake is automating the entire queue at once. The framework recommends the opposite: start with one noisy rule, the one generating the most false positives, and measure it for two weeks against a human reviewer before giving it more rope. If the model agrees with the human, you expand. If not, you’ve learned cheaply.

The line that sums up the right posture is this: the right move doesn’t take the human out of the loop; it takes them out of the paperwork and into the decisions. Automate the logging, the artifact collection, the postmortem draft. Let the human decide containment, disclosure, and what you tell the customer. The same division of responsibility I argue for in the architecture of an enterprise agent: the human where judgment matters, the machine on the repetitive parts.

What This Framework Doesn’t Solve

This is where the post gets honest, because the field itself has a critique the document downplays. Chris Hughes, of Resilient Cyber and a member of OWASP’s agentic security project, puts it well: most companies haven’t achieved Zero Trust even for their humans, who are deterministic entities with stable roles^[5]. An LLM is probabilistic. It can behave unpredictably even to the people who trained it.

That breaks a foundational assumption. Zero Trust verifies identities and policies that behave the same way every time. An agent doesn’t. A system prompt is, at best, a suggestion to a probabilistic system that obeys it at its own discretion. You can write “in this phase, only read, never write” and it will obey almost every time, until the one time it decides writing was necessary to complete the goal. His phrase sticks with you: you can’t put a firewall on an agent’s reasoning.

And that’s exactly why the controls that matter are the external ones. You don’t trust the model to respect the prompt. You take away its ability to do damage at the layer below, where its probabilism can’t reach: the token that expires, the tool that only reads, the sandbox that contains. The framework is mechanically sound even if it’s sold with optimism. If you take away one idea, let it be this: a guardrail is worth something because it’s external to the model, not because the prompt is well written. I explain the distinction between a control and a suggestion in what is a guardrail in AI.

One note on the brand spin: the document interleaves advice that presents Claude Code as the reference implementation, with deny-by-default permissions, sandboxed execution, OAuth for MCP, and hooks that validate parameters before execution. That’s one reasonable implementation of these principles. It isn’t the only one, and the framework’s value is in the principle, which is vendor-neutral.

What to Do on Monday

None of this is worth anything as theory. Translated into actions you can start this week:

• Inventory every tool your agents can invoke and classify it by what it can do, not just what it can access
• Replace every static API key on an agent with a short-lived token issued by your IdP, scoped per task
• Flag the agents that read untrusted input (web, email, PDFs, support tickets) and move them into an isolated sandbox before granting them more permissions
• Trim each tool’s agency to the minimum: reads without writes, no send or delete unless strictly necessary
• Review manager-to-worker delegations so no worker inherits the manager’s full privilege
• Add auditing over the agent’s sequence of actions, not just over each per-host call
• Pick one noisy rule from your alert queue and measure two weeks of automated triage against a human before expanding

You don’t hit the baseline all at once. But each of these points eliminates a capability instead of just watching it, and that’s the only metric that matters to an attacker with infinite patience.

If you want to practice these agent patterns (least privilege, tool design, human oversight) with exercises instead of a 36-page PDF, they’re in the interactive course AI Agent Design Patterns on Learn.

Sources

1. Zero Trust for AI Agents (Anthropic): the May 2026 framework, with the collapsed-timeline thesis, the design test, least agency, ephemeral tokens, sandboxing, JIT/ABAC, agentic SOAR, and the Spotlighting figures (from over 50% to under 2%) and constitutional classifiers (over 95% of jailbreaks blocked) cited within the document.
2. Small samples can poison LLMs (Anthropic, UK AI Security Institute, and The Alan Turing Institute): an October 2025 study in which 250 malicious documents are enough to introduce a backdoor into models from 600M to 13B parameters, as an absolute count rather than a percentage of the corpus.
3. First malicious MCP server found stealing emails (The Hacker News): the postmark-mcp case (September 2025), where version 1.0.16 added a hidden BCC to an external domain on every email sent.
4. The lethal trifecta (Simon Willison): private data, untrusted content, and the ability to exfiltrate as the combination that makes an agent exploitable.
5. Zero Trust was built for a different threat model (Chris Hughes, Resilient Cyber): the critique that Zero Trust assumes deterministic entities while an LLM is probabilistic, and that a system prompt is a suggestion, not a control.

Frequently Asked Questions

Wasn’t Zero Trust a networking thing?

It was, and it still is. It originated in network security and is standardized in NIST SP 800-207: don’t trust based on network position, always verify, assume the breach, and grant least privilege. Anthropic’s framework reapplies it to a new kind of actor, the autonomous agent, which acts across multiple steps, uses real tools, and carries memory across sessions. The principles are the same; what changes is who you apply them to.

What’s the difference between least privilege and least agency?

Least privilege limits which resources the agent can access. Least agency, an OWASP term, limits what each tool can do, how often, and where. You can give an agent read access to a database (privilege) while also preventing that tool from executing any write (agency). Agency is the layer that saves you when a prompt injection convinces the agent to attempt something destructive: the tool simply doesn’t have that capability.

Does a system prompt count as a security control?

No. It’s a suggestion to a probabilistic system that can skip it unpredictably if it thinks doing so helps complete the goal. The controls that count are external: tokens that expire, tools without write permission, a sandbox that contains the damage. You can’t put a firewall on an agent’s reasoning.

Does this apply if I only use Claude Code or a single MCP server?

Yes, and the postmark-mcp case is the example. A single compromised MCP server is enough to exfiltrate data with valid credentials, because the agent trusts the tool by design. Even if you use only one tool, the same applies: an ephemeral token instead of a static API key, and least agency so that MCP can only do what’s strictly necessary. Claude Code implements several of these controls by default, but the principle is independent of the tool.

What is tool poisoning and how do I detect it?

Tool poisoning is hiding malicious instructions in a tool’s description, schema, or metadata (typically an MCP server): the model reads that description when choosing which tool to call and executes the hidden order believing it’s a legitimate part of the tool. It’s a sibling of the implementation backdoor in postmark-mcp, where the damage lived in the code rather than the description, and they share a defense. Detecting it is hard because everything runs with valid permissions, so the defense is preventive: pin exact versions of your MCPs, audit both the code and the description of third-party servers before connecting them, and run the agent in a sandbox with least agency so, whether the descriptor or the implementation is poisoned, it has nothing to reach.