Agent Identity and Access Guide for AI Agents

Most AI agents in production today run on borrowed identity: a developer's token, a shared service account or a long-lived API key pasted into configuration, so nobody can say which agent did what, for whom, or with how much authority. Agent identity and access is the discipline of giving each agent its own verifiable identity, short-lived credentials it never sees in plain text, and authorisation that is decided per action rather than granted once. This pillar page is the overview for the whole category: what it covers, the concepts you need, the threats, the controls in maturity order, who owns what and which standards apply. It is written for IAM, platform and security architects who are bringing agents into an existing identity programme, and it links to every NHI Mgmt Group guide in the category for the depth.

Key takeaways

An agent is a non-human identity with extra problems. It authenticates like a workload, but it chooses its own actions at runtime, often acts for a human, and can be steered by the content it reads.
Two identities travel together. The agent's own workload identity and the user or system it acts for should be separate, verifiable claims, for example a workload credential plus an exchanged OAuth token carrying an act claim (RFC 8693).
Credentials belong outside the model. Keep secrets out of prompts, code and agent memory; issue short-lived, audience-restricted, ideally sender-constrained tokens through a broker or vault.
Authorise the action, not the agent. Decide at each tool call using the agent, the principal, the resource, the action and context, with human approval reserved for irreversible or high-value steps.
Ownership and lifecycle are the controls most often missing. Every agent needs a named owner, a registered purpose, a review cycle and a fast, tested revocation path.

What the field covers

Agent identity and access sits where non-human identity management, workload identity, OAuth delegation and authorisation policy meet. It answers five questions for every agent in the estate:

What is it? A registered, uniquely identified agent with an owner, a purpose and a risk rating, distinguishable from other agents and from the human who launched it. See the Agentic AI Identity Guide.
How does it prove that? Authentication of the agent as a workload, to tools, APIs, MCP servers and other agents. See the Agent-to-Agent Authentication Guide.
Whose authority is it using? Delegation from a user or system, expressed so that downstream services can see both the agent and the principal.
What may it do now? Authorisation at token issuance, at the tool gateway and at the resource. See the AI Agent Authorisation Guide.
Who answers for it? Governance: inventory, ownership, access reviews and decommissioning. See the Identity Governance for AI Agents Guide.

Out of scope here, and covered by sibling pillars: runtime guardrails and monitoring (the Agent Controls and Monitoring Guide), how agents are attacked (the Agent Threats and Attacks Guide) and policy and accountability (the Agent Governance and Risk Guide). If you are unsure what counts as an agent, start with AI Agents vs Agentic AI.

Core concepts

Identity models for agents

There are four ways an agent ends up with identity in practice. Only the last two scale safely.

Model	How it works	Accountability	When it is acceptable
Borrowed user credential	The agent runs with the developer's or user's own token, session or API key	None: logs show the human, not the agent	Local experimentation on non-production data only
Shared service account or API key	Several agents, or an agent and other software, use one account or key	Weak: you cannot tell which agent acted	Never for production; a common pilot shortcut that survives into production
Dedicated agent identity	Each agent is registered as its own OAuth client, service principal or workload identity	Good for the agent; principal is invisible unless delegation is added	Autonomous agents that do not act for a specific user
Agent identity plus delegation	Agent workload identity, plus a token that names the user as subject and the agent as actor	Full: both parties are visible in every call	Assistants and copilots acting for users; multi-agent chains

The IETF individual draft on WIMSE applicability for AI agents describes the same target state: agents with their own identities, automated short-lived credentials, narrow task-specific tokens and a credential that binds the agent to an accountable owner. It is an individual draft, not a working group document, so treat it as direction rather than a standard.

Delegation versus impersonation

RFC 8693 (OAuth 2.0 Token Exchange) draws the line that matters most for agents. In impersonation the agent receives the user's rights and is indistinguishable from the user. In delegation the agent keeps its own identity while acting for the user, and the issued token records it in the act claim; nested act claims record earlier actors in a chain, and only the current actor should drive access decisions. The may_act claim lets an authorisation server check that a given agent is allowed to act for a given subject. Prefer delegation everywhere: impersonation destroys the audit trail. See the OAuth Token Exchange and Delegation Guide.

Choosing a credential

Credential	Replay resistance	Typical lifetime	Best fit for agents
Static API key	None	Until someone rotates it	Avoid; if a vendor offers nothing else, vault it and broker access
OAuth client credentials with client secret	Low (bearer)	Minutes to an hour per token	Simple internal agent-to-API calls
OAuth with `private_key_jwt`	Bearer unless constrained	Minutes	Agents registered with another organisation's authorisation server
mTLS certificate-bound tokens (RFC 8705) or DPoP (RFC 9449)	High: token bound to a key	Minutes	Production agents; DPoP where TLS terminates at a proxy
Workload identity (SPIFFE SVID, cloud workload identity federation)	High at transport layer	Short, rotated by the platform	Agents running as workloads on platforms you control

RFC 9700 (OAuth 2.0 Security Best Current Practice) recommends sender-constrained tokens through mTLS or DPoP and audience-restricted access tokens, and requires PKCE for public clients. For workload options see the Cloud Workload Identity Guide, the SPIFFE and SPIRE Guide and the Workload Identity Federation Guide.

Identity in MCP

The Model Context Protocol authorisation specification (revision 2025-06-18) makes authorisation optional, but where an HTTP-based MCP server implements it the rules are specific: the MCP server is an OAuth 2.1 resource server, it must publish OAuth 2.0 Protected Resource Metadata (RFC 9728) and answer unauthenticated calls with 401 and a WWW-Authenticate header, clients must send the RFC 8707 resource parameter naming the server's canonical URI, and servers must reject tokens not issued for them. The server must not pass through the token it received to upstream APIs: it obtains its own token as a client. STDIO servers should take credentials from the environment instead, which is exactly why local MCP configuration files become secret stores. See the MCP Security Guide.

Authorisation concepts

Least agency: OWASP's extension of least privilege to autonomy itself: do not give an agent tools or decisions it does not need.
Intersection rule: an agent acting for a user gets at most what the user may do, what the agent may do and what the task requires, whichever is smallest.
Per-action decisions: evaluate each tool call against policy outside the model; prompts express intent, enforcement points stop actions.
Fine-grained grants: OAuth Rich Authorization Requests (RFC 9396) expresses "this account, this amount" rather than a broad scope. See the OAuth Rich Authorization Requests (RAR) Guide.
Just-in-time access: grants exist for the task and expire with it. See the JIT Access Guide.

Main threats

Identity is where agent compromise turns into business impact. The threats below are identity threats specifically; the wider attack surface (goal hijacking, memory poisoning, tool misuse) is covered in the Agent Threats and Attacks Guide.

Threat	What happens	Framework reference	Primary control
Credential harvesting from agent configuration	Keys in MCP config files, environment variables or agent settings are read by malware or a hijacked agent	ATLAS AML.T0083 Credentials from AI Agent Configuration; ATT&CK T1552.001	Brokered, short-lived credentials; no plaintext secrets on disk
Credential harvesting through tools	An agent is induced to use its tools to retrieve secrets it can reach	ATLAS AML.T0098 AI Agent Tool Credential Harvesting	Scope tool access; secrets never returned into context
Token theft and replay	A stolen bearer token is replayed from elsewhere	ATT&CK T1528, T1550.001	Sender-constrained tokens, short lifetimes, audience checks
Over-privileged agent identity	An agent with broad standing permissions does far more damage when it errs or is steered	OWASP ASI03 Identity and Privilege Abuse; LLM06 Excessive Agency	Task-scoped, just-in-time grants; no admin roles
Confused deputy and token passthrough	An intermediary forwards a token or consent it should not, so downstream services trust the wrong party	MCP Security Best Practices	Audience validation, per-client consent, no passthrough
Agent impersonation	Possession of a static key is the only proof of identity, so anyone holding it becomes the agent	OWASP ASI07 Insecure Inter-Agent Communication	Asymmetric credentials, signed agent metadata, mTLS
Orphaned agents	Agents outlive their project or owner and keep valid credentials	OWASP NHI Top 10 (improper offboarding)	Registry, owner attestation, automated expiry

Common failure patterns

Tokens left where the agent can find them. In the PocketOS database deletion, a coding agent working on a staging task found an account-scoped Railway token in an unrelated file and used it to delete the production database and its backups. The token had been created only to manage custom domains.
A bearer key as the only proof of identity. The Moltbook database exposure leaked about 1.5 million agent API tokens; because each key was the agent's only credential, anyone who read the table could impersonate any agent.
Handing real credentials to unvetted tools. Users of the look-alike postmark-mcp server supplied their own Postmark credentials, so the malicious version blind-copied every email using the victim's own delegated access.
Pilot permissions promoted to production. Admin or owner roles granted "to avoid permission errors" during a proof of concept are never reduced.
Forwarding the user's token down an agent chain. Every agent that sees it can use it anywhere its audience allows, and the final service cannot tell which agent called.
Authorisation written into the prompt. "Never delete anything" with no enforcement point behind it is guidance, not a control.

Key controls by maturity

The levels below follow the shape of the Agentic AI Identity Maturity Model. Most organisations should reach the second level before scaling agents beyond pilots.

Level	Identity	Credentials	Authorisation	Governance
1. Foundational	Inventory of agents, including unsanctioned ones; one identity per agent	Secrets moved out of code and prompts into a vault	Admin and wildcard permissions removed	Named owner and purpose for every agent
2. Managed	Agents registered as OAuth clients or workload identities	Short-lived tokens; audience restriction; automated rotation	Role per agent function; human approval for destructive actions	Agent identities included in access reviews
3. Delegated	Agent and principal both carried in tokens	Token exchange per hop; sender-constrained tokens (mTLS or DPoP)	Task-scoped, just-in-time grants; RAR for high-value actions	Delegation policy (`may_act`) reviewed with business owners
4. Adaptive	Attested workload identity bound to a verified build	No standing secrets anywhere in the agent path	Externalised policy engine decides every tool call with risk signals	Continuous posture checks; automatic revocation on anomaly

How to implement

Discover (weeks 1 to 3): list every agent, its runtime, the credentials it holds, where they are stored and who owns it. Include developer tools, low-code agents and MCP servers. See the Shadow AI Discovery Guide.
Separate identities: give each production agent its own identity. Retire shared keys one agent at a time, running old and new credentials in parallel for a fixed window so you can roll back by re-enabling the old credential without reissuing it.
Vault and broker: move secrets into a vault and have the runtime inject or exchange them, never the model. See the Credential Vaulting for AI Agents Guide.
Constrain tokens: shorten lifetimes to minutes, set audiences per resource, then enable certificate-bound or DPoP-bound tokens. Start resource servers in a log-only mode that records which calls would fail before enforcing.
Add delegation: introduce token exchange for user-context calls, reduce scopes at each hop and enforce may_act policy.
Gate actions: put a policy check in the tool gateway, pilot it on one agent in monitor mode, then enforce, with human approval for irreversible actions. See the Zero Trust for AI Agents Guide.
Govern: add agents to access certification, set expiry on registrations and rehearse revocation.

Decision guidance

Autonomous agent with no user: dedicated workload identity and client credentials; no delegation needed, but scope tightly because nobody's entitlements bound it.
Assistant acting for users: delegation is mandatory; the agent must never exceed the user's access, and usually needs much less.
Agents crossing organisations: register with the receiving organisation's authorisation server using asymmetric client authentication; verify the agent before trusting it. See the Know Your Agent (KYA) Guide.
Small organisations: a vault, one OAuth client per agent, token lifetimes in minutes and a gateway that checks audience cover most of the risk. Large estates should invest in a workload identity platform so no agent holds a long-lived secret.
Buying rather than building: use the AI Agent Identity Security Buyer's Guide to frame requirements.

Detection and measurement

Log, for every agent action, the agent identity (client ID or SPIFFE ID), the principal, the full act chain, the token's jti, the tool, the target and the decision. Alert on tokens presented to the wrong audience, a token or proof jti seen twice, an agent credential used from a new location, bursts of 401 and 403 responses, and scope elevation requests the MCP security guidance says servers should log.

Metric	Suggested target
Production agents with a dedicated identity and named owner	100%
Agents still using static API keys or shared accounts	Zero, each tracked to a retirement date
Median access token lifetime for agent calls	Minutes, not hours
User-context calls carrying delegation rather than a forwarded token	100%
Agent identities certified in the last review cycle	100% of production agents
Time to revoke all credentials of one agent in an exercise	Under 15 minutes

Roles and ownership

Role	Owns
Agent owner (business or product)	Purpose, risk acceptance, delegation scope, periodic attestation that the agent is still needed
IAM team	Identity issuance, authorisation server configuration, token policy, access reviews, offboarding
Platform or AI engineering	Runtime, workload identity integration, vault injection, tool gateway, logging
Security architecture	Reference patterns, approval of credential types, exceptions
Security operations	Detection rules, investigation, emergency revocation
Risk, audit and compliance	Evidence that agents are inventoried, owned and reviewed

The common gap is the agent owner. When agents are created by developers or business users in low-code tools, IAM often learns of them only at an incident. Make registration a precondition for receiving any production credential. Agents can also help run IAM itself; the Agentic AI in IAM Operations Guide covers the controls that need. For board framing, use the Board and CISO Briefing.

Standards and frameworks

Agent identity is still settling. The OAuth family is stable and usable now; agent-specific work at the IETF is mostly individual drafts, and NIST's NCCoE project on software and AI agent identity and authorisation is at the concept paper stage. Track status in the Agent Identity Standards Tracker.

Area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	Other
Agent inventory and ownership	AC-2, IA-4	ID.AM-02, GV.RR-02	A.5.16	OWASP ASI10 Rogue Agents
Agent authentication	IA-9, IA-5	PR.AA-01, PR.AA-03	A.5.17, A.8.5	RFC 8705, RFC 9449, MCP authorisation
Delegation and binding to principal	SC-23, IA-5	PR.AA-02	A.5.18	RFC 8693
Least privilege and per-action authorisation	AC-3, AC-6	PR.AA-05	A.5.15, A.8.2	OWASP ASI03; LLM06; RFC 9396
Credential protection	IA-5	PR.AA-01	A.5.17	ATLAS AML.T0083, AML.T0098; ATT&CK T1528
Logging of agent actions	AU-2, AU-12, AC-6(9)	PR.PS-04	A.8.15, A.8.16	ATLAS AML.M0029 for approvals

For the risk lists, see the OWASP Top 10 for Agentic Applications Guide and the Top 10 Agentic AI Identity Issues.

Where to go next

New to Agent Identity and Access? These are the foundational guides to read first.

Start here

Agentic AI Identity Guide: how agents get, use and lose identities across their lifecycle.
AI Agents vs Agentic AI: the terms defined and why the difference changes identity design.
Top 10 Agentic AI Identity Issues: the ten identity problems that recur in agent deployments.
Agent-to-Agent Authentication Guide: A2A security schemes, mTLS, DPoP, SPIFFE and per-hop token exchange.
AI Agent Authorisation Guide: least privilege for non-deterministic actors, access models and policy design.
Zero Trust for AI Agents Guide: applying NIST SP 800-207 to autonomous actors.
Know Your Agent (KYA) Guide: verifying external agents before you trust them.
Credential Vaulting for AI Agents Guide: keeping secrets out of prompts, code and memory with brokered access.
Identity Governance for AI Agents Guide: agent registry, ownership, reviews and decommissioning.
Agentic AI Identity Maturity Model: five levels to assess and plan your programme.
Agent Identity Standards Tracker: status of OAuth, IETF, OpenID and protocol work on agent identity.
AI Agent Identity Security Buyer's Guide: vendor-neutral requirements and proof-of-concept tests.

Browse all Agent Identity & Access guides

Practitioner checklist

Build an inventory of every agent, MCP server and agent platform, with owner, purpose and credentials held.
Give each production agent its own identity; ban shared accounts and borrowed user credentials outside sandboxes.
Move every agent secret into a vault or broker and confirm none appear in prompts, config files, repositories or memory.
Set agent token lifetimes in minutes, enforce audience checks and plan sender-constrained tokens.
Use token exchange with an act claim for user-context calls; never forward the user's original token.
For MCP servers over HTTP, confirm RFC 9728 metadata, RFC 8707 resource indicators, PKCE and no token passthrough.
Remove admin, owner and wildcard permissions from all agents, and gate destructive actions with human approval.
Add agent identities to access certification and set expiry on every registration.
Rehearse revoking all credentials of one agent and measure how long it takes.

Agent Identity and Access Guide: Identities, Credentials and Authorisation for AI Agents