Most enterprise identity programs can tell you exactly who has access to what: which humans hold which roles, which service accounts are attached to which systems, and which certificates expire when. Ask those same programs to tell you what your AI agents are authorized to do, under whose identity they operate, and who is accountable when one of them takes an action it shouldn’t - and the answer is usually silence.

That gap is now a recognized governance problem, not a theoretical one. NIST’s Center for AI Standards and Innovation launched a formal AI Agent Standards Initiative in February 2026, and the OWASP Agentic Top 10 - published in December 2025 - placed identity and privilege abuse as the third most critical risk across all agentic AI deployments. Both frameworks point at the same root issue: organizations are deploying agents as if they were tools, not principals.

Why Agents Are Not the Same as Service Accounts

The instinct to treat AI agents like traditional service accounts is understandable. Both use credentials. Both automate tasks. Both operate without direct human interaction. But the analogy breaks down quickly when you examine what agents actually do.

A conventional service account has a fixed, well-defined function: it connects to a database, runs a scheduled report, or polls an API. Its actions are deterministic. An AI agent, by contrast, is goal-directed. Given an objective, it determines its own action sequence, selects tools to call, and may spin up sub-agents to delegate portions of the work. Its behavior at runtime is not fully specified at design time.

This creates a category of identity problem that existing frameworks were not built to handle. The credentials an agent holds are not just keys to specific systems - they represent a delegated authority to reason, plan, and act. When you grant an agent OAuth tokens or API keys scoped to your CRM, your email system, and your document store, you are not authorizing a sequence of predefined operations. You are authorizing whatever sequence of operations the agent decides is necessary to complete its goal.

NIST’s NCCoE project on Software and AI Agent Identity and Authorization is examining precisely this problem: how do existing identity standards - OAuth 2.0, OIDC, SAML, federated identity protocols - need to extend or adapt to govern agents that operate continuously, chain actions across systems, and may delegate authority to downstream agents.

OWASP Agentic Top 10: The Identity-Centric Risks

The OWASP Top 10 for Agentic Applications (2026) emerged from review by over 100 security researchers and practitioners. Three of the top four entries are directly tied to identity and delegation.

ASI03 - Identity and Privilege Abuse is the entry that captures the core problem most directly. OWASP defines it as exploiting inherited or cached credentials, delegated permissions, or agent-to-agent trust to escalate access and bypass controls. An agent’s identity, in this framing, encompasses its persona and all associated authentication material - API keys, OAuth tokens, delegated user sessions. When an agent is compromised or manipulated, every credential it holds becomes an attack vector.

ASI07 - Insecure Inter-Agent Communication addresses what happens as agent architectures grow more complex. Multi-agent systems - where orchestrators delegate to sub-agents, which may delegate further - create delegation chains where trust assumptions accumulate and become difficult to audit. An action taken four delegation hops from the original human authorization may bear no meaningful relationship to what was actually consented to.

ASI09 - Human-Agent Trust Exploitation covers the governance side of the same problem: humans over-relying on agent outputs and approvals, enabling agents to effectively operate with more authority than was formally granted. This is the behavioral complement to the technical delegation risks.

OWASP’s framing matters for governance programs because it shifts the question from “what can this agent access?” to “what is this agent’s identity, and under whose authority does it act at each step of its operation?”

Federated vs. Managed Service Models

Organizations building out agent identity governance are converging on two broad approaches, each with different tradeoffs.

The federated model treats each agent as a distinct identity principal, issued its own credentials scoped to its specific function. Agents authenticate to services directly, and their permissions are managed through the same IAM infrastructure used for human and machine identities - with extensions to handle agentic-specific constructs like delegation chains and ephemeral sub-agent spawning. This approach integrates naturally with existing zero-trust architectures and NIST SP 800-207 principles, and it creates clear audit trails. The challenge is operational overhead: a complex multi-agent system may involve dozens of distinct agent identities, each requiring its own lifecycle management.

The managed service model routes all agent actions through a central broker that mediates identity, authorization, and audit. Agents do not hold credentials directly - they request actions from the broker, which applies policy, validates authorization, and logs the transaction before executing. This approach is easier to audit and revoke, but introduces a chokepoint that can become a performance bottleneck in high-volume agentic workflows. Emerging platforms like the Agentic AI Foundation’s governance work (co-founded under the Linux Foundation in December 2025 by Anthropic, Block, and OpenAI) are exploring standardized broker protocols that could bridge both approaches.

NIST’s AI Agent Standards Initiative is explicitly examining how protocols like A2A (Agent-to-Agent) and MCP (Model Context Protocol) fit within a federated standardization strategy - one that lets enterprises build on existing IAM investments rather than replace them.

Governance Principles That Apply Now

While standards are still maturing, several governance principles apply regardless of which architectural model organizations adopt.

Least privilege, applied to goal scope. Traditional least privilege scopes permissions to specific resources. For agents, least privilege must also scope the goal: an agent authorized to draft customer correspondence should not hold credentials that would allow it to send, even if sending is a logical next step. Goal-scoped authorization requires deliberate policy design and is not a default behavior in most current agent frameworks.

Explicit delegation boundaries. Every point at which an agent delegates authority to another agent should be a defined, auditable event. Delegation chains should have explicit depth limits. An orchestrator that can spawn sub-agents with the full scope of its own credentials creates recursive privilege escalation risk that is structurally equivalent to the confused deputy problem in traditional software security.

Agent lifecycle management. Agents are not set-and-forget deployments. Like service accounts, they accumulate stale credentials, outdated permissions, and behavioral drift as the systems they interact with change. A credential rotation schedule, periodic authorization review, and defined decommissioning process for retired agent deployments are baseline governance requirements.

Audit trails tied to human authorization. Every consequential agent action should be traceable to a specific human authorization decision - not just “the agent had permission” but “this specific human, at this time, authorized this scope of action.” For regulated industries, this traceability is increasingly a compliance expectation. NIST AI RMF’s GOVERN and MEASURE functions both point toward accountability chains that reach from automated action back to human decision.

Behavioral monitoring as an identity signal. Anomalous agent behavior - unexpected tool calls, unusual access patterns, novel action sequences - is an identity signal, not just a performance metric. Integrating agent behavioral monitoring into security operations, alongside traditional identity anomaly detection, closes the gap between what an agent is authorized to do and what it is actually doing.

The Governance Window Is Now

NIST’s comment period on AI agent identity closes in April 2026. The OWASP Agentic Top 10 is in active use by security teams building agent governance programs. The practical implication is that the governance frameworks are taking shape now, and organizations that engage with them now - through comment periods, pilot programs, and framework adoption - will be better positioned than those who wait for requirements to become mandates.

The 80% of Fortune 500 companies currently deploying agents without governance infrastructure are not acting recklessly. Most simply built agent capabilities before the governance frameworks existed. Those frameworks now exist, or are close enough to final form to act on. The question is whether governance gets built into agent deployments before an incident makes it urgent.

If your organization is deploying agentic AI and wants to build identity governance into the foundation rather than retrofit it later, use the contact form to start the conversation.