Zero Trust for AI Agents: Lessons from a 100-Agent Assessment

Picture a brilliant but painfully literal new hire. On day one, you hand them every key you own: inbox access, a task list, and one instruction - "get started." They never sleep, never take breaks, and never ask unnecessary questions. That's essentially what deploying an autonomous AI agent in a business looks like.

Now the harder question: what happens when someone else manages to slip that new hire a hidden instruction - buried inside an email, a document, or a web page it reads as part of its normal work?

An independent assessment of 100 production AI agents found that 98% of them sat exposed, simultaneously, to the exact three conditions that turn that scenario from hypothetical to available on demand. Only 11% passed a basic security bar.

Anthropic recently published a 36-page playbook on securing agents like Claude Code, and in a world where frontier models are becoming genuinely skilled at finding security vulnerabilities themselves, protecting the agents you run stops being optional. Here's what actually matters out of all of it - not the marketing, not the hype, just the controls that actually stop an attacker.

Five doors: mapping an AI agent's attack surface

To understand where an AI agent is vulnerable, it helps to break it into five components - because each one is a separate door an attacker can try to force:

• The model - the layer that thinks and decides.
• Tools - everything the agent can actually trigger: sending an email, editing a file, querying a database.
• Memory - what the agent remembers from past interactions.
• Identity - the credentials it carries to prove it's allowed to act.
• Autonomy - the freedom to decide its next step without asking you first. An attacker doesn't need to break the whole system. Finding just one of these five doors left open is enough.

Why the castle model collapsed - and what replaces it

The traditional way to secure systems is the castle model: a hard perimeter, and everything inside is trusted once it passes the gate. That's still the mental model most people default to. But an internally deployed AI agent punches straight through it, for three reasons:

1. Machine speed - no human approves every step or every tool call, so there's no gatekeeper in the loop.
2. Reading untrusted text all day - web pages, emails, documents can all carry a hidden instruction the agent simply obeys.
3. Standing access - the keys never leave its pocket. 24/7 access it can use at any moment. The castle model assumes a human gatekeeper and that everything inside is trustworthy. An agent has neither. So the wall simply doesn't hold.

What replaces it is called Zero Trust: never trust, always verify. Every request, at every one of the five doors, gets checked again each time - even one that appears to come from inside your own system.

The second half of that mindset is to assume breach: don't design for the possibility someone gets in - design as if the intruder is already inside, wearing a legitimate staff badge. The only question that actually matters is how far they could get before you'd ever know.

The lethal trifecta: the formula that turns an agent into an easy target

Simon Willison coined the term "lethal trifecta" for three ingredients that are each fine on their own but form a perfect opening together:

1. Access to private data.
2. Exposure to untrusted content - the open web, incoming email, documents it didn't write.
3. The ability to take an outbound action - sending something back out into the world. A model that reads the web but can't touch your data and can't send anything isn't much of a risk. But the moment an agent holds all three at once, an attacker has exactly what they need: the untrusted content smuggles in an instruction, the instruction reaches your private data, and the outbound action ships it straight out the door.

A Cloud Security Alliance research note cites the AI Risk Quadrant Q2 2026 assessment: of 100 assessed commercial and publicly available agents, 98% combined private-data access, untrusted content and outbound actions; 11% passed its baseline benchmark.

These are sample results under that assessment's method, not evidence that 98% of all agents have been breached or a measured rate for the entire market.

A real case: the impersonating postmark-mcp package

According to Postmark's September 25, 2025 security notice, the npm package postmark-mcp impersonated the company. After 15 versions, version 1.0.16 added a backdoor that secretly BCC'd email to an external server. This was not an official tool; Postmark's own services were unaffected.

That single line is the entire lethal trifecta in one incident: the agent held access to email (the private data), installed an untrusted package (the untrusted content, arriving through a tool), and could send email (the outbound action).

The official notice confirms the email-copying mechanism, but does not establish an affected-organization count or daily email volume. Those figures should not be treated as verified incident totals. The case illustrates supply-chain risk when an agent uses a third-party tool with access to email.

Which controls actually stop an attacker - and which just slow them down

The right starting assumption is a tireless attacker, patient, possibly already inside. For every security control you have, ask one question: does it make the attack impossible, or just tedious? A lot of so-called solutions are only tedious - rate limits, a non-standard port, long query strings. An attacker has infinite time, infinite patience, and near-zero cost per attempt.

They'll happily script hundreds of millions of tries overnight. Controls like these are friction, not security.

The controls that actually survive are the ones that remove a capability entirely:

• Hardbound credentials - a secret physically tied to one machine, so a copied key doesn't work anywhere else.
• Expiring tokens - access that dies within minutes instead of living forever.
• Cryptographic identity - provable proof of who you are that can't be faked.
• Network paths that simply don't exist - if there's no route from A to B, no amount of patience builds one. One more practical tip from the playbook: let AI handle the bookkeeping, not the decisions. AI can take notes, gather evidence, draft a postmortem - all the tedious work. Humans should keep the calls that actually matter: what to disclose, who to call, what containment looks like.

Five threat families

OWASP catalogued 17 distinct ways to attack an AI agent. Anthropic's playbook compresses these into five main families, and each one maps directly back to one of the five doors above:

1. Prompt injection - text the model reads carries an instruction it ends up obeying. The model door.
2. Tool and resource misuse - an agent going rogue with an MCP server it has access to. The tools door.
3. Identity and privilege abuse - an agent inheriting far more permissions than it actually needs. The identity door.
4. Supply chain risk - malicious packages or poisoned modules pulled in, exactly like postmark-mcp. Crosses every door.
5. Memory and context poisoning - corrupting what the agent remembers so it misbehaves later, or retrieving tainted data from something like a RAG database. The memory door. And the fifth door, autonomy, is the one that turns all of these from a slow problem into a fast one.

The numbers on the ground, and a three-stage maturity model

Gravitee's The State of AI Agent Security 2026 report draws on surveys of 919 executives and practitioners. It reports that 88% of surveyed organizations confirmed or suspected agent security or privacy incidents in the preceding year (page 6).

This is vendor-run, self-reported survey evidence including suspicions, not independent confirmation of a breach at every organization, and not the same sample as the 100-agent assessment.

The framework organizes implementation into three stages: foundation - the minimum bar most organizations should aim for, enterprise, and advanced - for high-risk deployments or strict regulatory environments.

What's notable is that tools like Claude Code already support much of this foundation out of the box, if you actually turn it on:

• Deny-by-default permissions - every write or execute action requires explicit approval, plus sandboxed execution and write-access restrictions.
• Auditing - OpenTelemetry metrics and full action logs, with a unique session ID for every run.
• Behavioral monitoring - command injection detection that flags suspicious commands even when they match an allow-listed pattern, with fail-closed as the default.
• Input and output controls - input sanitization, length limits, and a blocklist for dangerous commands.
• Credential isolation - Claude Code stores credentials in the OS credential store, with a path to integrate external secrets vaults.
• Memory isolation - sessions and users are separated by default. Nearly all of this is configured through the settings.json file - which is exactly where it's worth spending the time to tighten things up. Anyone who wants an extra layer can add something like the Microsoft Agent Governance Toolkit (open source, MIT licensed), which enforces policy, Zero Trust identity, and execution sandboxing on top of the agent's native permission layer.

A risk-based approach for anyone who doesn't need full enterprise Zero Trust

Not everyone runs an AI agent inside an organization with regulatory requirements. For a solo builder or small team, implementing full Zero Trust creates a lot of unnecessary friction - every action prompting for approval. The more practical approach is risk management scoped to context:

• Running an autonomous agent 24/7 on a side project? Isolating it in a separate VM (via a hypervisor, for example), fully disconnected from the rest of your file system, already provides meaningful protection - even without locking down every domain the agent can reach, that's a reasonable risk when there's no real sensitive data at stake.
• Lock down API keys everywhere you can: credit limits on a specific key, scoped permissions, tying a key to a specific project - most providers already support this.
• Secrets managers (AWS Secrets Manager, Infisical, Bitwarden, and similar) aren't immune to being breached themselves, but for protecting production-grade secrets, they're worth the investment. The core idea: map the full surface your agent actually touches, and choose your isolation and permission level based on what's genuinely at risk - not on how serious the security setup sounds.

The takeaway

The power handed to AI agents keeps growing - more access, more autonomy, more freedom to act alone. At the same time, the cost of an attack has collapsed: what once took a specialist months, a coding agent in the wrong hands can now attempt relentlessly, around the clock.

Zero Trust doesn't mean building a taller wall - the wall stopped being relevant. It means checking every request at every one of the five doors, every time, and planning as if the intruder is already inside.

The question that actually determines whether you're protected isn't how many controls you turned on - it's how many of them make an attack impossible, rather than just tedious.

Anthropic: Zero Trust for AI Agents (PDF)

Continue the workflow

To connect tooling with daily work, read the agentic engineering stack guide: interfaces, subscriptions and skills and evaluate the choices against your tasks and constraints.