Where Zero Trust Transfers to AI Agents and Where It Breaks

Zero trust for human users is a framework your buyers have been building for years. Zero trust for AI agents is what their CAIO or CISO is now asking about, usually because an OMB memo landed and someone two levels up wants to know if the agency's ZT architecture covers the agents that just got approved. You will encounter both in the same conversation. The sentence that buys you in: "Zero trust principles apply to agents. Whether the existing ZT mechanisms are sufficient is the open question."That positions you as someone who's read the room. It also happens to be true.

Zero Trust for Humans

What it is. Continuous, context-aware verification of human users across four signals: identity, device health, network position, and behavioral baseline.

What it does. Every access request triggers a policy evaluation. Who is this person (MFA, identity proofing)? What device are they on (EDR status, patch level, MDM compliance)? Where are they connecting from (network segment, geolocation)? Does their behavior look normal (session risk, UEBA baseline)? Access is granted per-request, scoped to least privilege, and subject to continuous re-evaluation — every request, every time.

Who's behind it. NIST SP 800-207 is the foundational architecture. OMB M-22-09 mandates it for federal civilian agencies, requiring phishing-resistant MFA, consolidated identity management, and endpoint detection across all authorized devices. CISA's ZTMM v2.0 operationalizes it across five pillars with maturity stages from Traditional through Optimal. The DoD Zero Trust Reference Architecture and DISA's implementation work extend the same principles into defense environments. Your buyers have been living inside these documents.

What makes it distinct. Every verification signal refers to something stable and observable. The human presents a valid credential or doesn't. The device passes a health check or doesn't. The behavioral baseline holds or it deviates. A human can be phished, coerced, or socially engineered. But a human cannot be silently reprogrammed mid-session by a document they happen to read.

Zero Trust for AI Agents

What it is. The attempt to apply continuous, context-aware verification to software entities that authenticate to systems, call tools, and take actions on behalf of humans, autonomously, or in chains with other agents.

What it does. In theory, the same thing: verify the agent's identity, assess its execution environment, enforce least privilege, monitor behavior. In practice, each of those steps hits a gap that doesn't exist for humans. Most agents today authenticate using static client credentials designed for service accounts. They carry no user context downstream. They rely on long-lived API tokens with broad access. Tooling to close these gaps is arriving, but production implementations remain scarce.

Who's behind it. Multiple standards efforts are active and none are finished. The IETF WIMSE working group addresses workload identity across service boundaries. The IETF AIMS draft (March 2026) proposes composing existing OAuth and SPIFFE standards for agent authentication. The OWASP Agentic Top 10 (December 2025) defines the risk taxonomy, covering failures from goal hijacking through delegated trust to emergent autonomous behavior.

What makes it distinct. An agent's behavioral scope can be altered at runtime by content it processes. A properly authenticated, correctly credentialed agent can be redirected through prompt injection to act outside its intended policy without any change to its identity or access tokens. No credential compromise required. The AIP draft treats this as an identity problem, because the agent still holds valid credentials while acting against its owner's intent. It is an identity problem.

Four Verification Signals, Two Very Different Subjects

I'm organizing this around the four verification signals that define human ZT: identity, device posture, network context, and behavioral signals. Your buyers already carry this structure in their heads from CISA ZTMM, which makes it the fastest way to show where the framework transfers and where it doesn't. It also surfaces the two buyer camps naturally, because the camps disagree about what the gaps mean.

Identity

Your OAuth and SAML intuition helps here. An agent can be registered as a first-class identity in a directory, assigned a human owner, given lifecycle governance, and de-provisioned when no longer needed. Microsoft Entra Agent ID frames agents as "digital teammates" managed with the same controls as employees. The SCIM extension draft (October 2025) argues existing provisioning standards can accommodate agents without new protocols, proposing two new SCIM resource types for agents and agentic applications. If you know how to govern a service account, you know the mechanics.

Now for where that intuition misleads you. A human's identity captures who they are. An agent's directory record doesn't capture what it's currently doing. An agent whose system prompt has been altered by indirect prompt injection still holds a valid, registered identity. The directory says "this is Agent X, owned by Jane, authorized for these scopes." It cannot say "Agent X is currently behaving as intended." Registration proves the agent is known. It says nothing about whether the agent is acting like itself.

Device Posture → Workload Attestation

There is no device. The equivalent is workload attestation, which verifies the agent's execution environment rather than a physical endpoint. SPIFFE/SPIRE, a CNCF graduated project now referenced in NIST 800-207A, handles this for cloud-native workloads: each agent gets a cryptographic identity derived from what the workload is and where it's running, not from a stored secret. Identities are short-lived (typically one hour, configurable to minutes) and automatically rotated. The security math is simple: a compromised one-hour credential has a blast window of 60 minutes. A compromised one-year API key has a blast window of 8,760 hours.

The logic maps cleanly. Before a human accesses a resource, you verify their device. Before an agent accesses a resource, you verify its runtime environment. SPIFFE attestation checks the Kubernetes namespace, service account, and container image, much like EDR checks the OS version, patch state, and security agent status.

The analogy stops bearing weight at the boundary between environment and behavior. Device posture can tell you a laptop has a keylogger installed. Workload attestation cannot tell you an agent's context window contains an injected instruction to exfiltrate data. A clean execution environment tells you nothing about what's sitting in the agent's context window. Current SPIFFE models may need revision to support entities whose behavior is determined partly by inference-time inputs, not just deployment configuration.

Network Context → Delegation Chains

Agents don't sit on network segments the way humans do. The equivalent constraint is the delegation chain: when a user delegates to a copilot, which calls an autonomous agent, which invokes a downstream tool, each hop should carry appropriately scoped authorization. The correct pattern is token exchange with scope reduction at each hop (each step in the chain gets a narrower token than the one before it). The common failure is token passthrough, where the original user's token gets forwarded downstream unchanged, granting the tool the user's full permissions.

The principle is identical to micro-segmentation: prevent lateral movement, enforce least privilege at every boundary. The mechanism is where things get uncomfortable.

No existing standard cleanly expresses multi-hop delegation chains with scope reduction at each step. The IETF Agentic JWT draft names this the "intent-execution separation problem": OAuth captures user consent at a point in time, but an autonomous agent may take hundreds of actions per session on the basis of that single consent moment. Cross-trust-domain delegation (your enterprise agent calling a third-party agent outside your identity provider) has no settled mechanism. And audit logs in most deployments attribute agent actions to human accounts rather than to agents, which makes incident investigation a forensic puzzle.

Behavioral Signals

The concept transfers perfectly. You should monitor agent behavior, establish baselines, flag anomalies. The OWASP Agentic Top 10 calls for "strong observability" with "detailed logging of goal state, tool-use patterns, and decision pathways." Nobody disputes this.

The tooling doesn't exist at production scale. UEBA for humans is a mature market with deployed products and years of baseline data. Behavioral analytics for AI agents is a requirement in frameworks and a bullet point in vendor roadmaps. A proposed NHI governance framework includes behavioral monitoring as one of five pillars. The word "proposes" is doing all the work in that sentence.

And "assume breach," the third ZT principle, hits hardest right here. For humans, assume breach means you design for the case where credentials are stolen. For agents, it means you design for the case where the agent's context window has been compromised by injected content. The AIP draft's "block" action, an unconditional deny for specified tools that cannot be overridden by any model output, injected prompt, or delegation claim, is what assume-breach enforcement looks like for agents. Policy enforcement at the tool boundary, downstream of identity. When a buyer talks about "continuous monitoring for agents," the honest follow-up is: "What are you using for that today?" The answer, in most cases, is logs.

The Two Camps

These four dimensions surface a genuine disagreement in the buyer community. Recognizing which camp your buyer occupies is more useful than having an opinion about which camp is right.

Camp 1: "ZT is ZT. Apply it consistently." This camp holds that zero trust principles are identity-type-agnostic. Register agents as first-class identities. Issue short-lived credentials. Scope their access. Monitor their behavior. The frameworks already anticipated non-human entities: NIST 800-207 uses "subject," not "user," throughout. CISA ZTMM defines identity as including "non-person entities." The IETF AIMS draft builds on existing OAuth and SPIFFE standards rather than proposing new protocols. Microsoft, Okta, and the CSA Agentic Trust Framework all take this position. You'll hear it from buyers who run mature ZT programs and see agents as the next identity type to onboard.

Camp 2: "Agents are architecturally different." This camp holds that agents introduce risk categories existing ZT mechanisms can't address. Prompt injection means an agent's scope can be altered by content it reads, without any credential compromise. The intent-execution separation problem means OAuth consent doesn't track to real-time agent actions. Multi-hop delegation chains accumulate permissions without explicit authorization records. Behavioral monitoring tooling doesn't exist at scale. The OWASP Agentic Top 10 exists precisely because the existing LLM Top 10 was insufficient for agentic risks. Academic researchers argue explicitly that existing IAM protocols are "fundamentally inadequate." OWASP extends least privilege to "least agency", limiting how much autonomy an agent has to act on its access without checking back. You'll hear this from buyers who've started deploying agents and discovered that identity governance alone doesn't prevent an agent from being talked into things.

Both camps agree on more than they'd admit. Agents need first-class identities, short-lived credentials, human ownership, scoped authorization, and audit trails. The disagreement: Camp 1 treats those mechanisms as the full answer. Camp 2 treats them as table stakes — required, yes, and wildly incomplete.

The buyer who says "we just need to extend our ZT architecture to cover agents" is Camp 1. The buyer who says "we need to rethink our security model for agentic workloads" is Camp 2. Both are telling you something real about where they are in their deployment.

How to Say This in the Field

Don't say	Do say	Why it matters
"Zero trust works the same way for agents as it does for humans."	"The ZT principles transfer. Some of the mechanisms don't, yet."	Acknowledges the gap without overpromising.
"Agents are just non-human identities."	"Agents are non-human identities with a property service accounts don't have: their behavior can be changed by their inputs."	Names prompt injection risk without jargon.
"You need a whole new framework for agent security."	"The identity layer transfers. The behavioral layer is where the open questions are."	Positions you between the camps.
"We handle agent identity the same way we handle service accounts."	"Agent identity registration works like service accounts. Agent authorization is harder because scope can change at runtime."	Separates authentication (solved-ish) from authorization (unsolved).
"Prompt injection is an AI problem, not an identity problem."	"Prompt injection is an identity problem because a redirected agent still holds valid credentials."	Connects the AI risk to the buyer's ZT investment.
"Our ZT architecture already covers this."	"Which of the four ZT signals — identity, device posture, network context, behavior — are you extending to agents today?"	Turns a claim into a diagnostic question.
"SPIFFE solves agent identity."	"SPIFFE solves workload attestation. It proves the agent is running where it should. It can't tell you whether the agent is doing what it should."	Precise about what's solved and what isn't.
"We need continuous monitoring for agents."	"What are you using for agent behavioral analytics today? The tooling isn't where UEBA is for humans."	Honest about the maturity gap.
"Least privilege applies to agents."	"Least privilege applies. OWASP extends it to 'least agency' — limiting how much autonomy the agent has to act on that access."	Introduces a concept the buyer may not have encountered.
"The delegation chain is handled by OAuth."	"OAuth handles one hop well. Multi-agent chains where each step should get a narrower token than the last: that's an open standards problem."	Names the specific gap.
"We're ready for agentic AI."	"Are you deploying user-delegated copilots, autonomous agents, or multi-agent chains? The controls that matter depend on the pattern."	Forces specificity before you commit to a position.

The buyer deploying a user-delegated copilot that inherits the human's permissions is facing a different problem than the buyer running autonomous agents with their own credentials. Both are in a different world from the buyer orchestrating multi-agent chains. Ask which deployment pattern they're building before you talk about which controls apply. The ZT dimensions that strain hardest depend entirely on which pattern is in play.