Agentic AI Identity Guide: How AI Agents Get, Use and Lose Identities

Every AI agent that calls an API, reads a database or talks to another agent needs an identity, and most today do not have a proper one. They borrow a developer's token, share a service account, or run on an API key pasted into a configuration file. That makes it hard to know which agent did what, on whose behalf, and with what authority, and harder still to stop it. This guide explains how AI agents obtain, use and lose identities: the main identity models, how delegation from users works, how to register, authenticate and retire agents, and a maturity path from borrowed credentials to attested, short-lived agent identities.

Key takeaways

• An AI agent is a non-human identity (NHI) that makes its own decisions about when to use its access. It needs everything a service account needs (owner, inventory, least privilege, rotation, offboarding) plus controls for delegation and autonomy.
• There are three identity models: the agent acts as itself, the agent acts on behalf of a user, or a hybrid where the agent has its own identity and carries delegated authority from a user. The hybrid model is the one to aim for in most enterprise use cases.
• The two anti-patterns to remove first are agents using human credentials and agents sharing static secrets. Both destroy attribution and make revocation all-or-nothing.
• Standards are converging on existing building blocks, such as OAuth 2.0 and 2.1, token exchange, workload identity (SPIFFE, WIMSE) and signed agent metadata, rather than inventing a new identity type from scratch.

Why agent identity is different

A traditional service account runs code that behaves the same way every time. An AI agent decides its next step at runtime, based on a goal, its instructions and whatever it has just read. That creates identity problems that static NHIs do not have:

• Non-deterministic use of access. The same agent with the same credentials may take different actions on different days. You cannot infer its behaviour from its code alone.
• Delegation is the norm. Many agents act for a person. The downstream system needs to know both who the agent is and whose authority it is exercising.
• Input can redirect it. Content an agent reads (email, web pages, tool output) can carry instructions. OWASP lists this as ASI01, Agent Goal Hijack, in its Top 10 for Agentic Applications.
• Agents create and discover credentials. Coding and operations agents can find tokens in files, create API keys and spin up new service accounts, adding NHIs that nobody registered.
• Lifecycles are short and numerous. Agents may be created per task or per session, so manual onboarding processes cannot keep up.

OWASP's ASI03, Identity and Privilege Abuse, sums up the result: most agentic systems lack real, governable identities, so agents inherit context, credentials or privileges in ways that IAM systems were not designed to track.

The three agent identity models

Model 1: The agent acts as itself

How it works: the agent has its own NHI, such as a workload identity, an OAuth client using the client credentials grant, or a cloud IAM role. It authenticates as itself and its permissions are set for its function.

Fits: back-office automation with no specific user behind each request, such as a security triage agent reading alerts or a cost-optimisation agent.

Watch for: permissions sized for every possible task the agent might do, rather than the task in hand. Because there is no user in the chain, the agent's own permissions are the only limit.

Model 2: The agent acts on behalf of a user

How it works: the user authorises the agent, typically through an OAuth consent flow, and the agent receives a token scoped to that user. Downstream systems see the user's identity.

Fits: personal assistants and copilots working in a user's mailbox, calendar or files.

Watch for: downstream systems cannot tell whether the user or the agent took an action, so audit trails and anomaly detection break down. Broad consent scopes give the agent everything the user has. This is impersonation, not delegation, unless the token also identifies the agent.

Model 3: Hybrid, with the agent's own identity carrying delegated authority

How it works: the agent authenticates as itself and presents a token that also records the user who delegated authority, narrowed to the task. OAuth 2.0 Token Exchange (RFC 8693) supports this through the act (actor) claim, which records the party acting on behalf of the subject. Each hop can exchange the token it received for a new one scoped to the next audience.

Fits: most enterprise agents that act for users against business systems.

Why it is the target: the resource server can apply policy to both identities ("this user, via this agent, may do this"), logs attribute actions correctly, and the agent's access can be revoked without touching the user's, and vice versa.

The agent identity lifecycle

Agent identities follow the same lifecycle as other NHIs, set out in our NHI Lifecycle Management Guide, with some agent-specific additions. The contributed article Managing AI Agent Lifecycles covers the same ground from a governance platform perspective.

1. Registration

Register every agent before it receives credentials. The minimum record is:

• A unique agent identifier, not shared with any other agent or workload.
• A named human owner (and a team) accountable for its behaviour.
• Its purpose and the business process it supports.
• The model and version it runs, the framework and the hosting platform.
• The tools, MCP servers, data sources and other agents it may call.
• Its identity model (itself, on behalf of users, or hybrid) and its autonomy level, including which actions need human approval.
• A risk rating and a review date.

An agent registry, whether a dedicated product, an extension of your IGA platform or a configuration management database (CMDB) record type, is the system of record. Unregistered agents should be treated as shadow AI and blocked from receiving production credentials.

2. Credential issuance and authentication

Give each agent credentials that are short-lived, bound to it and issued by a platform rather than stored in its configuration. In order of preference:

• Platform-issued workload identity (cloud IAM roles, managed identities, Kubernetes service account tokens, SPIFFE SVIDs), so the agent never holds a long-lived secret.
• OAuth access tokens obtained with private_key_jwt or mutual TLS client authentication, with audience restriction and short expiry.
• Sender-constrained tokens (mTLS-bound or DPoP) for high-value APIs, so stolen tokens cannot be replayed.
• Static API keys only where a third party offers nothing better, stored in a secrets manager, scoped narrowly and given an expiry.

The NHI Authentication Guide compares these methods in detail. The contributed article How to Authenticate AI Agents ranks them specifically for agents.

3. Delegation

When an agent acts for a user, delegation should be explicit, narrow and visible:

• Ask for consent to specific scopes for a specific task, not blanket access to the user's account.
• Use token exchange at each hop so every downstream service receives a token for its own audience, carrying both the agent and the user.
• Never forward the user's original token to other services. The Model Context Protocol authorisation specification explicitly forbids MCP servers from accepting or passing through tokens that were not issued for them.
• For high-risk actions, get fresh approval from the user out of band. OpenID Connect Client-Initiated Backchannel Authentication (CIBA) is one pattern for asking a user to approve an action on a separate device.

4. Runtime governance

Because an agent's behaviour can change with its inputs, identity controls continue at runtime:

• Authorise each action, not only the start of the session. See the AI Agent Authorisation Guide.
• Log the agent identity, the delegating user, the tool called and the outcome for every action.
• Baseline normal behaviour per agent and alert on deviations: new tools, new data, unusual volumes or times.

5. Change, review and retirement

• Treat a change of model, prompt, tools or autonomy level as a change to the identity that triggers re-review.
• Review agent entitlements on a schedule, as you would privileged human access.
• Retire agents deliberately: revoke tokens and grants, delete credentials, remove registry entries and archive logs. Improper offboarding is the first risk in the OWASP NHI Top 10 (NHI1), and short-lived agents make it easy to leave grants behind.

Attestation: proving what the agent is

Authentication proves an agent holds a credential. Attestation goes further and proves what is running: which workload, on which platform, with which code or configuration. Workload identity systems such as SPIRE (the SPIFFE runtime) attest the workload before issuing identity documents. For agents, attestation can extend to the model version, system prompt and toolset, so that an agent whose configuration changes does not keep its old identity. This area is still maturing. The IETF Workload Identity in Multi System Environments (WIMSE) working group and several individual drafts are exploring how agent identity builds on workload identity; our Agent Identity Standards Tracker follows where that work stands.

Common failure patterns

• Agents running on a developer's personal token. Every action looks like the developer, access is far broader than needed, and the token outlives the project. This maps to OWASP NHI10, Human Use of NHI, in reverse: machine use of human identity.
• One service account for all agents. No attribution, no per-agent revocation, and one compromise exposes everything (OWASP NHI9, NHI Reuse).
• Over-scoped tokens discovered at runtime. In the PocketOS incident, a coding agent located an API token with blanket authority and used it to delete a production storage volume and its backups.
• Agent credentials exposed through the agent platform. The Moltbook breach exposed AI agent keys at scale; the CoPhish campaign abused Copilot Studio agents to harvest OAuth tokens.
• Orphaned agents. Pilots end, owners move on, and the agent's OAuth grants and keys remain active.

A maturity path for agent identity

1. Discover. Find the agents you already have, including those built by business teams and AI tools with OAuth access to corporate data. See the Shadow AI and AI Agent Discovery Guide.
2. Separate. Move every agent off human credentials and shared secrets onto its own identity.
3. Register and own. Put every agent in a registry with an accountable owner and purpose.
4. Shorten and scope. Replace long-lived keys with short-lived, audience-bound tokens issued by a platform.
5. Delegate explicitly. Adopt the hybrid model with token exchange for agents acting for users.
6. Attest and adapt. Bind identity to attested workload and agent configuration, and authorise each action in context.

The Agentic AI Identity Maturity Model expands these stages into a self-assessment.

Practitioner checklist

• Every agent has a unique identity, a registry entry and a named human owner.
• No agent runs on a human's credentials or on a secret shared with other agents or workloads.
• Agent credentials are short-lived, audience-bound and issued by a platform; any static keys are vaulted, scoped and set to expire.
• Agents acting for users use delegated tokens that identify both the user and the agent; user tokens are never passed through.
• High-impact actions require fresh human approval enforced outside the model.
• Changes to model, prompt, tools or autonomy trigger re-review of the agent's access.
• Retirement revokes every token, grant and key, and is verified.

Standards and references

• OWASP Top 10 for Agentic Applications for 2026: ASI03 Identity and Privilege Abuse
• OWASP Non-Human Identities Top 10 (2025): NHI1 Improper Offboarding, NHI5 Overprivileged NHI, NHI9 NHI Reuse, NHI10 Human Use of NHI
• RFC 8693: OAuth 2.0 Token Exchange (actor claim for delegation)
• Model Context Protocol: Authorization specification
• OpenID Connect Client-Initiated Backchannel Authentication (CIBA)
• SPIFFE concepts and the IETF WIMSE working group
• NIST NCCoE: Software and AI Agent Identity and Authorization
• OpenID Foundation AI Identity Management Community Group

Related NHI Mgmt Group resources: AI Agents vs Agentic AI · AI Agent Authorisation Guide · NHI Authentication Guide · NHI Lifecycle Management Guide