Agent identity and delegation

Overview

When an AI agent books a meeting, files an expense or updates a customer record, it is acting on someone's behalf. The systems it touches need to answer three questions. Who is the person whose authority is being used? Which agent is actually doing the work? And what exactly is that agent allowed to do, for how long? Agent identity and delegation is the discipline of answering those questions with cryptographic credentials rather than trust and hope.

The bad old way is to give the agent a person's password or a long-lived API key with full rights. That fails in every direction. The agent can do anything the person can, the key leaks into logs and prompts, nobody can tell agent actions from human ones, and revoking access means changing the person's password. Agents make this worse because they decide at run time which tools to call and can be steered by prompt injection.

An everyday comparison is a power of attorney with limits. You do not hand your solicitor your bank card and PIN. You sign a document that names them, says what they may do ("sell the car, nothing else"), and expires on a date. Anyone they deal with can see both your name and theirs. Good agent delegation works the same way: the agent has its own identity, carries a credential that names the person it acts for, is limited to specific actions, expires soon and leaves a record. This page builds on OAuth 2.0, OAuth for tool access, OpenID Connect and JSON Web Tokens.

What it is

Agent identity and delegation combines older identity standards with newer agent-specific profiles. The main parts are these.

Two ideas sit underneath. First, identity is separate from authority: knowing which agent this is does not say what it may do. Second, authority should only shrink as it is passed along. A person delegates part of their rights to an agent; the agent delegates part of that to a sub-agent or a tool; nobody in the chain gains rights the person did not have.

Where it came from

The building blocks predate today's agents. OAuth 2.0 (RFC 6749, 2012) introduced delegated access with tokens and scopes so that third-party apps would not need users' passwords. OAuth 2.0 Token Exchange, RFC 8693, was published in January 2020. It defined a standard way for a client to send one token (the subject token) and, optionally, a token proving its own identity (the actor token) to an authorisation server, and get back a new token. It also defined the act claim, which records the acting party, and the may_act claim, which says who is allowed to act for a subject. Workload identity systems such as SPIFFE gave services, rather than people, their own cryptographic identities.

As agents began calling real tools, these pieces were applied to them. The Model Context Protocol made MCP servers OAuth resource servers. Its 2025-11-25 revision made Client ID Metadata Documents the recommended way for clients to register, and the 2026-07-28 revision, released on 28 July 2026, deprecated Dynamic Client Registration in favour of them. In June 2026 MCP's Enterprise-Managed Authorization extension reached stable status. It lets a company's identity provider decide which MCP servers employees can use, using the Identity Assertion JWT Authorization Grant (ID-JAG), an IETF OAuth working group draft by authors from Okta, Ping Identity and an independent contributor.

Agent-specific drafts multiplied in 2025 and 2026. One example is an individual draft from WSO2 authors, "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", which adds a requested_actor parameter to the authorisation request so that the consent screen names the agent, and requires an act claim in the issued token. Another is the OAuth working group's Transaction Tokens draft, which carries user and workload context through a chain of internal service calls. A survey presented at an IETF OAuth interim meeting in mid-2026 counted 32 individual drafts on delegating human authority to agents and noted that the field had not converged. At the time of writing, most agent-specific proposals are drafts, not finished standards.

How it works

Step 1: give the agent its own identity

An agent should not borrow a human's identity. It should be registered as a client, with its own client ID and credentials, or be issued a workload identity by the platform it runs on. Strong options use asymmetric keys or attested workload credentials instead of shared secrets. Each running instance can have its own identity so that one compromised instance can be cut off without stopping all of them.

Step 2: obtain the person's delegation

The person authenticates and consents, usually through the OAuth authorisation code flow with PKCE. The consent screen should name the agent and the scopes it asks for. In company settings the identity provider may decide by policy instead of asking each user, as in MCP's Enterprise-Managed Authorization. For actions that need approval later, when the person is not at the screen, a back-channel approval flow such as OpenID Connect CIBA can push a request to the person's phone.

Step 3: exchange for narrow, short-lived tokens

The agent should not carry one broad token to every service. Instead it exchanges a token for each downstream call. A token exchange request looks like this (line breaks added):

POST /token
grant_type         = urn:ietf:params:oauth:grant-type:token-exchange
subject_token      = <token representing the user>
subject_token_type = urn:ietf:params:oauth:token-type:access_token
actor_token        = <token proving the agent's identity>
actor_token_type   = urn:ietf:params:oauth:token-type:jwt
audience           = https://calendar.example.com
scope              = calendar.events.write

effective rights:  R_token = R_user ∩ R_agent ∩ R_policy ∩ R_requested

grant_type tells the server this is a token exchange; subject_token is the person's authority; actor_token proves which agent is asking; audience names the one service the new token is for; and scope asks for only the rights needed. In the last line, R_user is what the person may do, R_agent is what this agent is ever allowed, R_policy is what organisational policy permits in this context, R_requested is what the agent asked for, and ∩ means the token carries only rights present in all four. The issued token typically lives minutes, not days.

Step 4: record the delegation chain in the token

With delegation semantics, the new token keeps the person as sub and adds the agent under act. If a sub-agent exchanges again, the act claim nests, giving a readable chain. A decoded token might look like this:

{
  "iss": "https://auth.example.com",
  "sub": "user-4821",
  "aud": "https://calendar.example.com",
  "scope": "calendar.events.write",
  "exp": 1762600000,
  "act": {
    "sub": "agent:scheduling-assistant",
    "act": { "sub": "agent:travel-planner" }
  }
}

The calendar service can see that user 4821's authority is being used, that the scheduling assistant is the current actor and that it was invoked by the travel planner. RFC 8693 also allows impersonation, where the new token simply looks like the user's own. For agents, delegation is usually the safer choice because the actor stays visible.

Step 5: keep secrets out of the agent

Even narrow tokens should not sit in the model's context, where they can leak into logs, outputs or injected instructions. A credential broker solves this. The agent asks to call a tool; the request goes through a proxy or tool server outside the model; the broker fetches or exchanges the right token, attaches it, makes the call and returns only the result. The model sees "calendar event created", never the token. Secret stores such as HashiCorp Vault can issue dynamic, short-lived credentials for databases and cloud APIs in the same way.

Step 6: enforce at the resource and audit everything

Each service validates the token's issuer, signature, audience and expiry, and checks scopes for every request. MCP's authorisation rules, for example, require clients to send a resource indicator (RFC 8707) naming the server, require servers to accept only tokens issued for themselves, and forbid passing a client's token through to upstream APIs, which prevents a server being used as a confused deputy. Proof-of-possession methods such as DPoP (RFC 9449) or mutual TLS bind a token to a key so that a stolen token alone is useless. Finally, every action is logged with subject, actor chain, scope, resource and outcome.

Key concepts and terms

A worked example

This is an illustrative scenario, not a description of any real company.

A firm of 300 staff deploys an internal assistant that can read calendars, draft emails and file expense claims. Before redesign, it used one service account with a long-lived key that could read every mailbox. A test prompt hidden in an incoming email made the assistant forward another employee's messages. That was the trigger for change.

The redesign works like this.

1. Identity: the assistant is registered as a confidential client using a private key. Each deployment region runs its own instance identity.
2. Delegation: staff sign in through the company identity provider. Policy grants the assistant calendar.read, mail.draft and expenses.submit for the signed-in user only. mail.send is not granted at all.
3. Exchange: for each tool call, the tool gateway exchanges the user's session token for a token whose audience is one service, with one or two scopes, valid for five minutes.
4. Brokering: tokens live only in the gateway. The model sees tool results, never credentials.
5. Approval: submitting an expense over 500 pounds triggers a push approval to the employee's phone; the gateway waits for approval before calling the expenses API.
6. Audit: every call is logged with the employee as subject, the assistant instance as actor, the scope and the result.

When the same hidden-instruction test is repeated, the model again tries to forward someone else's mail. It fails twice over: the token's subject is the signed-in employee, so other mailboxes are out of reach, and mail.send was never granted. The log shows the attempt, which the security team uses to tune the prompt injection defences. If a five-minute token leaked, it would expire before most attackers could use it, and with proof of possession it would not work without the gateway's key.

Strengths and limitations

Strengths:

• Limits damage from mistakes and manipulation: the agent can only do what the token allows.
• Distinguishes agent actions from human actions in logs, which supports investigation and compliance.
• Allows instant revocation of one agent, one instance or one user's delegation.
• Keeps secrets out of model context, prompts and transcripts.
• Builds on mature, widely implemented standards such as OAuth, OpenID Connect and JWT.
• Fits zero-trust architectures, where every request is verified.

Limitations:

• Agent-specific standards are still drafts; vendors implement different revisions.
• Fine-grained scopes require services to define them, and many APIs offer only coarse ones.
• Token exchange adds latency and infrastructure at every hop.
• Consent screens can overwhelm users if agents request many scopes.
• Delegation chains across organisations need trust agreements that technology alone cannot provide.
• Tokens limit what can be done, not whether a permitted action is wise; that still needs policy and review.

How it compares with alternatives

Many real systems sit between the last row and the first: they start with plain OAuth per tool, then add a broker, token exchange and actor claims as the number of tools and the sensitivity of data grow.

Practical guidance and best practices

1. Give every agent, and ideally every agent instance, its own identity. Never reuse a human's credentials.
2. Grant the smallest scopes that do the job, and leave high-risk actions such as sending, paying or deleting out unless truly needed.
3. Exchange tokens per audience so a token for one service cannot be replayed at another.
4. Keep tokens short-lived, in minutes, and use refresh or re-exchange rather than long expiry.
5. Keep credentials outside the model behind a broker or tool gateway.
6. Prefer delegation, with an act claim, over impersonation, so the actor is always visible.
7. Bind tokens to keys with DPoP or mutual TLS where the services support it.
8. Require step-up approval for irreversible or high-value actions, and record who approved.
9. Log subject, actor chain, scope, resource and outcome for every call, and review anomalies.
10. Track the draft standards you depend on and note which revision your vendors implement.

Common mistakes

• Putting API keys or tokens in the system prompt or tool descriptions, where the model can repeat them.
• Passing the user's token straight through to upstream services, creating a confused deputy.
• Granting broad scopes "for flexibility" and never reviewing them.
• Using one shared identity for all agents, so logs cannot tell them apart and revocation is all or nothing.
• Treating authentication as enough and skipping per-request authorisation checks at the resource.
• Letting sub-agents receive the parent's full token instead of a narrower exchanged one.

Frequently asked questions

Why does an agent need its own identity if it acts for a user?

Because the systems it touches need to know both whose authority is used and who is acting. With its own identity, an agent can be limited, monitored and revoked separately from the person, and its actions can be distinguished from the person's own.

What is the difference between delegation and impersonation?

In impersonation the new token looks as if the user made the request directly. In delegation the token keeps the user as subject and records the agent as actor. Delegation preserves accountability, so it is usually preferred for agents.

Is RFC 8693 enough on its own?

It provides the exchange mechanism and the act and may_act claims, but leaves many choices open, such as how to validate chains and what policy to apply. Several agent-focused drafts aim to profile it more tightly. Today, teams combine it with their own policies.

How does MCP handle authorisation?

For HTTP transports, MCP servers act as OAuth resource servers. They publish protected resource metadata so clients can find the authorisation server, clients name the target server with a resource indicator, and servers must accept only tokens issued for them and must not pass tokens through. Enterprise deployments can add the Enterprise-Managed Authorization extension.

What is credential brokering?

It is a pattern where a trusted component outside the model holds or obtains credentials and attaches them to outgoing requests. The agent asks for an action; the broker performs it with the right credential. The model never sees the secret.

How short should agent tokens live?

Short enough that a leaked token is of little use, typically minutes for access tokens. The right value depends on how often the agent calls the service and how costly re-exchange is.

Can delegation work across companies?

Yes, using federation and cross-domain token exchange, but it needs agreements on trust, identity providers and claim formats. Drafts such as ID-JAG address part of this for enterprise applications.

Glossary

• Principal: the person or organisation whose authority is used.
• Agent identity: a verifiable identity belonging to an agent.
• Delegation: passing limited authority from one party to another.
• Token exchange: trading a token for a new one with different properties.
• Actor claim: a token field recording who is acting.
• Audience: the service a token is valid for.
• Scope: a named permission.
• Down-scoping: reducing rights at each delegation step.
• Credential broker: a component that injects secrets outside the model.
• Step-up approval: extra confirmation for sensitive actions.
• Audit trail: a record linking each action to subject and actor.

Summary

Agent identity and delegation lets AI agents act for people without holding their passwords or broad, permanent keys. Each agent gets its own identity; the person delegates specific rights; the agent exchanges tokens for narrow, short-lived credentials per service; the token records both subject and actor; secrets stay in a broker outside the model; and every action is logged. RFC 8693 token exchange, OAuth, OpenID Connect and MCP authorisation provide the foundation, while agent-specific drafts are still settling at the time of writing. Design so that authority only shrinks along the chain, and so that every action can be traced to both a person and an agent.

Related

It belongs to Frontier topics in my stack, under Agentic AI. Others in the same group: