AI agents are starting to operate inside real enterprise environments, and are crossing the line from software that suggests to software that acts. They call tools, move across systems, interpret goals, and execute multi-step operations with real permissions. That changes the security question. We are no longer only asking whether the model can be prompted safely. We have to ask what the agent can actually do when it is wrong, manipulated, or compromised.

Anthropic’s Zero Trust for AI Agents whitepaper, released on May 30th, describes in detail what most AI security conversations still avoid: agents are only as safe as the permissions, access paths they inherit and the infrastructure they run on.

With Anthropic’s authority, it says what we have been saying since we incorporated Act Security in September 2025: agentic apps are not only agentic, they are also cloud native apps, the threat is still access, and the controls that matter are the ones that make attacks impossible rather than tedious.

The premise is the oldest idea in security, rewritten for a new kind of actor: trust nothing, verify everything, assume breach has already occurred.

Here are the five takeaways that matter most, and where Act fits each one.

1. The threat is access, not the prompt

An agent doesn’t need an exploit. It needs the permission you already gave it, and a reason to use it differently than you intended.

“Traditional access controls won’t prevent agents from misusing legitimate permissions, and monitoring needs to account for attacks designed to succeed through persistence rather than exploitation.”

Where Act fits. Act models effective access across every boundary — what is configured, what is observed, and what was ever intended — cross-analyzing IAM and network as a single access model. That is the picture no agent inventory or prompt inspector can give you. It is the only way to understand an agent’s true blast radius before it ever takes action, under the assumption that every agent’s blast radius will eventually be tested.

2. Architected for breach from day one

The winners won’t be the companies with the most advanced AI. They’ll be the ones with the strongest fundamentals. The AI era rewards teams whose fundamentals in infrastructure, access, and blast radius are already strong.

“The organizations best positioned for this shift will not necessarily be the ones with the most advanced AI. They will be the ones whose fundamentals are strong enough that AI-assisted scanning finds fewer bugs in the first place, and whose agent deployments were architected for breach from day one.”

Where Act fits. This is the Act thesis in a sentence — go back to the access architecture itself, before attacks unfold. The model will change. The agent framework will change. The infrastructure boundary is what decides what can actually happen when something goes wrong.

Act inventories every workload and AI service in the estate, including the ones no one told security about, identifies the blast radius of each, and shrinks it with prioritized hardening campaigns: guardrails that deny whole classes of cross-environment movement and exfiltration, and ring-fencing, explicitly allow, that contains the blast radius around crown-jewel workloads.

3. Make the attack impossible, not tedious

Anthropic’s test for any control: does it make the attack impossible, or just tedious? Rate limits, non-standard ports, SMS codes, an extra hop — none of it slows an attacker with unlimited patience and near-zero cost per attempt. Static keys fare worst of all:

“Treat them as already-compromised.”

The controls that survive share a pattern:

“hardware-bound credentials, expiring tokens, cryptographic identity, and network paths that do not exist rather than paths that are merely inconvenient.”

Where Act fits. Act finds where you are still on static keys, over-broad wildcards, and click-ops drift, and enforces deny-by-default through the cloud-native controls you already own. The goal is never a slower attack — it is a path that does not exist.

4. Least privilege becomes least agency

“Least privilege” asks what an identity can access. However, “least agency” asks what an agent can do, under what conditions, with which tools, and with what level of oversight.

“least agency goes further, restricting what each agent tool can do, how often, and where.”

We gave up rightsizing human permissions because people hoard access and never give it back.

Agents are different. They are production applications with a declared purpose. Unlike human users, their intended function is known at build time, not inferred at runtime. That makes them uniquely suited for least-privilege design: permissions can be scoped to the agent’s specific intent rather than granted broadly in anticipation of future needs.

But intent alone is not a security control. Those boundaries have to be enforced independently of the agent itself. An agent is compute, and compromised compute walks straight through its own guardrails. That is why permissions must be enforced in two places: by the agent and by the resources it accesses. The real control is the one that still exists after the agent has been compromised.

Where Act fits. Least agency is the heart of both the paper and Act. Act enforces it on both sides of the access path — on the agent and the gateway or MCP server in front of it, and on the resource itself through cloud-native IAM. Over-broad agents are split into separately scoped sub-agents, and the role-assumption and trust-relationship paths a manager agent would use to pass its access down are eliminated rather than policed at runtime. The resource enforces its own guardrails and sensitivity tags no matter what the agent is tricked into asking, so a compromised agent can’t inherit access it was never scoped for.

5. Detection assumes you already lost

Prompt inspection, output filtering, classifiers — that layer is real, and it matters for data protection. But it catches the damage on the way out, which means it assumes the agent is already compromised. The cleaner answer to “the agent got compromised” is making sure it never had the permission in the first place.

Where Act fits. Governance is intent, and Act turns intent into the controls that enforce it. Intent becomes a control. An email-summarizer only needs to read, so Act keeps its read access to the email MCP and strips send, write, and delete, even though the server exposes them. The control lives on the MCP and the resource, not in the agent’s prompt, so it determines whether the agent ever sees it. Detection tells you the summarizer tried to delete a mailbox. This makes sure it couldn’t.

What this means for security leaders

Anthropic’s real contribution here is a shift in assumptions. The traditional security model assumes access will be used as intended. Zero Trust assumes every granted permission will eventually be exercised, inherited, delegated, or compromised.

That assumption becomes far more important in the age of agents. Agents don’t invent risk. They inherit it. Every permission, identity, trust relationship, and network path already present in the environment becomes part of their operating model. The blast radius is established long before the first prompt is sent.

That’s why the paper’s most important idea is not about agents at all. It’s about access. Cloud and AI are not separate security problems. They are the same access problem expressed through different technologies.

Secure the foundation, then let AI ride on top of it.

If you’re wondering how exposed your environment actually is, start there: map the identities, permissions, and paths that already exist in your cloud environment today. Most teams are surprised by what they find.

Source: Anthropic, Zero Trust for AI Agents. Quoted lines are verbatim.