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.
Okta for AI Agents extends Universal Directory to register agents as first-class identity records with human ownership, including a kill switch that deactivates the agent without affecting the human owner. Where it breaks: Universal Directory was designed for entities with stable identities. An agent's behavioral configuration can change mid-session without changing its directory record. Registration is where governance starts. What happens after registration is the harder problem.
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.
Okta's Cross App Access (announced June 2025) uses OAuth-based token exchange to scope agent-to-app and agent-to-agent authorization with short-lived, audience-restricted tokens (tokens only valid at the specific downstream service they're intended for). Where it holds: within the Okta trust domain, this addresses the delegation chain problem directly. Where it breaks: cross-organization agent delegation, where the downstream service doesn't validate Okta-issued tokens, remains open. This is an industry gap, not an Okta-specific one.
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.
Okta's ISPM discovers AI agents through browser-captured OAuth signals and managed app integrations, including agents built on Salesforce Agentforce. The shadow-app discovery pattern extends naturally to shadow agents. Where it breaks: agents deployed with API keys, service account tokens, or direct database credentials are invisible to this approach. Machine identities outnumber human identities by orders of magnitude in enterprise cloud environments. The vast majority operate outside any formal discovery scope.
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.
Things to follow up on...
-
IETF agent auth drafts: The AIMS draft and the Agentic JWT draft take opposite positions on whether existing OAuth standards are sufficient for agent delegation, and both are active Internet-Drafts that expire within six months of publication.
-
OWASP's "least agency" concept: The OWASP Top 10 for Agentic Applications introduces least agency as an extension of least privilege, limiting not just what an agent can access but how much autonomy it has to act without human approval, which is a framing your buyers may start using before vendors adopt it.
-
SCIM for agent provisioning: An October 2025 IETF draft proposes two new SCIM resource types for agents and agentic applications, which would bring agent lifecycle management into the same provisioning standards enterprises already use for human identities.
-
SPIFFE's agent-shaped gap: Solo.io's analysis of whether SPIFFE can work for AI agents concludes that current workload attestation models may need revision to support entities whose behavior is determined at inference time rather than deployment time.

