Article

How do you extend Zero Trust to AI agents?

Susanne Elizer Senoff

CISO, Conga

Consider the traditional “Zero Trust Architecture (ZTA)” concept. In it, the network is presumed hostile, so we have to decide what requests go through by using authentication and authorization.

An AI agent breaks this pattern in a way we haven’t seen before. Not only is the network still presumed compromised, the request itself can carry a malicious payload by hiding inside a correctly authenticated and scoped agent. In other words, a verified caller with an untrusted call.

What does it mean to extend Zero Trust to agents, then? We need to travel farther up the chain and seek the party accountable. In practical terms, authorization decisions have to move in front of tool invocations, rather than in front of the agent itself. The question stops being "is this agent trusted?" and becomes "should this specific call, with these specific arguments, against this specific data, be allowed right now?"

Now let’s understand how it’s done, and where the failure points are.

The assumption Zero Trust was built on

In August 2020, NIST SP 800-207 defined Zero Trust Architecture, relocating the trust decision from network position to a policy engine that evaluates identity, device, and context, and grants a session with a scope.

Written before the agentic AI era, the document’s approach to Non-Person Entities implies deterministic workloads with requests driven by their own code, and does so inside a section on threats rather than architecture. It also concludes that authentication for such components is “an open issue”.

In a world in which only such entities exist, trusting the entity making the request is trusting the intent of the human who built it. Authentication and authorization come hand in hand, as a single security decision.

With agents, this approach no longer works.

We’re in uncharted territory

It’s not a subject; it’s a chain

Let’s focus on a single tool call:

A person delegated the task.
An agent instance is executing it.
There might be sub-agents spawned by the main agent.
The platform that hosts the harness adds its own intent.
An MCP server can be involved, with APIs sitting behind it.

All these subjects have to be evaluated, rather than one subject with a single attribute set, as in traditional ZTA. Not all of it appears in the logs, so it is difficult to determine which agent updated a customer record when the logs show a token or a service account.

OAuth can help, somewhat. Its token exchange lets clients exchange a token for one that’s scoped, restricted, and records who acts on whose behalf. But the “prior actors” part of the act chain is informational, and shouldn’t be used when making access control decisions. In other words, it’s an audit trail, not an authorization primitive.

There are efforts to move OAuth into the agentic era. If you want to see what the future might look like, see OAuth Identity and Authorization Chaining Across Domains, which has already cleared the working group.

A verified identity no longer implies an authorized intent

Prompt injection, poisoned tool descriptions, and memory poisoning are some of the techniques that let an attacker author requests within a credentialed session. The action can even fall inside the agent’s granted scopes. A typical Zero Trust policy engine will evaluate the identity, device, and context of this action, then return “allow”.

OWASP's Top 10 for Agentic Applications, published in December 2025, treats this as ASI01, Agent Goal Hijack. ASI06, Memory and Context Poisoning, is also relevant.

Enforcement runs inside the thing you don't trust

Common agent deployments enforce policies through mechanisms such as tool allowlists in the agent configuration, rules in the system prompt, and confirmation dialogs in the client. In other words, they gate capabilities. And these gates can fail, as evidenced by confused-deputy research where input reasons its way around them.

And while MCPs are somewhat better about enforcement, their authorization spec applies only to HTTP transports. STDIO implementations retrieve credentials from the environment, and hold whatever access the environment gives them.

Pillar by pillar: humans, machines, agents

Token's Zero Trust for machines maps each Zero Trust pillar from its human implementation to its machine equivalent. Agents need a third column.

Pillar	Human	Machine	AI Agent	What Changes
Identity verification	MFA, SSO	Certificates, tokens, mTLS	Instance identity plus a delegation chain	mTLS proves the workload is what it claims. It says nothing about who authored the request the workload is carrying.
Least privilege	Role-based access	API scoping, workload policy	Per-call authorization on tool and arguments	A static scope cannot express "this customer's records, not the other 40,000."
Continuous authentication	Session expiry, adaptive MFA	Token rotation, certificate validation	Re-authorization per action	Machines re-verify per session. Agents change what they are doing inside a session.
Workload trust	Device posture	Workload posture, integrity validation	Provenance of tool descriptors and MCP servers	The runtime is trustworthy and its input is not, so posture checks pass while the instruction set is hostile.
Behavioral monitoring	UEBA	API and workload baselines	Comparison of action against stated intent	Agent behavior is legitimately non-deterministic, so a deviation from baseline is weak evidence on its own.
Lifecycle governance	HR-driven joiners and leavers	Certificate and secret orchestration	Named owner per agent and per sub-agent	Sub-agents create identities that no provisioning system issued.

Tenet by tenet: what transfers, what needs rewriting

The seven tenets in SP 800-207 §2.1 are another prism through which you should review the posture. These are “the ideal goal”, so not all of them will be fully implemented.

SP 800-207 Tenet	Status for Agents	What It Now Requires
1. All data sources and computing services are resources	Transfers	Tools, MCP servers, and agent memory (to which an attacker can write) have to be added to the resource inventory.
2. All communication is secured regardless of network location	Transfers	Unchanged.
3. Access is granted on a per-session basis	Needs rewriting	With agents, a session is the wrong unit. A single session can include numerous tool calls, which in themselves need to trigger trust decisions.
4. Access is determined by dynamic policy including the observable state of client identity, application, and requesting asset	Needs extending	The delegation chain, the tool being called, the arguments, and the classification of the data those arguments touch should be added.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets	Needs extending	Extend this monitoring from the agent runtime to the tool supply chain. Include descriptor provenance, MCP server identity, and change detection on them.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed	Transfers	Enforcing outside the agent runtime, as that part can be under attack.
7. The enterprise collects as much information as possible and uses it to improve its security posture	Transfers	You’ll need to log prompts, planning, and tool calling with an attribution chain to understand why an action took place rather than just see that it did.

Extending Zero Trust

An identity per agent instance

Ideally, each agent wields identities provisioned for them, rather than those provisioned for humans or shared service accounts.

Runtime-attested workload identities are a great option, since SPIFFE (Secure Production Identity Framework For Everyone) and SPIFFE Runtime Environment (SPIRE) do node and workload attestation before issuing an SVID. Do it, and the identity will derive from the workload, with automatic rotation and short default lifetimes.

Preserve the delegation chain

An auditor should be able to understand several things from the credential itself, without any configuration files.

The first is the delegation chain. For this, use tokens issued through token exchange, so each action includes a record of the person who requested it.

Then there’s the resource the credential has access to. Under the MCP spec, clients send a resource parameter naming the server they intend to use the token with, and servers reject tokens not issued for them.

A policy decision point outside the agent

Ideally, there should be a policy engine in front of every tool call, using a gateway or broker. These need to take into account the agent identity, delegation, the tool itself, the arguments, the classification of the data behind these arguments, and the agent’s previous actions. This way, the decisions are made by the policy engine, not an agent that could’ve been talked into misuse.

This way, you’re also defragmenting your policies. Rules scattered across APIs, IAM, agent configs, and more can be consolidated.

Segmentation by tool and record, not by network

An agent's network position tells you nothing. It reaches every system over HTTPS through an API, so that’s the surface that matters. You need to know the agent’s reach in both directions: corporate data and the open web. For example, read access to the DB and an outbound HTTP tool together equal an exfiltration path that won’t be flagged unless both are taken into account.

Containment sized to one instance

Let’s say one agent identity is compromised. What will it reach before anyone notices? This is how you do containment. You need rate and volume caps, as well as revocation that’s granular enough to work on a single instance. And of course, your kill switch has to be tested.