Blog · · 11 min read

AI Agent Identity Management Without Shared Session Tokens

AI Agent Identity Management Without Shared Session Tokens

AI agent identity management breaks down when a background run receives a browser session token or a tenant-wide service credential. A session token gives the runtime reusable access without identifying the agent behind the action. A shared service credential hides the user's boundary instead. Both designs make it harder to limit scope, expire access, revoke one run, or explain who did what. Keep the user, agent run, and downstream API separate. Give the run a short-lived credential for one approved audience and action set, persist only a protected reference to it, and check authority again before refresh or execution.

Why authorization decisions and execution credentials are different

A policy decision asks whether a user may request a refund proposal for an account. An execution credential proves which run may call the billing API, which operations it may request, and when that access ends. Treating one as the other produces predictable failures.

Forwarding the user's token

Some products pass the incoming web token straight to an agent or MCP server. The runtime then carries a credential issued for another client or resource. The official MCP security guidance calls token passthrough an anti-pattern. It also explains that weak audience validation can let one service accept a token intended for another.

That credential usually identifies the user and client, not the particular agent release or run that chose the action. The author of MCP issue #333 reports a confused-deputy problem in which the agent inherits the client's broad scopes even though its task needs less. The issue is practitioner evidence rather than a protocol guarantee, but the boundary failure is concrete.

Using one service credential for every user

A tenant-wide service credential removes the browser token from the runtime, but it also removes the delegating user from the credential. Every run looks like the same workload. Application code must simulate per-user revocation because the credential itself cannot enforce it.

Shared runtimes expose this limitation. In OpenAI Agents SDK issue #1566, a SaaS implementer reports that startup-bound MCP credentials cannot vary by user and asks for runtime-selectable OAuth credentials. That report does not define SDK behavior, but it shows why one credential cannot safely represent many users.

Saving live tokens in checkpoints

Agent runs pause for approvals, retries, callbacks, and scheduled resumes. A checkpoint that contains an access or refresh token expands the credential boundary to every replica, backup, trace exporter, and support path that can read that state. Old checkpoints may also restore secrets that should have been rotated.

Durable state should contain delegation metadata and a credential reference. A broker or protected vault should hold the secret material. When a run resumes, the broker resolves the reference only after it confirms that the run, user, policy, and requested action still qualify.

Model the user, agent run, and resource separately

The delegation model needs three named principals:

  1. The subject is the user or service account whose authority constrains the action.
  2. The actor is the product agent, immutable release, or specific run doing the work.
  3. The resource is the API that accepts the credential for a declared audience.

MIT's work on authenticated delegation and authorized AI agents describes a verifiable path from a human principal through a trusted agent, with user control and an auditable delegation chain. It is research, not a product protocol. For an application team, the immediate point is that an authenticated call to the product does not identify the agent that later takes action.

Microsoft Entra Agent ID implements a related separation. Its authorization documentation gives agents distinct managed identities and distinguishes delegated permissions, used for a signed-in user, from application permissions, used for autonomous work. Other identity systems may use different terms, but the product still has to preserve the distinction.

A permanent identity for every model turn is unnecessary. Give the agent a stable lifecycle identity, then bind the run ID and immutable release ID to the delegation record and action log. Depending on the trust model, the resource can receive those values as token claims, proof metadata, or signed request context.

Define a delegated credential contract

Write the contract before selecting an OAuth extension or vendor. An implementation might store this record:

{
  "delegation_id": "dlg_842",
  "tenant_id": "tenant_17",
  "subject_id": "user_92",
  "actor_id": "refund-agent",
  "agent_release": "refund-agent-2026-07-30.2",
  "run_id": "run_4401",
  "audience": "billing-api",
  "scopes": ["invoice.read", "refund.propose"],
  "resource_ids": ["account_381", "invoice_993"],
  "authorized_by": "policy-refunds-v18",
  "consent_event": "approval_117",
  "issued_at": "2026-07-30T09:42:18Z",
  "expires_at": "2026-07-30T09:52:18Z",
  "credential_ref": "vault://delegations/dlg_842/current",
  "status": "active"
}

The identifiers are examples. A real record must show who delegated authority, which agent release and run may use it, which resource can accept it, and which actions and records it covers. It also needs the policy and approval that authorized it, an expiry, a protected credential location, and revocation state.

Enforcement fields must be machine-readable. Application code can check refund.propose and the resource constraint invoice_993. It cannot reliably enforce a sentence such as "help the customer fairly."

Implement the AI agent identity management flow

Keep authentication and policy in the product's existing control plane. The runtime consumes a bounded decision; it should not grow a separate authorization system.

1. Authenticate the initiating principal

Resolve tenant, user, session assurance, and resource ownership from trusted product state. Conversation text is never an identity source. For a task started by a webhook or schedule, use the configured automation owner and its application permissions instead of fabricating a user session.

2. Ask policy for the minimum action envelope

Send the policy layer a structured request containing the subject, actor, run, resource, requested action, data sensitivity, and approval state. The reply should specify scopes and resource constraints rather than returning a general allowed flag.

Issue only enough authority for the next step. A support agent that reads an invoice and prepares a refund proposal needs invoice.read and refund.propose, not refund.execute. Approval for execution should create a new delegation event and credential.

3. Mint or exchange a short-lived credential

Use a mechanism supported by both the identity platform and resource server. RFC 8693 defines OAuth 2.0 Token Exchange for obtaining security tokens from an authorization server. Its use cases include delegation and credentials narrowed for a downstream service, and it defines subject and actor semantics. The RFC leaves the deployment trust model and many token security properties to the implementation. Product policy still has to constrain issuers, audiences, scopes, and lifetimes.

An IETF Internet-Draft on user authorization for AI agents explored explicit agent identity, user consent, short-lived authorization codes, and recorded delegation paths. The draft expired on 2025-11-03. It is useful vocabulary, not a standard to implement as normative guidance.

When token exchange is unavailable, the product can issue an internal capability or signed request token. It still needs a narrow audience, action set, resource set, and lifetime, plus a distinct actor, traceable subject, and central revocation. A proprietary token should not be called OAuth unless it implements an applicable specification.

4. Store a reference, not reusable secret material

Put delegation_id, policy version, scope, audience, expiry, and credential_ref in the run checkpoint. Store access and refresh tokens in a broker or vault that has access controls and audit logs. Make the reference unusable outside its tenant and run.

To resolve the reference, a worker should present its workload identity and the expected run ID. A resumed job can then move to another replica without placing a long-lived bearer token on the queue.

5. Validate at the resource boundary

Before executing, the downstream API should validate issuer, signature, audience, expiry, tenant, scope, subject, and actor data. It must also check current resource ownership. A token with invoice.read should not open another tenant's invoice simply because the model supplied that record ID.

The action log should record the subject, actor, delegation ID, run ID, agent release, policy version, approval event, target resource, and result. Operators can then follow a specific action back through its authorization chain instead of seeing only a generic service identity.

6. Refresh by reauthorizing

Refreshing agent access should include a new authority check. Confirm that the user remains active and may still access the resource. Check that the agent release is allowed, the policy has not withdrawn the action, the approval remains valid, the task still needs the same audience and scopes, and the run is neither cancelled nor complete.

Refresh may preserve or reduce scope. It must not expand it. A new resource, elevated action, or different audience needs another policy decision and, where policy requires it, new user approval.

7. Revoke by more than token ID

Support revocation by delegation, user, tenant, run, agent release, resource, and incident. First mark the delegation record revoked. Then invalidate broker material and notify the authorization server when it supports revocation. Workers should check the record before resolving a credential reference, even when a cached access token has time left.

Short expiry reduces exposure but does not remove the need for revocation. A compromised run can still act during a ten-minute token lifetime.

Separate delegated and autonomous work

A nightly reconciliation job may run with application authority. An inbox assistant may act within one user's authority. If both use the same credential mode, the audit record is false for one of them.

Use delegated credentials when user access, consent, or resource ownership should constrain the action. Use application credentials for an administrator-approved automation that owns its authority. Microsoft's Agent ID documentation distinguishes these two permission modes and recommends narrow permissions for specific resources (authorization in Entra Agent ID).

An autonomous task should record its automation owner and configuration revision, not a fake user ID. A user-delegated task should return reauthorization_required when consent expires rather than fall back to application authority.

Work through a refund example

A support user asks the agent to inspect invoice_993 and prepare a refund. The product authenticates the user, verifies access to the account, and starts run_4401 with agent release refund-agent-2026-07-30.2.

Policy grants invoice.read and refund.propose for that invoice. The broker exchanges or mints a five-minute credential tied to the user, agent, run, billing audience, scopes, and invoice. The checkpoint keeps dlg_842, not the bearer token.

The agent reads the invoice and prepares a proposal. When a supervisor approves execution, the first credential still cannot issue money. The product creates another delegation event for refund.execute, constrains it to the approved invoice and amount, and issues a new short-lived credential.

authenticated request
  -> policy(subject, actor, run, resource, requested_action)
  -> create delegation record
  -> mint or exchange scoped credential
  -> store credential reference in checkpoint
  -> resolve reference at tool execution
  -> resource validates subject, actor, audience, scope, resource
  -> record result against delegation and run

If the user loses account access while approval is pending, refresh returns subject_no_longer_authorized. A changed amount fails the stale approval constraint. Cancelling the run revokes both delegations and prevents the broker from resolving them again.

Handle credential failures as product outcomes

Identity failures should not arrive as ordinary tool text for the model to reinterpret. Return typed outcomes to the runtime, UI, and alerting system:

  • reauthorization_required: renew user consent or session assurance;
  • delegation_expired: the approved credential window has ended;
  • scope_insufficient: get another policy decision for the next action;
  • audience_mismatch: reject a credential presented to the wrong resource;
  • subject_revoked: stop because the user or service account lost authority;
  • actor_revoked: stop because the agent release or run was disabled;
  • resource_constraint_failed: reject a target outside the delegation;
  • credential_broker_unavailable: report that protected material cannot be resolved;
  • delegation_chain_invalid: report missing subject, actor, approval, or policy evidence.

Writes should fail closed. A read-only flow may continue with reduced capability only when product policy permits it and the UI discloses the limitation. Retry a transient broker timeout, but do not retry revoked authority or insufficient scope in a loop.

Verify the delegation boundary

Test credential behavior without involving model quality. Deterministic tests should prove that:

  • one resource rejects a token issued for another audience;
  • one run cannot resolve another run's credential reference;
  • checkpoints and traces never contain a user's raw token;
  • resource constraints block cross-tenant and out-of-scope IDs;
  • expired approval cannot produce a fresh execution credential;
  • refresh can reduce scope but cannot expand it without a new decision;
  • cancelling a run immediately blocks credential resolution;
  • disabling an agent release revokes its active delegations;
  • autonomous jobs do not masquerade as delegated users;
  • action logs contain the subject, actor, run, release, policy, approval, and result;
  • broker failure returns a typed outcome without falling back to a weaker credential.

Reproduce the MCP failure modes in integration tests. Present a token issued for the wrong service and expect audience rejection. Start with a broadly scoped client, then prove the agent receives only the task's subset. Send two users through the same agent process and confirm their credential references cannot cross.

Avoid six shortcuts

  1. Never forward a browser session token. Mint or exchange a credential for the agent's audience and approved action.
  2. Do not use one tenant credential for work delegated by individual users. Keep application and delegated authority separate.
  3. Keep raw credentials out of checkpoints. Persist delegation metadata and a protected reference.
  4. Authorization at run start is not enough. Check again before refresh and sensitive execution.
  5. Refresh must not expand scope. Elevation needs a new policy and consent event.
  6. Do not treat an expired draft as a standard. RFC 8693 is Standards Track, while the agent-specific IETF document cited here is an expired proposal.

Start with one delegated action

Find one background action that forwards a user token or relies on a shared service credential. Document its subject, actor, audience, minimum scope, resource constraint, expiry, refresh rule, and revocation paths. Add a broker record, change the checkpoint to hold only its reference, and run the negative tests before moving another tool.

This gives AI agent identity management an enforceable starting point. For that action, the product can show who delegated authority, which agent acted, what the credential allowed, where it worked, and when it stopped working.

References

Be first in line.

Join the waitlist and we'll email you the moment it's ready. No sales call.

Try the demo →
or talk to us