AI Agent Identity and On-Behalf-Of Authorization

What does “on behalf of” mean for an AI agent?

An AI agent acts on behalf of a user when the agent keeps its own identity while exercising a limited set of authority delegated by that user. A downstream service should be able to determine both the subject whose authority is being used and the actor performing the operation. This is delegation, not simply copying the user's credential or presenting the agent as if it were the user.

Delegation creates an attributable chain of authority: “agent A performed action X on behalf of user U.” It does not prove that user U intended action X. A prompt injection, malicious tool result, or planning error can steer an authenticated agent while it continues to use valid delegated credentials. Identity establishes who is involved; runtime authorization must still decide whether a specific action should proceed.

1
Controlling user (subject)
2
    |
3
    | delegates bounded authority
4
    v
5
Logical agent (actor)
6
    | policy and capability profile
7
    |
8
    | executed by
9
    v
10
Workload identity
11
    | deployed process or job
12
    |
13
    | presents delegated authority
14
    v
15
Target resource
16
    | validates and executes the action

Which identities exist in an agentic workflow?

Agentic identity is not one identifier. A production workflow can involve at least five distinct principals or security contexts:

These identities may map to the same component in a simple application, but they answer different security questions. The user explains whose authority is in use. The logical agent identifies which policy and capabilities apply. The workload proves which deployed software is executing. The OAuth client identifies who requested a token. The target resource constrains where that token is valid.

Do not accept an agent or user identifier merely because it appears in a request body, prompt, or model-generated tool argument. Identity used for authorization must come from a trusted issuer, authenticated session, workload credential, or server-controlled mapping.

Where do OpenID Connect and workload identity fit?

OpenID Connect authenticates the user and gives the application verifiable identity claims. An OIDC ID token is evidence for the client that authentication occurred; it is not a general-purpose credential to forward to downstream APIs. OAuth access tokens carry delegated API authorization, while the authorization server and resource server define what their scopes and claims mean.

Workload identity authenticates the software instance executing the agent. It can prove that a token exchange request came from the production invoice worker rather than a developer laptop or an arbitrary process holding a copied user token. Validate workload issuer, audience, environment, deployment, and service constraints before mapping that workload to a logical agent.

The logical agent identity sits above the workload. Several short-lived workers may execute the same agent:invoice-reviewer policy, while one workload may host several agents with different capability sets. Preserve both when the distinction affects authorization or audit. Do not assume that an OAuth client_id, workload subject, and logical agent name are interchangeable.

1
OIDC session
2
    | Which user authenticated?
3
    +-- subject: user:alice
4

5
SPIFFE/SPIRE
6
    | Which deployed process is running?
7
    +-- workload: prod/invoice-worker
8

9
Application map
10
    | Which logical agent policy applies?
11
    +-- actor: agent:invoice-reviewer

Authentication, delegation, and impersonation are different

Authentication verifies a principal. Delegation allows one principal to retain its identity while representing another. Impersonation makes the actor indistinguishable from the subject within the rights granted by the token.

OAuth 2.0 Token Exchange defines these delegation and impersonation semantics. Delegation is usually the safer model for agents because it preserves attribution and lets policy distinguish the agent from the user. Impersonation may be necessary for a legacy resource, but it weakens local auditability and should be narrowly scoped, short-lived, and recorded by the token service.

How OAuth token exchange represents “on behalf of”

RFC 8693 defines an OAuth extension in which a client presents one security token and requests another token appropriate for a target resource. For delegation, the request can contain:

• a subject_token representing the party on whose behalf the request is made;
• an actor_token representing the acting party;
• resource or audience values restricting the target service; and
• scope values describing the requested authority at that target.

A simplified token exchange request looks like this:

1
Authorization server
2
    | receives
3
    +-- subject_token
4
    +-- actor_token
5
    |
6
    | validates delegation,
7
    | audience, and scope
8
    v
9
Downscoped access token
10
    |
11
    v
12
Target resource API

1
POST /oauth/token HTTP/1.1
2
Host: identity.example
3
Content-Type: application/x-www-form-urlencoded
4

5
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
6
&subject_token=USER_ACCESS_TOKEN
7
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
8
&actor_token=AGENT_WORKLOAD_TOKEN
9
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
10
&resource=https://payments.example/api
11
&scope=invoices:read payments:create

The authorization server must authenticate the client, validate both input tokens, confirm that this actor may receive delegated authority from this subject, and apply policy for the requested resource and scope. The exact token types, claims, actor mapping, and support for token exchange depend on the identity provider.

Request one target and the minimum scopes required for the next operation. RFC 8693 notes that combining multiple audiences or resources with multiple scopes creates the Cartesian product of those rights. Broad exchange requests are therefore easier to misuse and harder to reason about than one audience-specific, downscoped token.

How do the sub, act, and may_act claims work?

When the issued credential is a JWT, RFC 8693 defines claims that can preserve delegation semantics:

• sub identifies the subject whose delegated authority the token represents.
• act identifies the current actor to whom that authority has been delegated.
• may_act can state which party is eligible to become an actor for the subject.

An illustrative delegated token could contain:

1
{
2
  "iss": "https://identity.example",
3
  "aud": "https://payments.example/api",
4
  "sub": "user:alice",
5
  "act": {
6
    "sub": "agent:invoice-reviewer"
7
  },
8
  "scope": "invoices:read payments:create",
9
  "exp": 1786467600
10
}

The top-level claims define the token's validity and authority. Claims inside act identify the actor; expiry, audience, and other token-validity claims are not meaningful inside that object. A resource server should validate the top-level issuer, signature, audience, time bounds, and scopes before using sub and the current act identity in policy.

The presence of act is not evidence that delegation is valid by itself. Trust comes from the issuer's signature and the resource server's decision to trust that issuer for this audience and claim model. Likewise, may_act is an input to authorization-server policy, not a replacement for validating the actor or applying deployment-specific delegation rules.

How should multi-agent delegation chains work?

An orchestrator may delegate work to a specialist agent, which may call another service. RFC 8693 permits nested act claims: the outermost act is the current actor, while nested actors form a historical chain. The least recent actor appears deepest in the structure.

1
{
2
  "sub": "user:alice",
3
  "act": {
4
    "sub": "agent:payments-specialist",
5
    "act": {
6
      "sub": "agent:finance-orchestrator"
7
    }
8
  }
9
}

For access-control decisions, RFC 8693 requires the consumer to consider the top-level token claims and the current, outermost actor. Prior actors are informational history, not principals whose permissions should be accumulated. Never union scopes or roles across the chain; every hop should preserve or reduce authority, set the next audience, and produce a new short-lived credential when practical.

Limit delegation depth and reject loops. Record the full chain for investigation, but keep authorization policy focused on the subject, current actor, target resource, and requested action. If a downstream service cannot validate the chain format or issuer, fail closed rather than silently treating the current agent as the user.

Why “on behalf of” does not prove user intent

A valid delegation proves a chain of authority, not approval for every action taken through that chain. Human permissions often cover work a person may perform over months. An agent is completing one task now, and untrusted content can change the plan while the credential remains valid.

For example, a user may authorize an email agent to read messages and draft replies. A malicious document can instruct the agent to attach confidential data to an external message. The token correctly proves which user and agent are involved, and the send operation may fall within a broad email:send scope. None of those facts establishes that the user intended this recipient, attachment, or disclosure.

This is an agentic confused-deputy problem: an attacker influences software that already possesses legitimate authority. Arcjet's analysis of the two speeds of AI agent runtime security describes the boundary this creates. Identity and delegation establish who the agent represents. Least privilege defines the outer boundary. Runtime governance decides whether this action should proceed now.

Authorize the action as well as the token

The target service should evaluate delegated identity together with application context immediately before a consequential operation. A useful runtime decision can include:

• controlling subject, current actor, workload, and tenant;
• token issuer, audience, client, scopes, age, and delegation depth;
• tool name, operation, arguments, and target object;
• data classification, recipient, amount, and reversibility;
• the user's task, recent approvals, and workflow state;
• prompt-injection or bot signals; and
• per-user, per-agent, and per-organization budgets.

Authorization must be object-level and action-specific. A token permitting payments:create should not automatically permit every amount, recipient, funding account, or sequence of changes. Query resources through the subject's tenant boundary, validate model-generated arguments as untrusted input, and apply agent-specific restrictions in addition to the user's permissions.

High-impact actions may require step-up authentication or explicit approval. Bind an approval to a canonical representation of the operation—such as action type, resource, amount, recipient, and expiration—so it cannot be replayed for a materially different call. Keep the gated set small enough that reviewers inspect the request rather than approving automatically.

The AI agent runtime security guide explains how these checks fit at tool and action boundaries, including prompt-injection detection, sensitive-data controls, sequence-aware policy, and budgets.

The action gate belongs before the tool creates its side effect:

1
Model proposes tool call
2
          |
3
          v
4
Application validates arguments
5
          |
6
          v
7
Runtime policy evaluates:
8
    subject + actor + workload
9
    resource + action + approval
10
    |
11
    +-- deny
12
    |     stop and record reason
13
    |
14
    +-- approval required
15
    |     bind approval to exact action
16
    |
17
    +-- allow
18
          execute and record outcome

Provider-neutral pseudocode makes the separation explicit:

1
const action = {
2
  type: "payments.create",
3
  resource: invoice.id,
4
  amount: invoice.total,
5
  recipient: invoice.paymentAccount,
6
};
7

8
const decision = await authorize({
9
  subject: session.userId,
10
  actor: agent.id,
11
  workload: workloadIdentity.subject,
12
  tenant: session.tenantId,
13
  action,
14
  approval: workflow.approvalFor(action),
15
});
16

17
if (decision.status !== "allow") {
18
  return handleDeniedAction(decision);
19
}
20

21
const result = await payments.create(action);
22
await audit.record({ action, decision, result });

What if there is no controlling user?

Not every agent acts for an individual. A queue-driven invoice processor, scheduled monitor, or incident-response agent may run under organizational authority. Do not invent a human subject merely to fit an on-behalf-of model.

Give an autonomous agent a dedicated workload and logical-agent identity. Restrict it with service-owned scopes, tenant and resource constraints, short-lived credentials, budgets, and approval requirements for irreversible actions. Audit records should state that the agent acted under a service or organization policy rather than attributing the operation to the last person who deployed it.

When a human later approves a specific action, record that approval as separate evidence. The approver is not necessarily the subject of every prior read or planning step, and the agent remains the actor that executes the approved operation.

Constrain token lifetime, audience, and revocation

Delegated tokens should be short-lived, audience-restricted, and downscoped. Avoid placing a user's general access token in agent memory, logs, prompts, tool arguments, or long-running workflow state. Exchange it for a credential usable only by the intended resource, and store credentials outside model-visible context.

Token exchange is an issuance event, not a permanent link between input and output tokens. RFC 8693 token processing notes that exchanging a token does not invalidate the input token and does not automatically propagate later renewal or revocation to the output token. If rapid revocation matters, design it explicitly through short expirations, introspection, a revocation registry, session versioning, or provider-specific propagation.

Validate at least the signature, trusted issuer, exact intended audience, expiration and not-before times, subject, current actor, client where relevant, tenant boundary, and required scope. Reject unsupported token types or signing algorithms, unsupported delegation forms, excessive chain depth, and tokens intended for another environment or service.

What should an agentic identity audit record contain?

Record enough structured evidence to answer who acted, under whose authority, what happened, why it was allowed, and which workflow produced it:

• subject, current actor, logical agent, workload, OAuth client, and tenant;
• issuer, audience, scopes, token identifier or safe fingerprint, and delegation depth;
• tool, action, target resource, and normalized high-level parameters;
• policy version, decision, reason code, and approval reference;
• workflow and correlation IDs linking related steps; and
• timestamp, outcome, and reversible or irreversible status.

Do not copy bearer tokens, prompts, complete documents, or sensitive tool arguments into logs. Use opaque identifiers and redacted structured fields. Keep attacker-controlled evidence separate from trusted summaries so an audit or MCP tool cannot turn stored input into a new prompt-injection channel.

Tools for agentic identity and delegated authorization

No single tool implements the complete on-behalf-of chain. User authentication, delegated token issuance, workload identity, object-level authorization, and runtime action enforcement are separate jobs. Choose a component for each job and test the claims passed between them.

Which identity and authorization capabilities do AI agents need?

Which commercial identity platforms support AI agents?

• Auth0 for AI Agents provides user authentication and a Token Vault for storing external-provider credentials and exchanging an Auth0 token for a connected account's access token. It fits agents that need user-consented access to services such as Google, GitHub, Microsoft, or Slack. Check whether each target integration preserves the actor identity you need; a provider access token may represent only the user and client.
• Descope Agentic Identity Hub provides inbound OAuth applications, outbound connected applications, credential storage, user consent, and MCP authorization tooling. It fits systems that need to expose an application to agents and connect those agents to external tools. Verify tenant isolation, scope mapping, token export, and audit behavior against the target APIs you use.
• Managed fine-grained authorization, including Auth0 FGA, can store relationships such as user U can approve invoice I or agent A may read documents delegated by U. This answers object-access questions, but it does not authenticate the workload or prove that the current action matches the user's intent.

Managed token vaults reduce the need to store refresh tokens in application infrastructure. They do not make model context a safe place for access tokens, and they do not replace an application check before a payment, message, deletion, or data export.

Which open-source tools support agentic identity?

• Keycloak supports standard OAuth token exchange for issuing a token to another client in the same realm. Its current standard implementation can filter audiences and enforce downscoping, but RFC 8693 delegation with may_act is experimental. Do not base a production actor chain on Keycloak's experimental delegation feature without accepting that compatibility risk.
• SPIFFE and SPIRE attest nodes and workloads and issue X.509 or JWT SVIDs. Use SPIRE to prove which deployed workload is executing the agent. An SVID identifies the workload; it does not carry user consent or delegated user authority by itself.
• OpenFGA is a CNCF open-source relationship-based authorization system. It can model user, agent, tenant, and resource relationships and answer object-level access questions. Keep volatile request facts such as amount, prompt-injection risk, and current workflow state in the runtime decision rather than forcing every fact into the relationship graph.
• Open Policy Agent evaluates policy over structured input using Rego. It can combine token claims, workload identity, tool arguments, resource attributes, and workflow state. The application remains the enforcement point: it must query the policy before the operation and handle allow, deny, and unavailable results explicitly.

Which identity tools should an AI agent combine?

For a managed deployment, use Auth0 for AI Agents or Descope for user consent and connected-account credentials, then add object-level authorization and an in-code guard before consequential tools. For a self-hosted deployment, one division of responsibility is Keycloak for user identity and token exchange, SPIRE for workload identity, OpenFGA for durable resource relationships, and OPA for contextual policy.

Do not add every component by default. A small agent that calls one internal API may need an existing OIDC provider, a short-lived audience-restricted token, and application authorization. Add a token vault when the agent connects to external user accounts, workload identity when deployment provenance affects trust, and a separate policy engine when policy must be shared across several services or languages.

Agentic identity anti-patterns

• Sharing the user's bearer token: the agent receives all token capabilities, and downstream services cannot distinguish actor from subject.
• One credential for every agent: actions cannot be attributed to a logical agent or isolated by capability, environment, or tenant.
• Trusting prompt-provided identity: model output or request metadata chooses the user, role, or delegation chain.
• Treating OAuth scopes as user intent: a broad capability is accepted as approval for every concrete action.
• Forwarding one token to every API: audience boundaries disappear and a compromised service can replay the credential elsewhere.
• Accumulating delegation rights: downstream agents union permissions from prior actors instead of reducing authority at each hop.
• Long-lived refresh tokens in workflows: compromise creates durable access after the task and user session end.
• Audit logs with only the user: the agent, workload, client, and delegation path disappear from incident evidence.

On-behalf-of implementation checklist

1. Identify the controlling subject, logical agent, workload, OAuth client, and target resource separately.
2. Choose delegation over impersonation when the target can represent both subject and actor.
3. Authenticate users and workloads through trusted issuers; never accept identity from prompts or model arguments.
4. Exchange credentials for one target audience with the minimum scopes and lifetime needed for the next operation.
5. Validate subject and actor tokens and explicitly authorize the actor to receive delegated authority.
6. Preserve the current actor in a signed claim or trusted server-side session, and retain prior actors only as audit history.
7. Reduce authority at every delegation hop; limit chain depth and reject loops.
8. Keep credentials outside prompts, model context, tool output, and logs.
9. Enforce tenant, object, action, recipient, amount, and budget policy at the execution boundary.
10. Bind approvals to the exact consequential action and expire them quickly.
11. Record subject, actor, workload, policy decision, and workflow correlation without logging bearer credentials.
12. Test cross-tenant access, actor substitution, audience confusion, scope escalation, replay, expired approval, chain splicing, and prompt-driven misuse.