AI Agent Identity: How to Authenticate, Authorize and Govern Agents in the Enterprise

Quick answer: An AI agent identity is a distinct, first-class identity issued to an autonomous software agent, separate from both the human who launched it and the application that hosts it. The agent authenticates with its own credential (an OAuth client with short-lived tokens, a workload certificate or a platform-issued agent ID), acts under scoped, delegated authority from a human or system principal, and leaves an audit trail that records both the agent and the principal on whose behalf it acted. The rule: never let an agent borrow a human's session.

In 2025 most enterprises piloted AI agents inside a chat window. In 2026 those agents started calling APIs, opening tickets, moving data between systems and, in some cases, spawning other agents. By 2027 the question for every identity team is no longer whether agents need identities but how to issue, scope, monitor and revoke them at a pace the business will tolerate.

This guide is written for IAM program owners, identity architects and CISOs. It sets out why agents are a distinct class of non-human identity, which standards are mature enough to build on, how to design authorization for software that makes its own decisions, and what "governance" means when the actor is non-deterministic. If you are still building your inventory of service accounts and keys, start with our non-human identity management playbook; agents inherit every problem described there and add several more.

Should an AI agent have its own identity separate from the user?

Yes, and this is the single most consequential design decision. Three patterns are in use today, and only one scales safely.

• Agent impersonates the user — How it works: Agent reuses the user's session token or stored password · Why it fails or succeeds: Audit log shows the human doing things they never did; no way to scope the agent below the human's full access; revoking the agent means revoking the human
• Agent runs as a shared service account — How it works: One powerful NHI for "the AI platform" · Why it fails or succeeds: Standing privilege, no per-user context, no way to tell which user's request triggered which action; a single credential compromise exposes every workflow
• Agent has its own identity with delegated authority — How it works: Agent holds its own credential; a token exchange binds it to a specific human or system principal and a narrow scope for a bounded time · Why it fails or succeeds: Separates who is acting (the agent) from whose authority (the principal); enables least privilege, independent revocation and a truthful audit trail

The third pattern is what Microsoft (Entra Agent ID), Okta, Ping and others are converging on, and it is the model assumed in the emerging IETF work on agent authentication and in the Workload Identity in Multi-System Environments (WIMSE) effort. Treat it as the default.

How do you authenticate an AI agent?

Authentication answers "which agent is this, and is it the one we registered?" The mechanisms are mature because they are the same ones used for workloads:

• OAuth 2.0/2.1 client credentials for the agent's own identity, with private-key JWT or mutual TLS client authentication (RFC 8705) instead of a shared client secret.
• Workload attestation where the agent runs in your infrastructure: SPIFFE/SPIRE-issued identities, or cloud managed identities, so the credential is bound to a verified runtime rather than copied from a config file.
• Sender-constrained tokens (DPoP, RFC 9449, or mTLS-bound tokens) so a stolen access token cannot be replayed from another host.
• Short lifetimes. Agent access tokens should live minutes, not hours; refresh via the attestation path, not via a long-lived refresh token sitting in a prompt-injectable context.

The Model Context Protocol (MCP), which many agents use to reach tools and data, adopted an OAuth 2.1-based authorization model in 2025. In practical terms this means each MCP server is a resource server, the agent (or its host) is an OAuth client, and your existing authorization server can issue the tokens. That is good news: you do not need a new identity provider for agents, you need policy and registration discipline in the one you have.

Registration is the control most teams skip. Every agent should exist as an object in your directory or IGA platform with: an owner, a purpose, the model and framework it runs on, the tools it may call, the data classifications it may touch, and a kill switch. Unregistered agents are shadow IT with API keys.

How do you authorize what an AI agent can do?

Authorization is harder than authentication because the agent chooses its own actions. Four layers work together:

1. Delegation scope. When a human triggers an agent, use OAuth token exchange (RFC 8693) to mint a token that encodes both the agent (actor) and the human (subject), with scopes that are the intersection of what the human may do and what the agent is approved to do. Rich Authorization Requests (RFC 9396) let you express fine-grained constraints ("read invoices for cost center 4410, no writes") rather than coarse scopes.
2. Per-tool policy. Enforce externalized policy (OPA/Rego, Cedar, or your authorization service) at each tool or API the agent calls. The agent's reasoning is not a security boundary; the policy decision point is.
3. Step-up and human-in-the-loop. Define actions that always require a fresh human approval: payments above a threshold, changes to identity or security configuration, data egress, deletion. The agent requests; a person approves through a channel the agent cannot spoof.
4. Rate and blast-radius limits. Cap calls per minute, records per action and spend per day. Agents fail fast and loop; limits turn a runaway into an incident ticket rather than an outage.

OWASP's Top 10 for LLM Applications names "excessive agency" as a core risk, and this is the control set that addresses it: the agent gets the minimum authority to do its job, for the shortest time, with the consequential actions gated.

What is agentic identity governance?

Governance is where agents differ most from ordinary workloads. A batch job does the same thing every night; an agent may do something new tomorrow because the prompt, the data or the model changed. Agentic identity governance therefore has to cover the lifecycle, the authority and the behavior:

Lifecycle

• Joiner: registration with owner, purpose, risk tier and approved tools; security review before production credentials are issued.
• Mover: any change to model, tools, data access or autonomy level re-triggers review. Treat a model upgrade like a role change.
• Leaver: decommissioning removes the identity, revokes tokens and consents, and archives logs. Orphaned agents are the new orphaned service accounts.

Authority

• Quarterly certification by the owner of the agent's entitlements, driven by observed usage: which tools it actually called, which scopes it actually used.
• Separation of duties applies: the agent that drafts a payment should not be the agent (or the identity) that releases it.

Behavior

• Baseline each agent's tool-call pattern and alert on new tools, new data domains, unusual volumes or activity outside the principal's working context.
• Log at the level of intent and action: the request that triggered the run, the principal, the agent, the tools called, the parameters and the outcome. Identity threat detection and response (ITDR) tooling is starting to include agent-specific detections; until yours does, build them in your SIEM.

Regulation is catching up. The EU AI Act's obligations phase in through 2026 and 2027 and require traceability and human oversight for higher-risk uses; the NIST AI Risk Management Framework asks for accountability and transparency; sector rules such as DORA and APRA CPS 230 expect ICT and operational resilience controls to extend to automated processes. An identity-centric audit trail is the cheapest way to evidence all three.

Which standards apply to AI agent identity, and which are still moving?

• Agent credential — Use now (stable): OAuth 2.1 client credentials; private-key JWT or mTLS client auth (RFC 8705); SPIFFE/SPIRE · Watch (in progress): Vendor agent registries (e.g. Entra Agent ID) maturing into cross-platform standards
• Delegated authority — Use now (stable): OAuth token exchange (RFC 8693) with actor/subject claims · Watch (in progress): IETF drafts on agent authentication and authorization; WIMSE architecture
• Fine-grained scope — Use now (stable): Rich Authorization Requests (RFC 9396); externalized policy (OPA, Cedar) · Watch (in progress): Standardized "agent capability" vocabularies
• Token binding — Use now (stable): DPoP (RFC 9449); mTLS-bound tokens · Watch (in progress):
• Tool access — Use now (stable): MCP authorization (OAuth 2.1 based) · Watch (in progress): Agent-to-agent protocols and how they carry identity
• Risk framing — Use now (stable): OWASP Top 10 for LLM Applications; NIST AI RMF; NIST SP 800-207 · Watch (in progress): Sector guidance on agent oversight

The design lesson: build on the stable column, and isolate the moving parts behind your authorization server and policy layer so you can swap them without re-plumbing every agent. That is also the argument for treating agent identity as one more consumer of a coherent identity fabric rather than a bolt-on.

How do you revoke an AI agent's access fast?

Revocation is the capability to test before go-live, because you will need it during an incident.

• Keep access tokens short-lived so revocation is effectively "stop issuing."
• Maintain a single registry so disabling the agent's identity cuts off every tool at once, including SaaS OAuth consents.
• Implement a kill switch at the orchestration layer that halts in-flight runs, not just new ones.
• Rehearse: pick an agent, revoke it, and measure the time until its last successful call. Record the number; it is the agent equivalent of "time to disable a leaver."

Key takeaways

• Agents are a distinct class of non-human identity: autonomous, non-deterministic and often acting for a specific person. Give each one its own identity and delegated authority.
• Authentication is a solved problem if you treat agents as workloads: OAuth client identities, attestation, short-lived sender-constrained tokens.
• Authorization must live in policy enforcement points and human approval gates, never in the prompt.
• Governance means lifecycle, usage-based certification, separation of duties and agent-aware monitoring; a model or tool change is a "mover" event.
• Build on stable OAuth and workload-identity standards and keep the moving parts (agent registries, agent-to-agent protocols) swappable.
• Test revocation before go-live and report time-to-revoke alongside your other identity metrics.

Join your peers at Identity World 2027

Identity World is the global identity and access management forum: practitioner-led, vendor pitch-free, and built around the questions above. Agentic AI and non-human identity are on the agenda in every city: Sydney, February 18 · Melbourne, March 17 · New York, May 6 · London, June 16 · San Francisco, November 3.

Not ready to register? Sign up for updates and the IdentityBriefing newsletter.