Your buyers have already picked a side. Here's how to engage either one without losing the room.
Two practitioner positions on AI agent identity are circulating in federal security circles right now, and they're not reconciling anytime soon. The first says Zero Trust already handles agents — they're non-human identities, and the framework's primitives apply as written. The second says agents are different enough — dynamically scoped, indirectly authorized, and susceptible to instruction manipulation at runtime — that the existing framework's verification model doesn't reach the actual threat. You'll encounter both positions in the same week, sometimes in the same agency. The language you use in the first two minutes of that conversation determines whether you're a peer or a vendor.
Camp A: Zero Trust Applied Consistently
What it is: The position that AI agents are non-human identities, and Zero Trust already specifies how to handle non-human identities.
What it does: Camp A argues that the framework's core principles — verify explicitly, least privilege, assume breach — apply to agents exactly as they apply to service accounts, APIs, and automated pipelines. The work is implementation discipline, not framework invention. An agent needs an identity. That identity needs to be issued, scoped, monitored, and rotated. Privileged access gets time-bounded. Lateral movement gets detected. The underlying logic doesn't change. You're applying the same principles at higher scale and velocity.
Practitioners in this camp tend to point to service account sprawl as the more urgent problem. Most federal environments already have thousands of unmanaged non-human identities with excessive privilege and no rotation policy. Agents will inherit whatever hygiene — or lack of it — exists for those accounts. Fix the foundation before you build a new framework on top of it.
The Camp A position also carries a practical skepticism about framework proliferation. Every new category of "special" identity that gets its own bespoke controls adds complexity, and complexity is where security fails. If agents get a separate framework, so will the next category, and the one after that. The principle of consistent verification exists precisely to prevent this.
Who's behind it: This view is well-represented among federal security architects who've spent years managing non-human identity at scale — the people who built the service account governance programs, the PAM deployments, the API gateway policies. It surfaces in NIST's ongoing work on AI system security, which frames agent identity as a specialization of existing non-human identity guidance rather than a departure from it. The Cloud Security Alliance's non-human identity working group has published similar framing. At RSA 2025, several practitioners from federal civilian agencies made this argument explicitly: the tooling exists, the gap is adoption.
What makes it distinct: Camp A's claim is about sufficiency. The framework already works. The gap is enforcement, not specification. If your Zero Trust controls are mature, agents fit inside them. If they're not, a new framework won't save you.
Callout: The Service Account Analog
Service accounts are the closest existing analog to agent identities — non-human principals with scoped credentials, defined permissions, and (ideally) rotation schedules. Camp A's argument holds well here: the lifecycle management primitives that apply to service accounts apply directly to agents. Where it breaks: a service account executes a defined, predictable set of operations. An agent interprets instructions at runtime, and those instructions can come from sources outside the original authorization context. The service account analog is useful for credential lifecycle conversations. It stops being useful the moment a buyer asks what happens when the agent reads a document that tells it to do something its credential technically permits but its operator never intended.
Camp B: Agents Need Their Own Framework
What it is: The position that agents' dynamic scope, indirect authorization chains, and susceptibility to runtime instruction manipulation create verification problems that Zero Trust's current specification doesn't address.
What it does: Camp B's argument starts with a specific claim about what "verify explicitly" actually requires. Verification assumes you can characterize the entity making the request at the time it makes the request. For a service account or an API client, that's tractable: the identity is stable, the scope is defined at credential issuance, and the behavior is predictable within that scope. For an agent, none of those assumptions hold cleanly.
An agent's effective scope (what it will actually do with its credentials) is shaped by the content it processes at runtime. That content can come from sources the authorizing party never reviewed: documents, web pages, tool outputs, messages from other agents in a multi-agent pipeline. If that content contains instructions that redirect the agent's behavior, the entity executing the request is not the entity that was verified at authentication time. Camp B calls this the authorization gap: the credential is valid, the scope is technically correct, and the action is still unauthorized in any meaningful sense.
The second part of Camp B's argument is about indirect authorization. In agentic workflows, a human authorizes an agent to act on their behalf, and that agent may spin up sub-agents, call tools, or delegate further. The authorization chain lengthens with each hop, and the original authorizing party has no visibility into what's happening at the end of it. Zero Trust's assume-breach posture helps, but Camp B argues it doesn't specify how to verify that the entity at the end of a multi-hop chain is still acting within the intent of the original authorization — only that you should assume it might not be.
The OWASP LLM Top 10 lists prompt injection as the top threat to LLM-based applications, and Camp B treats this as an identity problem, not just an application security problem. If an agent can be redirected by injected content, the identity layer needs primitives for detecting and responding to that redirection — primitives that don't currently exist in Zero Trust's specification.
Who's behind it: AI security researchers, the practitioners building multi-agent systems in production, and the red teams who've demonstrated agent compromise in controlled environments. The OWASP LLM Top 10 working group has been the most systematic in documenting the threat surface. Researchers publishing on indirect prompt injection — the variant where injected instructions arrive through data the agent retrieves rather than direct user input — have made the strongest technical case for Camp B's position. A February 2026 thread on Hacker News, where a researcher who contributed to the IETF OAuth working group walked through the authorization chain problem in multi-agent systems, is worth reading because it's one of the cleaner articulations of why existing OAuth delegation primitives don't fully solve the problem. (The thread also has a useful counterargument in the replies from a practitioner who's deployed agents in a federal environment — the disagreement is genuine and the fault line is visible.)
What makes it distinct: Camp B's claim is about adequacy. The framework's principles are right, but its current specification assumes a stable, predictable entity. Agents aren't that. New verification primitives are needed — specifically, mechanisms for detecting runtime instruction manipulation and constraining authorization chains across agent hops.
Callout: The OAuth Delegation Analog
OAuth's delegation model — a user authorizes a client to act on their behalf within a defined scope — maps reasonably well onto the human-to-agent authorization pattern. The token carries the scope, the scope constrains what the client can request, and the authorization server sits between the client and the resource. Camp B's argument doesn't dispute this; it asks what happens after the token is issued. OAuth scope defines what the agent can request. It says nothing about what the agent will actually request based on the content it processes at runtime. In a buyer conversation about agent authorization, this distinction matters: if the buyer's mental model is "we'll use OAuth and scope it tightly," the follow-up question is how they're handling the gap between what the scope permits and what the agent actually does.
Comparison Strategy
The structure here is trait-led analysis across three dimensions where the camps genuinely diverge: identity model, threat model, and tooling adequacy. Scenario mapping would work if the goal were to show how each camp handles a specific situation, but scenario choice editorializes, and the brief is explicit that this piece shouldn't. A flat A/B table loses the nuance of where the camps agree (they agree on more than the debate suggests). Trait-led analysis lets both camps appear on every relevant dimension without the scenario bias.
Identity model. Camp A: agents are non-human identities, full stop. The identity model is the same as for any other non-human principal — issue a credential, scope it, monitor it, rotate it. Camp B: agents are non-human identities with a runtime behavior layer that the identity model doesn't currently reach. The credential is necessary but not sufficient to characterize what the agent will do.
Threat model. Camp A: the primary threats are the same as for any non-human identity — credential theft, excessive privilege, lateral movement, lack of visibility. The assume-breach posture handles these. Camp B: the primary threats include those, plus a category that doesn't exist for other non-human identities — runtime instruction manipulation that redirects agent behavior within the bounds of a valid credential. Camp A's threat model is a subset of Camp B's.
Tooling adequacy. Camp A: existing PAM, IGA, and SIEM tooling, applied consistently to agent identities, covers the gap. The work is configuration and governance, not new tooling. Camp B: existing tooling handles credential lifecycle and access control, but has no primitives for detecting prompt injection, constraining multi-hop authorization chains, or monitoring agent behavior at the semantic level. New tooling is required, and the field is early in building it.
The camps share more than the debate implies. Agents need identity. Least privilege applies. Both camps would endorse those statements without argument. Current agent deployments are bad on both counts: unmanaged credentials, excessive scope, no rotation, no monitoring. The debate about whether new primitives are needed is a second-order question. In a buyer conversation, this means you can almost always find common ground on the immediate work, regardless of which camp the buyer is in.
Callout: Where Both Camps Agree
Neither camp disputes that the current state of agent identity in most organizations is poor. Agents are running with overprivileged credentials, no rotation, and no monitoring — the same problems that plagued service accounts a decade ago. Both camps would endorse the same first-order remediation: inventory your agent identities, scope their credentials to least privilege, implement rotation, and add them to your IGA workflows. The debate about whether new primitives are needed is a second-order question. In a buyer conversation, this means you can almost always find common ground on the immediate work, regardless of which camp the buyer is in.
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "Agents are just service accounts with extra steps." | "Most teams start with service account controls as the baseline — what's your current approach to scoping what those accounts can do at runtime?" | Validates their frame without closing off the runtime behavior question. |
| "Zero Trust already covers this if you apply it correctly." | "Zero Trust gives you the principles. The implementation question for agents is specifically how you verify an entity whose behavior can be shaped by the content it processes." | Accurate to both camps; surfaces the specific challenge without taking a side. |
| "You need a whole new framework for AI agents." | "What specific gaps are you seeing in your current controls — is it the identity layer, the authorization layer, or something at the behavior level?" | Surfaces what they're actually worried about before you position anything. |
| "Prompt injection is an application security problem, not an identity problem." | "Prompt injection is where the identity and application security layers collide — the question is whether your identity controls can account for an agent that's been redirected mid-task." | Keeps the conversation in your lane without dismissing a real threat. |
| "OAuth is fine for agent authorization." | "OAuth handles the delegation piece well. The open question is whether token scope can constrain what an agent actually does, or whether that's a separate enforcement problem." | Accurate, surfaces the real gap, doesn't overclaim. |
| "That vendor's 'AI-native Zero Trust' is just marketing." | "Worth asking them specifically what primitives they've added beyond standard non-human identity controls — the answer will tell you whether they're solving a real gap or repackaging existing capability." | Positions you as technically credible without endorsing or dismissing the vendor. |
| "You can't wait for standards to mature — agents are already in your environment." | "What's your current posture on non-human identity while you wait? Agents will inherit whatever controls you have in place for service accounts and APIs today." | Moves the conversation to immediate action without being alarmist. |
| "MCP is an identity protocol." | "MCP defines how agents communicate with tools — the identity and authorization layer sits above it. The question is what controls you're enforcing at that layer before the MCP call happens." | Technically accurate; positions the identity conversation correctly. |
| "Some practitioners disagree with your CISO's position." | "The implementation question is specifically how you verify an entity whose behavior can be modified by the content it processes — that's where teams are working out the details." | Validates the CISO's frame while surfacing the specific challenge without creating a confrontation. |
| "Okta thinks agents are just non-human identities." | "Okta's public position is that agents are non-human identities that need the same lifecycle management as any other identity. The harder question your team will face is what to do about runtime behavior. The field is still working that out." | Accurate to Okta's public position; honest about what's unsettled. |
| "The agent identity debate is mostly theoretical." | "The credential hygiene piece is solvable today with existing tooling. The runtime behavior piece is where practitioners are still building the controls. Both are real problems at different stages of maturity." | Separates the tractable from the unsettled without dismissing either. |
| "Your team needs to pick a side on this." | "The two positions aren't mutually exclusive. It's a sequencing question: which problems in the next six months, which in the next two years." | Reframes the debate as a sequencing question, which is where the actual work lives. |
The field is moving. The IETF OAuth working group has active discussion on authorization for agentic systems. NIST's AI risk management work is starting to address agent identity specifically. The OWASP LLM Top 10 is in its second revision cycle. None of this has produced a settled answer yet, and a buyer who tells you the debate is resolved, in either direction, is working from a snapshot that's already out of date.
What you can say with confidence: the first-order work is the same regardless of which camp your buyer is in. Inventory the agents, scope the credentials, implement rotation, add them to your IGA workflows. The second-order debate — whether new primitives are required for runtime behavior — is real, technically substantive, and genuinely unsettled. Knowing the difference between those two layers is what lets you stay in the room when the CISO and the red team lead are arguing past each other.