Zero Trust for AI Agents: Architecture & Controls

According to the Gravitee State of AI Agent Security report, just 47.1% of AI agents deployed within the typical enterprise are being monitored and secured. A separate report from Cloud Security Alliance and Aembit discovered a more troubling statistic: 68% of organizations are unable to distinguish data from human activity and AI agent activity in their logs. When you combine those two numbers, the strong business case for zero trust for AI agents becomes clear: Most teams have no visibility into what their agents are doing, and even when they do, they can't determine who or what is doing it. That division does not need to be addressed through self-policing by the agent. The attack surface of a prompt injection is the agent's very own reasoning process. It is not possible to enforce inside the agent's prompt if it is the same thing that was manipulated to determine the safety of the action. It must be placed outside it in a location where the manipulation cannot reach.

Why Traditional Zero Trust and IAM Break Down for Agents

Zero trust for agentic AI is a problem that is different from that of zero trust for humans on a VPN. In traditional IAM, if a user logs in, all actions performed during that session are likely to be attributable to that user. Agents challenge that notion in two ways.

Session-Boundary Authentication vs. Continuous, Per-Request Verification

A human employee only needs to be authenticated once, perhaps with MFA, and their session is trusted for hours. There can be hundreds of tool calls and data reads within that window, each of which can be the moment that one of the instructions in a session becomes a hijacked instruction. Session-level trust means that the user identity of the session will not change during a session. Agents must be continually authenticated: re-authenticate each request based on the current context, and not the context at the time of session start.

The visibility gap manifests itself in practice here. That same CSA and Aembit survey revealed that 43% of organizations continue to use shared service accounts for their agents, and 52% of organizations continue to use workload identities rather than agent-specific credentials - partly why most organizations are unable to distinguish between agent actions and human actions in their logs. If there is no per-request verification that is associated with a specific agent ID, there is no way to detect when an agent's fifth tool call performs an action not approved by its first four.

Non-Deterministic Execution Paths and Unanticipated Resource Access

Traditional access control makes the assumption that there exists a predictable set of resources a given role/service requires and provides it with a standing access to that set. Agents do not have a rigid execution path - the same agent, the same tools, the same content retrieved in the same order - might yield a different resource based on the interpretation of the last piece of retrieved content. This is why you would give it reasoning in the first place, but also means that you can't list all of the resources it may access in advance, as you can with a service account.

If the agent decides mid-task that they need a finance API as well because a tool description or retrieved text told them that was the next logical step, then a "this agent needs read access to the CRM" policy would not have been written for the agent. A self-directed system within your infrastructure is beyond the capabilities of static, pre-approved access lists.

The Three NIST SP 800-207 Principles, Applied to Agents

NIST SP 800-207 clearly outlined zero trust architecture for humans and static workloads, but its three principles-verify explicitly, enforce least privilege, and assume breach-apply just as clearly to agents, as long as the assumption of "identity" is no longer the user. When we bring NIST 800-207 to AI agents, we're swapping out the human-on-a-keyboard for actors that can be machine-fast, but are not deterministic.

Verify Explicitly

In a human, explicit verification is the combination of MFA, device posture, and a login event. An agent's identity is based on cryptographic proof, and is different from its human or service account to which the agent is deployed, and is verified on each request. It also needs to reflect what the agent is requesting, not just who — a request in line with the purpose of the agent is much different than another agent with the same credentials requesting a resource that the agent has never interacted with before.

Enforce Least Privilege

Least privilege enforcement for agents involves granting the agent permissions only for the task at hand, not granting it the widest possible permissions for every task it might conceivably run. This is "least agency" in Anthropic's framework: not only does an agent have limited access to data, but it also has limited agency to act on that data without a checkpoint. In practice, this translates to task-scoped credentials (short-lived) which expire upon the completion of the task, rather than "standing" access that would be set up and left on because it's not convenient to rotate.

Assume Breach

Breach for agents is not about trying to stop breach; it's about designing for the time a breach is successful. It means segmenting by identity so that a compromised agent can't move laterally, containing the blast radius of any compromised session, and running the response playbooks fast enough that it matters (an agent can cause more havoc in the ten minutes before a human knows something is amiss than a compromised human account can do in a day).

The Four Control Surfaces for Agentic Zero Trust

Zero trust for AI agents is about enforcing access control for agents on four surfaces: identity, data, model, and output. Each one is unique, and never a single control, such as a firewall or API gateway, was going to be able to secure it alone.

Identity

The first step in identity verification for AI agents is ensuring each agent has an identity, rather than that of a human or a shared service account. That identity requires an owner, purpose, scope of access, and a complete log of the credentials attached to it; otherwise, an audit log can report on who performed a certain action, rather than whose API key it was executed with. If done without, attribution fails the second an issue arises, which is the very 68% issue that was mentioned above.

Data

The data surface refers to the data that can be read, retrieved, and written by an agent, but also, crucially, what is inserted into the agent's context window. Memory and context poisoning may be an attack surface if an agent trusts a data source that the attacker has seeded with content the agent should not have trusted, and the agent's subsequent decisions are influenced by this content. Data controls must check the data going into an agent's context as well as what it can query.

Model

A model surface restricts the kind of decisions the model can make without choosing what is actually technically possible for it to reason its way to. This is where prompt injection defenses, input sanitization and behavioral monitoring for goal drift come into play. Here, however, any controls on the model's ability to pursue an attacker's goal must be non-coherent and non-confident, or the model will sound coherent and confident while pursuing the goal.

Output

What an agent can actually do with its results depends on the output surface — write to a database, send an email, call a downstream API, etc. Where irreversible or high-consequence actions should have a human approval gate or a policy check that is independent of the model that generated the action, this is the last checkpoint before the action becomes a real action.

Architecture Patterns That Actually Enforce This

It really doesn't matter which of the four control surfaces you place the enforcement logic on as long as you do. Two patterns for architecture emerge, time and time again, in real deployments that are successful.

Enforcement at the Model Gateway, Not the Network Perimeter

More and more, runtime enforcement for AI agents is occurring at the model or agent gateway, instead of the traditional network perimeter, which is a point every tool call, API request, and MCP interaction must pass through. A gateway can verify the identity of the agent for each request, enforce policy prior to execution of a tool call, and create a complete audit trail – independent of what the agent's internal logic determined. Part of the reason is that from Google to Ping Identity, vendors have adopted some form of this pattern because a network perimeter sees the deviation of traffic from the building, but not whether a particular tool call is an action this agent should be taking right now.

Enclaves and "Virtual Chambers" for High-Value Assets

A complementary pattern is to use enclaves, network boundaries, with agents assigned to each project where agents assigned to one project cannot reach the tools, data, or other agents of another project across the network, at all. This is a structural guarantee, and one that cannot be "reasoned around" by an attacker. Sometimes the highest-value assets in an enclave get an extra layer, a virtual chamber: a boundary that prevents all traffic by default; even a correctly functioning agent within the enclave can't reach this asset without a separate explicit permission. Sandboxing agents like this into enclaves is more about architecture than hope the model will not be injected into.

Why the Enforcement Layer Must Sit Outside the Agent's Reasoning

All the above patterns have the same characteristic: they do not require the agent to impose anything upon itself. A prompt injection attack is an attack that tries to manipulate the reasoning of the model: any control that lives inside the reasoning — a "please don't do X" guardrail — is as trustworthy as the reasoning itself. Enforcement located at a gateway, at an enclave boundary, or at a policy engine outside the model does not know what the agent has decided internally; it only knows whether the requested action is allowed or not. This is the only version of zero trust that has survived the attacker who can do prompt injection.

How This Relates to CSA's Agentic Trust Framework and OWASP

The Cloud Security Alliance's Agentic Trust Framework (ATF) and the OWASP Top 10 for Agentic Applications are responding to two distinct sets of questions and shouldn't be confused, no matter how similar they might seem.

ATF as the Control Layer, MAESTRO as the Threat Model

Also published by CSA, MAESTRO threat modeling provides an answer to the question, "what could go wrong?": a seven-layer framework for discovering threats in an agentic system's architecture, from the base models all the way up to multi-agent orchestration. The CSA Agentic Trust Framework provides a response to a different question: "how do we stay in control. ATF's governance is divided into five elements – agent identity, data validation, behavioral monitoring, segmentation, and incident response – and a four-level maturity model – Intern through Principal – in which agents have earned their trust and autonomy through audited performance and not given it out of hand; and are automatically demoted after major incidents. Three of ATF's five elements govern the post-prevention, assume-breach principle directly to agent governance.

Mapping to OWASP Top 10 for Agentic Applications

The OWASP Top 10 for Agentic Applications, released December 2025, features 10 (Agentic Application Security) categories of risks (ASI01 to ASI10) which are based on actual events, rather than hypothetical ones. Several are directly applicable to the four control surfaces above: Identity and Privilege Abuse (ASI03) occurs on the identity surface; Memory and Context Poisoning (ASI06) occurs on the data surface; Agent Goal Hijack (ASI01) occurs on the model surface; and Cascading Failures (ASI08) occurs on the output surface when a bad decision cascades downstream. ATF explicitly matches OWASP's list; so taking ATF steps will also help contain most of OWASP's Top 10.

What the Major Vendors Are Doing

The vendor frameworks published in 2026 both share some of the principal ideas above regarding zero trust, but on entirely different levels.

Anthropic's Zero Trust for AI Agents Framework

In May 2026, Anthropic released its Zero Trust for AI Agents framework in the Claude blog, pointing out that perimeter security is not scalable for systems that understand goals, select tools, and execute multi-step actions using valid credentials. It includes the latest threat landscape of agents, such as prompt injection, tool poisoning, identity and privilege abuse, memory poisoning, and supply chain attacks, as well as a three-part maturity model, an eight-phase implementation process, and tips for security ops as agents accelerate at a new pace. It also mentions the 'blast radius' and 'least agency' framing that was mentioned above and states that Anthropic's own constitutional classifiers are able to block more than 95% of jailbreak attempts during testing.

Microsoft's Zero Trust for AI Initiative

Introduced in March 2026 and enhanced at RSAC 2026, Microsoft's Zero Trust for AI (ZT4AI) builds on Microsoft's zero trust workshop, adding a new AI pillar and updated Data and Network assessment tools, which encompass approximately 700 controls throughout the AI lifecycle, from data ingestion to agent behavior. It is used in conjunction with Microsoft Entra Agent ID, which provides agents a governed identity instead of borrowed credentials, and Agent 365, a control plane for governing agent activity across Entra, Purview and Defender. The essence of the risk it's trying to address, says Microsoft, is "double agents" with autonomy that makes them useful, but unmonitored makes them dangerous.

Implementation Checklist for Security Teams

The majority of the frameworks mentioned above agree on where to begin, although they may employ different terms to represent it. This is a realistic progression for a security team to follow when implementing agent access control:

• The majority of the time, shadow agents that are deployed via OAuth grants, browser extensions, or MCP integrations don't appear in a standard asset inventory.

• Avoid assigning agent-specific IDs, not borrowed IDs, and eliminate shared service accounts and personal API keys for agent workloads first - it's the one biggest leverage fix, as many incidents are attributable to the absence of an ID.

• Remove standing credentials; instead, conciseness and task-specific access that lasts only as long as the task.

• Place a gateway or policy engine between each agent and each tool; this means that the decision to enforce is made beyond the agent's reasoning, at the place where the tool call is actually executed.

• Not only to validate what the agent is authorized to query, but also to validate what enters agent memory and context to close the gap of memory-poisoning.

• Restrict to irreversible, high-consequence behaviors until an agent's track record is audited and found reliable enough to be allowed more autonomy.

• Do not build an "allow or deny" type switch, but rather a maturity path based on the number of years of service, allowing agents to gain greater access the longer they have served, while immediately losing access after an incident.

How Akto Enforces Zero Trust for AI Agents

The new beta version of Akto's Identity for AI Agents is designed to address the above identity surface gap. It doesn't simply treat an agent as another identity; it finds all of the credentials an agent uses, attributes them to the agent, the human who is accountable for them, and their actual access scope, expiry, rotation, and last activity, all the time. This is the "blended identity" pattern the identity community has coalesced around, where the agent's identity is verified and delegated by the human the agent is acting on behalf of, so neither can act without the other.

In addition to discovery, Akto has policies designed to reflect the way agents fail rather than to be written as generic identity policies: no admin credentials for agent identities, no cross-service credential reuse, no unapproved automation, and limited code execution permissions. If there is a break in policy, Akto records the severity of the violation, the user involved, and the extent of the blast (which systems have been compromised, what data has been exposed, what remediation might look like). With an identity and model control surface from one platform, Identity for AI Agents complements Akto's current agentic discovery, agentic guardrails, and prompt hardening features.

Final Thoughts on Zero Trust for AI Agents

AI Agents do not have a Zero Trust policy document; it is an architecture question of where Zero Trust exists. But the four checks - identity, data, model, and output — only hold if they occur before the agent applies his own thinking, in a gateway, or in a policy engine to which a prompt injection cannot talk his way through. All of the frameworks starting from NIST, CSA, OWASP, Anthropic, and Microsoft agree on one thing: Agents must first have their own verifiable identity for everything else to function.

Akto's first mission is to fill that gap. Identity for AI Agents finds ALL credentials used by your agents and associates, assigns them to a responsible individual and a true scope and applies policies that prevent over-privileged agents from becoming the next incident in your logs that cannot be attributed. If you already have agents in production without that foundation, request an Agentic security demo and experience Akto in your environment.

Frequently Asked Questions on Zero Trust for AI Agents

What is zero trust for AI agents, and how is it different from traditional zero trust?
For AI agents, zero trust means "never trust, always verify," switching from session-based trust to per-request verification. Traditional zero trust assumes that a human's intent remains constant for a session, while agentic zero trust assumes that it may vary because an agent's next intent can be influenced by the content he or she just read.

Why does traditional IAM break down when applied to autonomous agents?
Traditional IAM provides a one-time authentication and allows predictable access to a set of resources. A static access list doesn't foresee the agent's needs in the middle of the task or the agent reaching for a resource he or she shouldn't. Agents make hundreds of decisions within each session, and reach resources dynamically as they retrieve them from content.

What are the three core NIST SP 800-207 principles, and how do they apply to agents
Explicitly enforce least privilege and assume breach. Verify explicitly: re-check a cryptographic agent identity on each request; short-lived credentials: credentials are task-scoped rather than standing access; assume breach: agents are segmented by identity, so that if an agent is compromised, it cannot move laterally.

What are the four control surfaces in an agentic zero trust architecture?
Identity (who they are and who they are responsible to), Data (what they can read, retrieve, write, and what is their context window), Model (what they are allowed to decide), and Output (what they can actually do). Each surface requires individual controls as each surface fails in different ways.

Why can't an AI agent reliably enforce its own security against prompt injection?
Prompt injection involves altering the agent's reasoning; hence, it is considered a prompt. That control is part of that reasoning — a "please don't do X" guardrail — and therefore cannot be trusted more than the reasoning it is supposed to restrict. Enforcement needs to be at a gateway or policy engine beyond the model.

What is the Cloud Security Alliance's Agentic Trust Framework (ATF)?
An open governance specification that breaks down zero trust into five components: identify, validate data, monitor behavior, segment, and respond to incidents, and a four-level maturity model (from Intern to Principal), with agents' autonomy granted and revoked based on their actual performance, and automatically when an incident occurs.

How does ATF relate to MAESTRO and OWASP's Top 10 for Agentic Applications?
MAESTRO is a threat modeling framework that defines what can go wrong at seven layers of an agentic system. ATF is the governance level that helps to establish the controls necessary to keep these risks in check after discovery. Both are in line with the OWASP Top 10 for Agentic Applications.

What are "Virtual Chambers," and why do high-value assets need them even inside a trusted enclave?
A virtual chamber is a boundary that encloses one asset that has high value, to which all traffic is denied unless they pass through this boundary. Unlike enclaves, which prevent an agent of one project from accessing resources in another project, virtual chambers add an additional, explicit-grant-only layer to an enclave.

How many organizations can currently distinguish human activity from AI agent activity in their logs?
Just 32%. Sixty-eight percent of organizations surveyed could not clearly differentiate an AI agent's activity from that of humans in their logs in part due to the fact that 89% of organizations surveyed did not use a dedicated credential for their AI agents to run them on, but rather used a common service account or a workload identity supplied by humans.

What has Anthropic published on zero trust for AI agents?
Anthropic released its Zero Trust for AI Agents framework on the Claude blog in May 2026, which included the agent threat landscape, a three-tier maturity model, an eight-phase implementation workflow, and defensive operations designed for AI-accelerated attacks, as well as "blast radius" and "least agency" framing.

What is Microsoft's Zero Trust for AI initiative?
Zero Trust for AI (ZT4AI) was announced in March 2026 and expanded at RSAC 2026, adding a dedicated AI pillar to Microsoft's Zero Trust Workshop and approximately 700 controls throughout the AI lifecycle, including Microsoft Entra Agent ID for agent identity and Agent 365 as a governance control plane.

How does Akto enforce zero trust principles for AI agents in production?
Currently in beta, Akto's Identity for AI Agents identifies all credentials that an AI agent accesses, links them to the agent, the responsible human, and the actual range of the agent's activities, and applies policies designed around how agents fail, alerting to violations in real time in full "blast radius" detail.