How should an agent use delegated, short-lived identity?

Scope

Use this pattern when an agent calls internal or external services on behalf of a person or workload. It applies to delegated reads and changes. It does not assume OAuth is the only identity system; the core requirement is explicit, short-lived, target-bound authority enforced outside the model.

Why it happens

Prototype agents receive an API key in an environment variable and use it for every user and tool. The key collapses the service owner, current user, agent process, task, and target into one ambient authority. If a prompt injection changes the plan, the same credential remains usable.

Passing the user’s full token is not much better. The model or tool runtime may see a credential with unrelated scopes, long lifetime, and several audiences. Audit logs show the user but lose the fact that an agent proposed and executed the action.

Diagnosis

Trace one sensitive tool call and identify:

1. the human or service principal requesting the task;
2. the agent workload instance executing it;
3. the durable task and proposed action;
4. the delegation rule and current policy decision;
5. the protected resource, tenant, and audience;
6. the credential issuer, lifetime, scope, and revocation path;
7. the target-side decision and resulting effect.

If the answer is one API key or a token copied into the prompt, the system cannot enforce or explain least privilege reliably.

Solution

Give the agent runtime a workload identity used to authenticate to a trusted broker. The broker evaluates the requesting actor, task, policy, approval, resource, operation, and risk. It issues or exchanges for a narrow credential whose audience and expiry match the target and expected execution time.

Keep credentials out of model-visible context. The tool adapter attaches them after the model has produced a typed proposal. The gateway and target service validate issuer, audience, expiry, sender binding if available, scope, tenant, and current policy. Recheck action-specific authorization at commit.

Record delegation without putting raw tokens in telemetry. Use actor, subject, workload, task, policy-decision, token ID hash or safe reference, target, and effect identifiers.

Artifact

Complete this identity-chain worksheet for each tool class:

Link	Required record
Requesting actor	Canonical identity, tenant, role, authentication strength
Agent workload	Service identity, instance, software version, environment
Task	Durable ID, purpose, owner, risk tier, deadline
Proposal	Operation, parameters digest, target, expected effect
Delegation	Actor/subject relationship, permitted operation, conditions
Approval	Approver authority, proposal digest, policy, expiry
Credential	Issuer, audience, scope, lifetime, sender binding, revocation
Target decision	Resource identity/version, current policy, allow/deny reason
Effect	Idempotency key, actual outcome, receipt, verification, audit link

Common mistakes

• Reusing a platform-wide API key for every user and task.
• Exposing bearer tokens to the model, transcript, memory, or general logs.
• Minting a fresh token without rechecking the exact pending action.
• Validating scope at the gateway while the target trusts network location.
• Logging “acted as user” without preserving workload, task, delegation, and approval.