AI Agent Identity & Access Management in 2026: Authentication, Delegated Authority, and the Standards That Are Actually Shipping

TL;DR: The moment an AI agent stops answering questions and starts taking actions — sending email, moving money, merging a PR, filing a ticket — it needs an identity that systems can authenticate and authorize. In 2026 most agents don't have one. They borrow a human's OAuth token or a shared service-account key and act indistinguishably from a person, which quietly breaks the three things security depends on: accountability (who actually did this?), least privilege (the agent inherits the human's full scope), and revocability (you can't kill the agent without killing the human's access). The industry has converged on the fix — an agent is a first-class non-human identity: its own cryptographically-attested principal, short-lived at runtime, with the human preserved as a separate delegating subject. The plumbing for that (OAuth 2.0 Token Exchange, workload identity via SPIFFE, MCP's OAuth profile, A2A agent cards) mostly already exists; the OpenID Foundation, IETF, and NIST are standardizing the assembly, and Microsoft, Okta, and Auth0 shipped agent-native IAM products in the last year. This is the working picture: the problem, the four building blocks, the standards, and what to actually do in production.

Why "just give it my token" is a security incident waiting to happen

Almost every agent demo authenticates the same way: the developer pastes an API key, or the agent runs an OAuth flow and stores the user's access token. It works, and it's wrong for anything past a prototype. Three failure modes follow directly from it.

Impersonation destroys the audit trail. When an agent acts with your token, every downstream system logs you as the actor. If the agent is prompt-injected into exfiltrating a customer list, the SIEM shows a legitimate employee running a legitimate export. There is no field that says "a machine did this, unattended, because a web page told it to." The OpenID Foundation's October 2025 whitepaper names this directly: the industry has to move from impersonation to delegation, where a token carries the user's identity and the agent's identity as distinct claims.

Borrowed scope is maximal scope. A human's OAuth token to Google Workspace can read every email, every file, every calendar. An agent that only needs to draft replies in one label inherits all of it. Because agents chain many tools, the effective blast radius of a compromised agent is the union of every scope it borrowed. This is exactly the token passthrough problem that MCP had to fix at the protocol level.

No offboarding, no expiry, no manager. Traditional IAM assumes a human on the other end — passwords rotate, MFA challenges fire, SSO sessions expire, and HR offboarding revokes access when someone leaves. A non-human identity has none of those signals. Agent credentials accumulate, drift out of inventory, get copied across environments, and rarely rotate. Gartner's widely-cited estimate puts the ratio of non-human to human identities at roughly 45:1 in enterprises by 2026, and agent deployments are the fastest-growing driver.

The through-line: an agent is not a user, and it is not a traditional service account either. It's a new kind of principal that acts on behalf of a user, autonomously, across many systems. Identity systems weren't built for that, and retrofitting it is the 2026 project.

The mental model: three questions every agent action must answer

Before the standards, the model. Any well-designed agent identity system answers three questions on every action:

Keep these three separate and most of the hard problems become tractable. Conflate them — which is what "use my token" does — and you lose all three at once. The rest of this post is how each is being solved.

Building block 1 — Workload identity: proving who the agent is

Before an agent can be authorized, it has to be authenticated as itself. The cleanest answer comes from the world of cloud-native workload identity: SPIFFE (Secure Production Identity Framework For Everyone) and its reference implementation SPIRE. SPIFFE issues each workload a short-lived, cryptographically verifiable identity document (an SVID) — typically an X.509 cert or JWT — that lets two services prove who they are to each other over mTLS, without any shared secret or long-lived key.

For agents this matters because it gives the agent an identity that is attested at runtime (issued based on what the workload actually is and where it runs), short-lived (rotated automatically, so a leaked SVID expires in minutes not months), and independent of OAuth client registration. The March 2026 IETF Internet-Draft draft-klrc-aiagent-auth-00 proposes exactly this composition: agents are workloads with WIMSE/SPIFFE identifiers, and access tokens carry a dual identity — the agent's verifiable workload identity as client_id, and the delegated user as sub. Red Hat's emerging-tech team demonstrated the full wiring in June 2026: SPIFFE for service-to-service mTLS, token exchange to carry user-delegation context, and a lifecycle layer (Kagenti) to bind policy to the agent.

The practical takeaway: an autonomous agent that runs without a human in the loop needs a machine identity, not a borrowed user token. SPIFFE/SPIRE is the mature, vendor-neutral way to give it one.

Building block 2 — Delegated authority: proving on whose behalf

The second building block is the one the OpenID Foundation calls foundational: OAuth 2.0 Token Exchange (RFC 8693). Instead of the agent impersonating the user, the agent exchanges a base token for a new token that carries two identities as separate claims:

• sub — the subject: the human the agent is acting for.
• act — the actor: the agent itself, nested inside the token.
• may_act — optionally, which actors a subject has authorized to act for them.

This is the difference between impersonation ("I am Alice") and delegation ("I am Alice's scheduling agent, acting for Alice"). Every downstream service — and every audit log — now sees both. If the agent misbehaves, you can attribute the action to the agent and the delegation, revoke the agent's actor identity, and leave Alice's own access intact. The OpenID Foundation's On-Behalf-Of (OBO) work formalizes this pattern as the replacement for direct impersonation.

Token exchange also enables just-in-time privilege narrowing for multi-tool workflows. The agent holds a base token with modest scope; immediately before it calls a high-privilege API, it exchanges that base token for a narrowly-scoped, audience-restricted ephemeral token that expires in minutes. A compromised agent can only replay tokens for the exact resources it was mid-task on — not its entire lifetime of accumulated access.

Building block 3 — Fine-grained authorization: proving this action, right now

Authentication says who; authorization says what. Coarse OAuth scopes (calendar.read) were designed for apps a human drives click by click. An autonomous agent making hundreds of unattended calls needs fine-grained, externalized authorization — a policy decision evaluated per action, outside the agent's own code (so a hijacked agent can't rewrite its own rules).

The standards body response is the OpenID Foundation's AuthZEN Working Group, which is standardizing the interface between a Policy Enforcement Point (the gate in front of a tool) and a Policy Decision Point (the service that answers "is this allowed?"). Architecturally this is the same PEP/PDP split that zero-trust networking uses, applied to agent tool calls. A 2026 research thread also formalizes deterministic pre-action authorization — checking a proposed tool call against policy before it executes rather than detecting abuse after — which is the right shape for irreversible actions.

The pragmatic version, deployable today without waiting for a spec: scope tokens per resource (a per-repo GitHub PAT, a per-channel Slack token, not a workspace-wide grant), bind tokens to an audience so they can't be replayed elsewhere, and keep a human-in-the-loop approval for the small set of high-consequence, irreversible actions. Reversibility is the ultimate authorization backstop: an action you can undo needs less up-front gating than one you can't.

Building block 4 — Agent-to-agent identity: A2A and agent cards

When one agent calls another (increasingly common in multi-agent systems), each needs to identify itself to the other. The A2A protocol (Agent-to-Agent) handles this with the Agent Card — a discoverable JSON document at a well-known URL that declares an agent's capabilities, its authentication schemes, and its authorization requirements. Agent cards are the agent-world equivalent of an OpenID discovery document: they let a caller learn how to authenticate before the first request. A2A composes with the rest of the stack — the card declares that the agent expects, say, an OAuth token-exchange delegation, and the caller mints one.

This is also where MCP fits. MCP secures agent-to-tool connections; A2A secures agent-to-agent connections. MCP's June 2025 spec revision made OAuth 2.1 with Resource Indicators (RFC 8707) mandatory for HTTP transports precisely to kill token passthrough — binding each token to a specific MCP server so a malicious server can't replay it downstream. The identity model is consistent across both protocols: verifiable agent identity, delegated user context, audience-bound tokens.

The standards landscape in one table

Where the specs actually are as of mid-2026:

The reassuring news for builders: you don't need to wait for the drafts to finalize. The primitives that matter — token exchange, resource-indicator-bound OAuth, workload identity — are already stable standards. The 2026 work is mostly assembly and governance, not net-new cryptography.

The platform layer: what you can buy

Identity vendors moved fast, and this is now a real product category rather than a research topic:

• Microsoft Entra Agent ID registers AI agents as a first-class identity type, distinct from employees and from generic service principals — so you can set per-agent access rules, usage boundaries, and activity logs, and see agents in the same directory you govern people in.
• Okta for AI Agents and Auth0 for AI Agents provide agent registration, governance, and lifecycle management, plus Cross App Access (XAA) — an open extension of OAuth/OIDC that gives IT visibility and control over app-to-app and agent-to-app connections that would otherwise be invisible shadow integrations.
• NHI-security specialists (Astrix, Entro, Oasis, Aembit, Clutch) focus on the discovery, secret rotation, least-privilege scoping, and behavioral monitoring side — finding the agent tokens you didn't know you had and watching them for anomalies.

Rule of thumb from the 2026 comparisons: Microsoft-centric shops get the fastest coverage from Entra Agent ID; multi-vendor enterprises benefit from Okta's fabric approach; teams building proprietary agents start with Auth0's developer-first controls or roll SPIFFE + token exchange themselves. The competitive battleground has already shifted from authentication to governance — who granted access, what the agent can do, and whether every action is logged and revocable.

What to actually do in production (2026 checklist)

If you're shipping an agent that takes real actions, in rough priority order:

1. Give the agent its own identity. Stop reusing a human's token or a shared service-account key. Autonomous agents get a workload identity (SPIFFE/SVID); user-facing agents get a registered agent identity distinct from the user.
2. Delegate, don't impersonate. Use OAuth Token Exchange so tokens carry both sub (user) and act (agent). Your audit logs must be able to say "this agent did this, for this user, unattended."
3. Scope per resource, bind to audience, keep it short-lived. Per-repo, per-channel, per-dataset tokens — never workspace-wide. Exchange for a narrow ephemeral token right before a high-privilege call.
4. Externalize authorization. Put a policy decision point in front of tool calls so a hijacked agent can't grant itself scope. Gate irreversible actions with human-in-the-loop.
5. Inventory and rotate every non-human identity. You can't govern what you can't see. Discover agent credentials, rotate them on a schedule, and make every one revocable in a single action.
6. Monitor for behavioral anomalies. A burst of users.list at 3am, an export the agent has never done before — NHI monitoring catches the compromise that scoping didn't prevent.
7. Assume prompt injection will succeed sometimes. Identity is a containment control, not a prevention one. The value of scoped, delegated, revocable identity is that it caps the blast radius when the model is hijacked — which, per the prompt injection reality, it eventually will be.

The one-slide summary

• An agent that takes actions is a new kind of principal: its own identity, acting on behalf of a human, autonomously, across many systems. "Use my token" fails all three of accountability, least privilege, and revocability at once.
• The fix is delegation, not impersonation: agent identity + user identity carried as separate claims (act / sub) via OAuth Token Exchange, with autonomous agents authenticated by workload identity (SPIFFE).
• The primitives are already standard (RFC 8693, RFC 8707, SPIFFE); OpenID, IETF, and NIST are standardizing the assembly; Entra Agent ID, Okta, and Auth0 sell the platform layer today.
• Identity is a containment control. It doesn't stop prompt injection or MCP-borne attacks — it makes them survivable by capping what a hijacked agent can reach and letting you revoke it in one move.

Further reading

• Standards & primary sources. OAuth 2.0 Token Exchange (RFC 8693) · OpenID: Identity for Agentic AI · OpenID AuthZEN WG · IETF draft-klrc-aiagent-auth-00 · SPIFFE.
• Reference implementation. Red Hat: wiring zero-trust identity for AI agents (SPIFFE, token exchange, Kagenti).
• Platform layer. Okta for AI Agents · Microsoft Entra Agent ID · Auth0 for AI Agents.
• Related pillars on this site. MCP Security in 2026 · Prompt Injection in 2026 · AI Agent Access Control & Data Security · AI Agent Security Best Practices · The A2A Protocol Explained.
• Glossary. Non-Human Identity (NHI) · Agent Identity · Delegated Authority (On-Behalf-Of) · OAuth Token Exchange (RFC 8693) · Workload Identity (SPIFFE/SPIRE) · Fine-Grained Authorization (for agents) · MCP OAuth · Blast Radius.