AI Agent Credentials: Delegate Authority, Not Tokens

An AI agent can be perfectly constrained by its prompt and still hold a credential that can read every customer, call every tool or move money long after the task ends. The model may request one permitted action; the reusable token turns a mistake, injection or leaked trace into much wider authority.

The design decision is not simply where to store an API key. It is how to prove which workload is acting, for whom, on which resource, under what approval, and for how long—without giving the agent a credential that answers broader questions. The practical pattern is to authenticate the workload, evaluate current policy at a token broker, and mint a short-lived credential for one audience and a narrow set of actions. The destination must then enforce that contract independently of the model.

Separate the identities before issuing authority

An agent transaction can involve several identities that are easy to collapse into one service account:

This separation follows the direction of NIST SP 800-207A, which moves cloud-native access control from network location towards application and service identities as well as user identity. It is especially important for agents because the user, model process, orchestration service and tool endpoint are not the same security principal.

Microsoft's documented flow for interactive agent authentication makes one version of that distinction explicit: authenticate the user, validate their claims, then acquire a downstream token through an on-behalf-of flow. A background reconciliation agent has no signed-in user and needs its own workload authority instead. An agent must not silently switch between those meanings because one token was convenient.

Choose the authority pattern before the OAuth flow

Start with the business relationship, not the identity product already installed.

Delegation and impersonation are not synonyms. OAuth 2.0 Token Exchange, RFC 8693 defines exchanges that can represent either and provides an actor claim for delegated chains. In a delegated call, the resource should be able to distinguish the subject whose authority is involved from the service doing the work. A token that makes the workload appear to be the user may simplify an audit log while destroying the very distinction investigators need.

The model should never decide which pattern applies. Ordinary application code should select it from the session type, job registration, tenant policy and requested action. The broader lesson from the recent MCP permission-boundary review still holds: tool capability is not permission to use it in this request.

Exchange a credential instead of relaying it

Suppose a user presents token A to the agent API. Token A proves access to that API; it is not a travel pass for every downstream service. Relaying it to a payments, email or storage API exposes the credential to another system and may let the agent use authority intended for the wrong audience.

RFC 8693 allows a service to present an existing subject token and, where appropriate, an actor token to a security token service in return for a new credential suited to the downstream resource. The exchange is a policy checkpoint, not a mechanical JWT rewrite. The broker should authenticate the calling workload, verify that delegation is permitted, evaluate present policy and reduce authority rather than copying every original claim.

RFC 8707 resource indicators let a client name the protected resource for which it requests access. Its security guidance explains why an audience-restricted token accepted at one resource should not be reusable at another and why tenant-specific resource identifiers may be necessary in multi-tenant systems. Scope answers what may be done; audience answers where the credential may be presented. Both are required.

A useful issued-token contract records or cryptographically binds:

• one trusted issuer and one intended audience;
• the workload actor and, for delegation, the human or service subject;
• tenant and resource boundaries precise enough for the destination;
• narrow actions rather than a broad administrative role;
• issued, not-before and expiry times measured in minutes where practical;
• the approval, policy version and stable operation identity by reference; and
• a presenter-binding method when the client and destination support one.

Do not put prompts, invoice text or other sensitive evidence inside a widely logged token. Keep the credential compact and point to a protected decision record. Logs should retain token identifiers and decision facts, never the bearer value.

Bind the token to the workload that requested it

Short life reduces the window after theft; it does not stop a stolen bearer token being used during that window. DPoP, RFC 9449 is an application-layer method for binding OAuth tokens to a public key. The client signs a proof for an HTTP request, and the resource checks that the proof key matches the key bound to the token. DPoP does not authenticate the model, approve the action or make the request correct. It only adds evidence that the presenter holds the corresponding private key.

The broker therefore needs a trustworthy workload identity before minting downstream authority. SPIFFE specifies short-lived cryptographic workload identities that can be obtained through a workload API and used with X.509 or JWT-based authentication. Kubernetes provides a platform-specific example: its TokenRequest service-account tokens can carry an audience and expiry and can be bound to the lifetime of an object such as a Pod. Both approaches replace a secret copied into configuration with an identity issued to a running workload.

Cloud federation applies the same idea across boundaries. Google documents exchanging ambient OIDC, SAML or AWS credentials for short-lived access through Workload Identity Federation. AWS IAM Roles Anywhere similarly uses trusted X.509 certificates to issue temporary credentials for external workloads, with session policy able to reduce the resulting permissions. These products are examples, not proof that a default configuration is narrow: issuer mappings, trust conditions, audience, role and session policy still define the real boundary.

Make the resource server enforce the contract

A beautifully minted token is useless if the destination checks only its signature. The resource server owns the side effect and must reject the request unless all material claims and current business rules agree.

At minimum, validate issuer, signature, audience, time window, tenant, actor, subject where relevant and the exact action. Verify proof of possession when used. Then apply live authorisation: does this operation still exist, is the approval current, is the amount or object inside its limit, and has policy changed since issuance? Token validity is necessary evidence, not the final business decision.

Keep this check outside the model and shared by every caller. The five action-validation gates explain how structural and semantic validation should precede authorisation, while the agent concurrency guide shows why the same operation identity must also reject duplicates and stale workers. Identity, authorisation and idempotency solve different failures.

Revocation needs an honest design. Very short expiry can make a deny-list unnecessary for low-risk reads, but a five-minute payment credential may still be too powerful after approval is withdrawn. For higher-impact actions, let the destination check an approval or policy version at commit time. Do not hide a long-lived refresh token in agent memory to make expiry invisible; reacquire authority through the broker and re-evaluate the conditions.

Worked example: create a payment draft, never release it

Consider a hypothetical invoice assistant. A finance user reviews invoice 1842 and approves creation of a payment draft up to £4,800. The user is not authorising release, beneficiary changes or access to other entities.

• The agent API validates a user token intended for itself and records the draft-only approval.
• The running agent authenticates to the broker with its workload identity and a fresh key proof.
• The broker verifies the user, actor, tenant, invoice revision, amount limit and policy version.
• It issues a five-minute token for the payment-draft API, scoped to create one draft for the approved operation and bound to the workload key.
• The payment API validates the token, proof, tenant, current invoice revision, approval and operation identity before committing.
• A retry carries the same operation identity and receives the original draft reference rather than creating another.
• Releasing the payment requires a different endpoint, permission and approval; the draft token cannot be exchanged upward into it.

If the token expires while the agent is preparing the request, the agent asks the broker again using the same operation identity. The broker may issue a replacement only after confirming that the approval and source state remain current. Expiry becomes a deliberate re-authorisation point rather than a reason to cache a more powerful secret.

Test the ways authority can escape

The security tests should challenge boundaries, not merely confirm that a valid token works:

• present the token to a neighbouring API and require an audience rejection;
• replay it from a different key or workload and require presenter rejection;
• change the tenant, resource, amount or action while retaining the token;
• withdraw approval or advance the policy version before commit;
• delete the bound workload and verify that new exchange fails;
• attempt to exchange delegated authority into a broader scope;
• forward the original user token to the downstream API;
• retry the same operation concurrently and after token renewal; and
• place token-like strings in prompts, traces and errors and verify redaction.

This evidence belongs beside the privacy-safe trace described in the AI incident replay guide. An investigator should reconstruct issuer, subject, actor, audience, scope, decision, operation and commit without recovering a credential that can still be used.

Measure authority reduction, not token volume

The final review is concrete. Can the agent prove its own workload identity? Can the system preserve who it acts for without impersonating them? Does the issued credential name one destination, tenant and bounded action? Can the destination reject stale approval, a stolen presenter and a duplicate operation? If those answers are not independently enforceable, the agent does not have delegated authority; it has a borrowed master key.