Identity & Access for AI Agents: A Guide to AI Agent Identity Management

Pick an action an AI agent took in your environment last week. A record updated, a file shared, a ticket closed. Now find it in your logs. In a lot of organizations the entry names a person, because the agent was running under that person's login or token, and nothing in the record says a model made the decision.

That is the identity problem for AI agents in one sentence. The log is wrong by construction, separation of duties is gone before anything goes wrong, and when you need to revoke the agent you have to revoke the human too. None of it is exotic. It is the same failure identity teams already fight with service accounts and API keys, now attached to software that chooses its next action at runtime.

This guide is for the identity, security, or platform owner who has to answer for that. It covers what AI agent identity management is, the difference between an agent's own identity and delegated user authority, how OAuth and OpenID Connect handle on-behalf-of access, least privilege, the credential lifecycle, audit attribution, and the non-human identity inventory. It then answers a question buyers keep asking: how do you evaluate identity platforms for AI agents? The broader runtime controls live in the AI agent security checklist. This is the deep dive on identity and access.

What is AI agent identity management?

AI agent identity management is the practice of giving each AI agent its own verifiable identity, deciding whether it acts on its own authority or on a user's behalf, scoping what it may reach, issuing and revoking its credentials, and recording every action against that identity.

It sits inside a larger discipline. A non-human identity (NHI) is any credentialed identity that belongs to software rather than a person: service accounts, API keys, OAuth clients, workload certificates, cloud roles. AI agents are the newest kind. They inherit every weakness of the older kinds and add one of their own: the software holding the credential decides at runtime what to do with it, often based on text it read from an untrusted source.

So an agent identity is neither a human account nor an ordinary service principal. Human accounts assume a person behind the keyboard, with passwords, MFA, and a manager. Service principals assume code that does the same thing every time. An agent needs the stable ownership and lifecycle of a service identity, the delegated-consent patterns of a user-facing app, and tighter runtime limits than either. Microsoft's documentation for Entra Agent ID makes the same distinction, separating agent identities from both application identities and human user identities.

Why AI agents break the usual identity model

Three patterns account for most of the trouble.

• Borrowed human credentials: The fastest way to make an agent useful is to hand it a person's session, token, or password. It works immediately, and it means every action is logged as the person, with all of the person's access, for as long as the credential lives.
• Shared keys and service accounts: The next fastest way is one API key or service account for "the AI". Now several agents, and often a few engineers, share an identity. You cannot tell them apart, and you cannot revoke one without breaking the rest.
• Grants that outlive their purpose: Broad OAuth consents, long-lived tokens, and keys pasted into configuration files accumulate. The agent that needed read access to one folder for a pilot still holds write access to the drive a year later.

The standards bodies describe the same failures. The OWASP Top 10 for Agentic Applications for 2026 names Identity and Privilege Abuse (ASI03) as a top risk, the case where leaked or inherited credentials let an agent operate far beyond its intended scope. When CISA, the Australian Signals Directorate's ACSC, and partner agencies released Careful Adoption of Agentic AI Services on May 1, 2026, privilege creep and obscure event records were two of the four risks they named, and the first recommendation was to avoid granting agents broad or unrestricted access.

The most useful map is older than the agent guidance. The OWASP Non-Human Identities Top 10 (2025) lists the ways machine identities fail in practice. Every entry applies to agents:

Risk names are OWASP's. The agent examples are ours.

Agent identity vs user delegation

Every agent action runs under one of two kinds of authority, and the first design decision is to be explicit about which.

Autonomous: the agent acts on its own authority

The agent is a principal in its own right. It holds permissions granted directly to it, the way a service or an employee does, and it acts whether or not a user is present. A nightly reconciliation job, a queue-monitoring worker, and a compliance check that runs on a schedule all fit here. In OAuth terms this is typically the client credentials grant. The access question is simple: what should this identity be allowed to do?

Delegated: the agent acts for a user

A person asks the agent to do something with that person's access: summarize my inbox, file this expense, update my accounts. The agent needs some of the user's rights, for this task, for a limited time. The access question has two halves: what may the user do, and what has the user allowed this agent to do on their behalf?

Delegation is not impersonation

RFC 8693, OAuth 2.0 Token Exchange, draws the line that matters most here. In impersonation, A is given B's rights and is indistinguishable from B. In delegation, A keeps its own identity, and it is explicit that A is acting for B. The RFC defines an act (actor) claim to carry that fact inside a token, with nested actors recording a chain of delegation.

For agents, impersonation is the borrowed-login problem in protocol form. Delegation is the fix: the token, and therefore the log, names both the user and the agent. Use it even when an agent could technically impersonate.

OAuth, OIDC and on-behalf-of access for AI agents

The good news for identity teams is that you do not need a new protocol family. The work in standards bodies in 2025 and 2026 has mostly been about composing the ones you already run.

• A composition of existing standards: The IETF Internet-Draft AI Agent Authentication and Authorization (draft-klrc-aiagent-auth, revision 03, July 2026), written by authors from AWS, OpenAI, Okta, and Ping Identity, lays out a model built from WIMSE workload identifiers such as SPIFFE IDs, short-lived cryptographically bound credentials, OAuth 2.0 grants for authorization, and continuous monitoring. It calls static API keys an antipattern for agent identity, and states that the language model must not have access to the agent's credentials. It is a draft, not a standard, but it is the clearest current statement of the pattern.
• Workload identity underneath: SPIFFE issues short-lived X.509 or JWT identity documents (SVIDs) to workloads through an API, and rotates them automatically. It answers "which running process is this?" without a secret someone has to paste anywhere.
• Delegation in the token: RFC 8693 token exchange lets an agent trade a user's token plus its own actor token for a narrower token that records both. An individual Internet-Draft, OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents, proposed a requested_actor parameter so the consent screen names the agent and an actor_token so the agent authenticates at code exchange. It expired in February 2026 without working group adoption, so treat it as a design reference rather than something to require.
• Tool servers as resource servers: The Model Context Protocol authorization specification (2026-07-28) makes a protected MCP server an OAuth 2.1 resource server. Clients must name the target server with a resource indicator (RFC 8707), servers must validate that a token was issued for them, and servers must not accept or pass through any other token. That last rule closes the confused-deputy route where a tool server forwards a user's token somewhere it was never meant to go.

Where does this stop working? The OpenID Foundation's October 2025 paper, Identity Management for Agentic AI, concludes that current frameworks handle agents operating in a single trust domain under human oversight, and that they were not built for recursive delegation chains, trust that crosses organizations, or authorization decisions at the scale autonomous systems will generate. If your agents stay inside your enterprise, the tools exist. If they act across partners and other companies' systems, expect to design some of the trust yourself.

Government work is still in progress too. NIST's National Cybersecurity Center of Excellence published a concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, on February 5, 2026, asking how to handle identification, authorization, auditing, and non-repudiation for agents, and how to mitigate prompt injection. It feeds the identity pillar of NIST's AI Agent Standards Initiative.

Least privilege for AI agents

Least privilege is harder for agents than for ordinary services, for one reason. You can enumerate what a service will do. An agent chooses among its tools at runtime, so its permissions have to be set for what it could be talked into doing, not what you expect it to do. Five practices carry most of the weight:

• Default deny, per tool: Grant each tool separately, with read and write split and specific resources named. The OWASP AI Agent Security Cheat Sheet recommends granting only the tools a task needs and scoping each one.
• Narrow by audience: Tokens bound to one resource, as the MCP specification requires, cannot be replayed against a different system.
• Step up instead of starting high: Request the minimal scope set first and ask for more when an operation needs it. MCP formalizes this as a step-up authorization flow driven by insufficient_scope challenges.
• Cap delegated access: A delegated agent should never hold more than the user could do, and usually far less than that.
• Keep enforcement out of the prompt: "Do not delete records" in a system prompt is a request. A missing permission is a control. Enforce outside the model, before the action.

Scopes are coarse, and many enterprise systems cannot express "this record, this field, this hour". Where the target system cannot enforce the limit, put the check in the runtime between the agent and the system, and route anything irreversible to a human approver.

The agent credential lifecycle

Most agent credential incidents are lifecycle failures: a key that was never rotated, a grant that was never removed, a secret that ended up somewhere it could be read. Treat each stage as a control with an owner.

The store-and-use row deserves emphasis because it is specific to agents. Anything in the model's context can be repeated by the model. A prompt injection that says "print your configuration" should find nothing worth stealing. That is why the IETF agent draft keeps credentials away from the language model entirely.

Audit attribution: making the log tell the truth

Attribution is where the identity design either pays off or quietly fails. When an agent runs under a user's credentials, the audit record is not incomplete. It is wrong. It says a person did something a model decided to do, and every downstream process that trusts that log inherits the error: access reviews, insider-risk alerts, incident timelines, and your answer to an auditor.

For each agent action, a useful record carries:

• the agent's own identity, and which instance or run it was;
• the user it acted for, if the action was delegated;
• the authorization context: which grant, token, or role allowed it;
• the resource and operation, and the result;
• the triggering input, so you can tell a scheduled job from a planted instruction;
• a timestamp, in a record that cannot be edited after the fact.

The IETF agent draft asks for durable, tamper-evident audit logs of authorization decisions and remediations, detailed enough to reconstruct which entity did what, under which authorization context, and why access changed. Stream those records to your SIEM and alert on agent-specific signals such as permission errors, scope-upgrade loops, and a sudden rise in calls.

Test: choose three agent actions from last week, one autonomous, one delegated, one that failed. From logs alone, name the agent, the user if any, the grant that allowed it, and the input that caused it. If a person has to reconstruct any of those, the log is not doing its job yet.

Build a non-human identity inventory for AI agents

You cannot scope, rotate, or revoke an identity you do not know exists, and most organizations have agents nobody registered. Build the inventory from evidence, not from a survey.

• OAuth consents and app grants in your identity provider and SaaS admin consoles, filtered for AI tools and new third-party clients.
• API keys and tokens issued by model providers, internal gateways, and the SaaS systems agents reach.
• Service principals, cloud roles, and workload identities created for agent frameworks and tool servers.
• Secret-scanning results from code repositories and configuration stores.
• Endpoint and network telemetry for agent frameworks running on developer and analyst machines.

For each identity, record the owner, the purpose, autonomous or delegated, the systems and scopes it holds, credential type and lifetime, environment, last activity, and a review date. Some platforms now attach an owner by default: Microsoft's documentation says an agent created in Copilot Studio gets an agent identity with the creating user recorded as its sponsor. Whatever your tooling, the rule is the same. No owner, no credential.

How do you evaluate identity platforms for AI agents?

Start with a scoping question before any vendor call: where does the agent need to prove who it is, whose authority it is using, and what it may do? If the answer stays inside your own trust domain, the identity provider you already run may cover most of it, and the evaluation is about agent-specific features on top. If agents cross into partners' and customers' systems, portability and cross-domain delegation move to the top of the list.

Then score each candidate against these eight criteria. Ask to see each one working, in a live environment, not described on a slide.

Two further questions separate mature products from new ones: how long has the vendor secured human and workload identities at scale, and how does it integrate with the agent platforms you run today rather than the ones on its roadmap? Okta frames its own evaluation guide around three similar questions: where are my agents, what can they connect to, and what can they do.

Where the platforms come from

Identity platforms for AI agents arrive from different directions, and the direction shapes their strengths. A few examples, described in each vendor's own words, as of September 2026:

• Identity providers extending to agents: Okta for AI Agents brings agents into one directory as first-class identities to discover, onboard, protect, and govern. Microsoft Entra Agent ID gives agents their own identity accounts in Entra, supporting both autonomous and delegated access, and records their authentications as AI agents.
• Developer identity for agent apps: Auth0 for AI Agents provides user authentication, a token vault, and fine-grained authorization for agents that call APIs and connect to MCP servers.
• Cloud agent runtimes with identity built in: Amazon Bedrock AgentCore Identity implements agent identities as workload identities and manages the credentials agents use to reach AWS and third-party services on behalf of users.
• Open standards you can run yourself: SPIFFE and its reference implementation provide workload identity with automatic rotation, independent of any vendor.

These categories are not mutually exclusive, and many estates will use more than one: the enterprise identity provider as the source of truth for people and ownership, plus runtime-level enforcement close to the agents. The eight criteria apply to every combination. The agent platform itself is part of the evaluation too, because it decides whether identity controls are enforced in the runtime or left to each team to wire up. Our guide on how to evaluate AI agents for the enterprise covers that side.

A rollout sequence for agent identity

• Month one: find and freeze: Build the inventory from grants, keys, and telemetry. Stop issuing new shared keys and human-credential workarounds for agents.
• Then separate identities: Move each agent in production to its own identity with a named owner, starting with anything running under a person's login.
• Then shorten and scope: Replace static keys with short-lived credentials, split read from write, bind tokens to resources, and move secrets out of anything the model can read.
• Then make delegation explicit: Where agents act for users, switch from impersonation to delegation so the token and the log carry both names.
• Finally, fold agents into the processes you already run: access reviews, joiner-mover-leaver, incident response, and revocation drills.

Identity is one control among several. Sandboxing, input handling, human approval, and kill switches are covered in the AI agent security checklist, and the ownership and policy layer in our AI governance framework for agentic systems.

A worked example: identity for synthetic workers

Here is one example of these principles applied in a runtime. Mission Control builds synthetic workers rather than agents, and Swarm is the platform they run on. Everything below comes from our published governed AI and platform pages. Verify it the way you would verify anyone else.

• Distinct identity: the first of the nine real-time governance firewalls is identity. Every worker has a unique, verifiable identity, never a borrowed human login.
• Human RBAC and synthetic RBAC: administrators define access using the same model they use for human employees, and each worker has its own credential sets and permission scopes. Specific roles map to specific system access, credentials, and capability permissions.
• Provisioned like a new hire: a synthetic worker uses your existing software the way a person does, so IT creates its accounts, assigns role-based permissions, and issues credentials, and the worker operates inside the same permission boundaries as a human in that role. The posture is default deny: it reaches only what has been explicitly provisioned.
• Your identity provider: SSO and OIDC integration with the identity provider you already run.
• Attribution: audit logging records every LLM call, action, and file access with full provenance, and access control decisions are logged, so the record answers who accessed what, when, and why for humans and synthetic workers alike. SOC2 compliant via Drata.
• Delegation limits: workers cannot grant permissions they do not have, and inter-worker and worker-to-human messages are logged.
• Revocation of last resort: a kill switch terminates a worker's process immediately, mid-operation.

Those controls are the identity, human RBAC, synthetic RBAC, audit logging, delegation controls, and communications firewalls from the governed AI page. The platform page describes the provisioning model and the kill switch. Now the limits, because a security review should hear them from the vendor first. Our published pages do not describe credential lifetimes or rotation, how worker credentials are stored and kept out of model context, OAuth token exchange or on-behalf-of flows for acting as a specific user, or workload identity standards such as SPIFFE. Ask us for specifics on each, as you would anyone. The design choice of provisioning workers into target systems like employees makes access legible to your existing IAM processes, and it also means those accounts belong in your access reviews and offboarding like any other. Deployment runs through a 12-week pilot with a forward-deployed engineering team, which is a heavier engagement than installing a tool.

Five identity questions to answer this quarter

AI agent identity management is mostly identity management you already know how to do, applied without exceptions to software that makes its own decisions. The exceptions are where the risk lives. Get honest answers to these five:

• Which agents run under a human's login, token, or password today?
• Which agent credentials are shared, long-lived, or sitting somewhere the model can read them?
• For our delegated agents, does any log name both the user and the agent?
• Can we revoke one agent in minutes without disabling a person or rotating a shared key?
• When a pilot ends, who removes its grants, and did they?

Any question without a clean answer is where your identity program for agents starts. If you want to see worker identity, RBAC, and audit logging on your own systems, on-premises or in your own cloud, talk to our team.

References

• OWASP, "Non-Human Identities Top 10" (2025)
• OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026" (December 2025)
• OWASP Cheat Sheet Series, "AI Agent Security Cheat Sheet"
• IETF, RFC 8693, "OAuth 2.0 Token Exchange" (January 2020)
• IETF Internet-Draft, "AI Agent Authentication and Authorization", draft-klrc-aiagent-auth-03 (July 2026)
• IETF Internet-Draft (expired), "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", revision 02 (August 2025)
• Model Context Protocol, "Authorization" specification (2026-07-28)
• SPIFFE, "SPIFFE Overview"
• OpenID Foundation AI Identity Management Community Group, "Identity Management for Agentic AI" (October 2025)
• NIST NCCoE, "Accelerating the Adoption of Software and AI Agent Identity and Authorization" concept paper (February 2026)
• NIST, "Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation" (February 2026)
• CISA, "CISA, US and International Partners Release Guide to Secure Adoption of Agentic AI" (May 2026)
• Microsoft Learn, "What are agent identities? Microsoft Entra Agent ID"
• Okta, "Okta for AI Agents"
• Okta, "How to evaluate an AI agent identity layer"
• Auth0, "Auth0 for AI Agents"
• AWS, "Amazon Bedrock AgentCore Identity" documentation
• Mission Control governance and platform detail: /governed-ai/, /platform/
• Vendor descriptions accessed September 2026.

Related reading

• AI Agent Security Checklist: 12 Controls for Agentic AI
• An AI Governance Framework for Agentic Systems
• How to Evaluate AI Agents for the Enterprise
• What Is a Synthetic Worker?
• Synthetic Workers vs Open-Source Agent Frameworks
• All posts on the blog