AI Security

AI Agent Identity: Workload Identity, Delegation, and Accountability

A practical identity architecture for AI agents: separate user, workload, service, and delegated principals while preserving accountability across every tool call.

By PermsAI Editorial Team

An AI agent should have an explicit machine identity, while retaining evidence of the human or service that initiated the work. It should not silently become the user or disappear behind a shared service account. The design must answer five questions for every consequential call: Who is acting? On whose behalf? Using which credential? Under which policy? Can the action be attributed later?

This is an identity problem before it is an authorization problem. Identity establishes the principals involved; authentication proves a claimed identity; delegation carries bounded authority from one principal to another; authorization decides whether a particular action is allowed; accountability preserves evidence of that decision and its outcome. For the companion question—what an agent may do—see AI Agent Permissions: Least-Privilege Authorization by Design.

The five concepts teams must keep separate

Concept	Question it answers	Example evidence
Identity	Who or what is this principal?	User ID, workload ID, service principal
Authentication	How was that claim verified now?	Signed assertion, certificate, authenticated session
Authorization	May this principal perform this action on this resource?	Policy decision with constraints
Delegation	Why may this actor exercise some authority for another principal?	Consent or grant, scope, audience, expiry
Accountability	Can investigators reconstruct and attribute the action?	Correlated decision, tool, resource, time, result

Authentication does not itself confer permission. A valid workload certificate can prove that a caller is agent-prod-17 while policy still denies it access to a customer record. Likewise, an access token is not a complete identity model: it is a credential whose claims and issuer must be interpreted by a relying service.

Why tool-using agents need explicit identity

A chat model that only returns text may stay inside one application session. A tool-using agent crosses boundaries: it reads a queue, calls APIs, delegates work, waits, resumes, and may run after the initiating user has left. Multi-step plans can span processes and services. Machine-to-machine calls may be retried by workers that never held the original browser session.

If every hop uses the user's token, the system cannot reliably distinguish a human click from autonomous execution. If every hop uses one API key, it cannot distinguish agents, tenants, or jobs. Explicit identity lets policy, evidence, and revocation follow the actual execution topology.

NIST's AI Agent Standards Initiative identifies agent authentication and identity infrastructure as a foundation for secure human-agent and multi-agent interaction. The related NCCoE project is active work, so its concept paper should be treated as direction-setting—not a finished universal agent-identity standard.

User, agent, workload, service, and delegated identities

Real systems usually need more than one principal:

A user principal represents a human or organizational user authenticated to the application.
An agent or workload principal represents the running agent instance, worker, deployment, or controlled execution environment.
A service principal represents an application or backend service acting for its own operational purpose.
A delegated identity records that an actor is exercising a bounded grant associated with another principal.

The useful choice depends on the action. A personal assistant reading a user's calendar may need user delegation plus its own workload identity. A nightly compliance agent may act as a service workload without a current user. A deployment agent may require a service identity and a separately approved change grant. One model does not fit every system; the invariant is that the actual actor and the authority source remain distinguishable.

Acting as the user: useful, but easy to overstate

User delegation is appropriate when the resource belongs to the user and the user intentionally asks the application to act—for example, drafting a calendar event in that user's account. The grant should cover the requested resources and actions, for a bounded period, with a clear way to revoke or reauthorize it.

Blind impersonation is different. Copying a broad user token into every worker can give the agent all of the user's rights, outlast the session, and make autonomous changes look like direct human activity.

Prefer a representation that can preserve both parties: the user remains the subject or authority source, while the agent or application is recorded as the actor. If a downstream protocol cannot express that relationship, keep it in signed gateway context and correlated audit events instead of pretending the ambiguity does not exist.

Acting as a service or workload

An agent performing application-owned work should normally authenticate as a dedicated machine principal. Platform-issued workload identity, a dedicated service principal, or an equivalent machine identity lets services distinguish deployments and apply policy without borrowing a human password.

Scope the identity at a boundary that supports containment. One identity for every agent recreates the shared-account problem; an identity per ephemeral process may be noisy. A practical boundary might be application, environment, agent role, and tenant, with job-level correlation.

Workload authentication is only the entrance check. The target still needs an authorization decision for the requested action. SPIFFE illustrates a vendor-neutral pattern: a workload proves a SPIFFE ID using a short-lived X.509 or JWT identity document delivered through a Workload API, avoiding a bootstrap secret embedded in the application. Other platforms provide different mechanisms; the principle is environment-attested, rotatable machine identity rather than a copied static key.

Delegation must be explicit and bounded

Delegation means one principal grants a subset of authority to another actor. A defensible grant identifies at least:

the delegating principal and the acting principal;
permitted actions or scopes and protected resources;
the intended audience or receiving service;
issuance and expiration time;
conditions such as tenant, environment, purpose, or approval;
revocation and reauthorization behavior.

Do not infer delegation merely because the agent can access a user's session. Consent at login is not perpetual consent for any future tool call. Long-running agents need rules for expiry: stop, continue with service-owned operations only, or request fresh authorization.

At the OAuth architecture level, an access token represents authorization for a protected resource. Scope describes a class of access; audience or resource limits where the token is accepted; expiry bounds time. RFC 8707 defines resource indicators that help an authorization server issue audience-restricted tokens. RFC 8693 defines token exchange, including delegation and impersonation semantics and an act actor claim. Support is deployment-specific: do not invent a token-exchange flow where the authorization server and target service do not implement it.

Sender-constrained tokens can require proof from the intended presenter, reducing the value of a copied bearer token. They do not prove the business action is legitimate.

The PermsAI Agent Identity Chain

Treat identity as a chain of evidence, not one username propagated everywhere:

Human/User Principal → Application → Agent Workload Identity → Tool Gateway → Target Service

Hop	Identity	Credential	Delegation evidence	Authorization boundary	Audit evidence
User → application	Human user	Authenticated session	Request, consent, selected account	Application action gate	User, session, request ID
Application → agent	App plus agent workload	Workload assertion	Job envelope with user/grant reference	Agent scheduler	Creator, agent ID, purpose, expiry
Agent → gateway	Agent workload	Short-lived workload credential	Bounded tool request	Tool gateway policy	Agent, tool, arguments digest, decision
Gateway → service	Gateway/service actor	Audience-bound downstream credential	User/agent delegation claims or correlation	Target API	Actor, subject, scope, resource, result

This chain avoids forwarding the raw user token through every component or erasing the user behind a gateway account. Each service receives only the identity and authority evidence it needs; model context usually needs no credential.

Identity propagation without token forwarding

For User → App → Agent → Tool Gateway → Downstream service, decide separately which identity, credential, and context cross each boundary. Never equate propagation with copying the incoming token.

The application can create a signed job envelope naming the user and approved purpose. The agent authenticates with its workload identity; the gateway validates both, applies policy, and obtains a target-restricted credential. Audit IDs link the chain without putting tokens in prompts or traces.

Trust must be re-evaluated at every hop. A downstream service should validate issuer, audience, lifetime, and expected actor—not accept identity headers from any caller. If the chain becomes too long or ambiguous, require a fresh authorization decision rather than silently extending it.

Accountability is designed, not inferred

For every consequential tool call, preserve the initiating human or service principal, agent/workload identity, delegated scope and expiry, authorization decision and policy version, tool, resource, tenant, timestamp, result, and correlation ID. Record approvals and denials. Protect logs from tampering, restrict their sensitive fields, and synchronize time.

Accountability does not mean storing hidden model reasoning. Inputs, normalized requests, policy decisions, tool calls, and observable results are stronger operational evidence than an unverifiable narrative of why a model acted. The broader AI Agent Security guide explains how this evidence fits system-level controls.

Identity between agents

When Agent A calls Agent B, treat B as another workload and delegation boundary. B authenticates A, verifies the grant, rejects authority amplification, and records both identities. B should not inherit every capability A has or receive the user's credential as if it were the original application.

Credential lifecycle supports identity

An identity is operational only when its credentials can be issued, scoped, used, rotated, expired, revoked, and audited. Prefer short-lived, automatically rotated credentials; bind them to the expected workload and audience where supported; and maintain a rapid disable path for the workload and its active grants. For credential custody and lifecycle, see Secure Credential Handling for AI Agents; identity design should not be solved by inserting secrets into model context.

Failure modes to test

One shared service account hides which agent or tenant acted.
A universal API key turns compromise of one tool into compromise of every tool.
A user token copied into queues, prompts, and workers expands both exposure and authority.
Logs record only the user or only the gateway, erasing the actual actor chain.
Tokens lack audience restriction and are accepted by unintended services.
Delegations have no expiry, revocation, or reauthorization path.
Agent-to-agent calls amplify scope or drop the initiating principal.
Retries create actions without a stable job and decision correlation ID.

Design checklist

Inventory human, agent, workload, service, and delegated principals.
Choose when an action is user-delegated versus service-owned; document the rule.
Give production agents dedicated workload identities instead of shared credentials.
Authenticate every service hop and authorize every action separately.
Bound delegation by action, resource, tenant, audience, time, and purpose.
Propagate identity evidence, not raw user tokens, unless a reviewed protocol requires the token.
Preserve subject, actor, grant, policy decision, resource, timestamp, and result in correlated audit events.
Make grants and workload credentials revocable; test expiration during long-running work.
Test cross-agent, cross-tenant, replay, confused-deputy, and actor-erasure cases.
Re-review identity boundaries whenever a new tool, agent, or downstream service is added.