Definition
An AI agent identity is a verifiable, revocable, auditable identifier (and associated credential) that represents a specific running agent instance. It answers four questions simultaneously:
- Who am I?, a unique identifier for this agent instance (not just the model or the application).
- Who authorised my existence?, the tenant, user, or system that caused this agent to be instantiated.
- What may I do?, the scope of tools, data, and actions authorised for this instance.
- On whose behalf am I acting right now?, the principal whose delegation chains into this specific action (which may differ from the agent's owner).
A sufficient agent identity system makes these four facts independently verifiable by any tool or service the agent interacts with, produces an audit trail that a regulator can reconstruct, and can be revoked in bounded time when any of the four answers change.
The three-tier identity model
The operational pattern that works in production is a three-tier identity model. Each request an agent makes carries three identities, not one:
- User identity (the principal). The human, or upstream system, on whose behalf the work is being done. Carried as an OAuth access token, SAML assertion, or similar. This is the identity whose permissions ultimately bound what may happen.
- Agent identity (the actor). The running agent instance itself. This is the workload identity, ideally a short-lived, workload-attested credential (SPIFFE SVID, OIDC token bound to the agent's runtime) that a downstream service can verify cryptographically without reference to the upstream user.
- Tool identity (the context). The specific tool, MCP server, or integration the agent is calling. Downstream services use this to reason about what kind of action they're seeing, and to apply tool-specific policy.
Mature implementations carry all three: the access token (delegated user scope), the agent workload credential (proves the caller), and the tool context (shapes policy). Poor implementations carry only the first, which means the downstream system cannot distinguish a human using the system directly from an agent acting on the human's behalf, and the audit trail loses crucial information.
act claim in a JWT, the claim that says "the principal is X, but the actor performing this request is Y."
Agent identity vs service account
It is tempting to implement agents as service accounts, issue a token, let the agent use it, call it done. This works until it doesn't, for several reasons:
| Dimension | Service account | Agent identity |
|---|---|---|
| Instantiation cardinality | A small, stable set (tens to thousands). | Potentially unbounded, one per session, per task, per delegation chain. |
| Behaviour envelope | Deterministic, human engineer wrote the integration code. | Probabilistic, tool selection is model-dependent. |
| On whose behalf? | Usually itself. Occasionally an explicit OBO flow. | Almost always on behalf of a user, sometimes chained through another agent. |
| Scope granularity | Typically static, issued at account creation. | Ideally per-invocation, bounded to the immediate task. |
| Revocation pressure | Low, rotation on key schedule. | High, must be instantly revocable on prompt-injection detection or scope drift. |
| Audit expectation | "This account did X at time T." | "This agent, instantiated by user U at T0, calling tool T1 with prompt P, produced action A at T2, which was reviewed by approval A1." |
A service account is the right primitive for long-lived integrations. For agents, the right primitive is a short-lived, workload-attested identity that can be materialised at session start and destroyed at session end, more analogous to a Kerberos ticket or an SVID than to an API key.
What an agent identity should carry
A well-formed agent identity credential (typically a JWT or X.509 certificate) should carry at minimum:
- Subject identifier, unique per agent instance. Not per agent definition, per instance.
- Issuer, the identity provider that vouches for this instance.
- Tenant, the organisation on whose behalf the agent is operating.
- Agent type / definition, what kind of agent this is (e.g.
customer-support-tier-1,devops-assistant), for policy decisions. - Actor claim, in delegated flows, the principal whose permissions bound the action (the
actclaim in RFC 8693). - Scope, the set of actions authorised, ideally bounded to the current task.
- Expiry, short. Minutes, not hours. Certainly not days.
- Workload attestation reference, proof that the credential was bound to a specific runtime (device, cluster, cryptographic attestation). This is what makes the credential not-portable, the property that separates a workload-attested identity from a string that can be stolen.
- Instance correlation ID, to link audit events from the credential issuance through to every tool call.
Issuance patterns
Three patterns are in production use:
Pattern 1: SPIFFE/SPIRE with workload attestation
The agent runs as a workload in a SPIRE-managed cluster. At startup, SPIRE's node attestor verifies the runtime (Kubernetes pod identity, cloud instance identity document, TPM), and the workload attestor verifies the specific agent process. An SVID is issued to that process. Downstream MCP servers or tools verify the SVID. Short-lived, cryptographically attested, workload-bound. See SPIFFE/SPIRE.
Pattern 2: OAuth 2.1 + OIDC with OBO token exchange
The agent authenticates to the IdP at session start, receiving an agent-level OIDC token. When it acts on behalf of a user, it performs an OAuth 2.0 Token Exchange: presenting the user's access token as a subject_token and its own token as an actor_token. The IdP issues a new token carrying both identities. This is the emerging pattern for SaaS-integrated agents where the tools are HTTP APIs.
Pattern 3: WIMSE (IETF, in progress)
The IETF Workload Identity in Multi-System Environments (WIMSE) working group is standardising a workload identity model that extends beyond single-cluster SPIFFE. As of draft-ietf-wimse-arch-07 (March 2026), the architecture covers cross-trust-domain workload identity, directly relevant to agents that traverse clouds, SaaS tenants, or organisational boundaries. See IETF WIMSE.
Verification
Verification on the tool side is the part most early MCP deployments have got wrong. A downstream tool server should:
- Verify the agent identity credential signature against the issuer's public key.
- Confirm the credential has not expired, has not been revoked, and has not been reused beyond its nonce / one-time semantics if applicable.
- Inspect the actor claim (if present) and apply combined policy: the action must be permitted under both the actor's scope and the principal's permissions. Either denies.
- Verify the credential is bound to the calling connection (proof of possession / DPoP, mTLS, or similar). A bearer-only token is a credential anyone who intercepts it can replay.
- Log the full identity tuple (principal, actor, tool, action, correlation ID) to the audit system.
Any tool that skips step 4 is vulnerable to credential replay exactly as the Okta HAR file breach was. Any tool that skips step 3 cannot enforce delegated-scope policy. Any tool that skips step 5 cannot be audited.
Open problems
- Prompt injection as an identity problem. When untrusted input causes an agent to act outside its intended behaviour envelope, the agent's identity is still valid, but the intent it represents is not. Mapping "this looks legitimate cryptographically but illegitimate semantically" into an identity-layer signal is an open research problem.
- Cross-agent delegation. Agent A calls agent B, which calls tool T on behalf of user U. RFC 8693 supports chained actor claims in principle, but real-world tool implementations rarely validate them. Chains longer than one hop are essentially un-auditable today.
- Agent lifecycle. An agent's "lifetime" is frequently shorter than the time horizons the existing IAM provisioning/deprovisioning systems were built for. Event-driven issuance and revocation is the right pattern; most organisations aren't there yet.
- Accountability. When an autonomous agent does something wrong, the legal question of attribution (to the human operator, the developer, the tenant, the model provider) is unsettled. Identity systems will be asked to produce evidence; the evidence needs to be legible to non-specialists.
FAQ
Is an AI agent a non-human identity?
Yes. It is a specialised one, but it is firmly in the NHI category, every authoritative framework treats it as such. See What is non-human identity.
Can I just use service accounts for agents?
You can for toy deployments. For anything that acts on behalf of users or handles regulated data, the service account model will not give you the delegation semantics or the audit fidelity you need.
Is MCP authentication a solved problem?
No. The MCP authorisation specification continues to mature. Current production deployments typically layer OAuth 2.1 over MCP's transport, but the conventions for tool-level policy, scope narrowing, and actor propagation are still being worked out. See MCP security.
Assess your own NHI programme.
Run the free maturity assessment or the OWASP NHI Top 10 self-audit, get your score in the browser, and unlock the full written report.