Designing credentials that expire before trust does

Trust changes faster than most credentials. A user can lose access, a task can be cancelled, a destination can become suspicious, an agent can enter a new phase, and an incident responder can decide to stop work. A credential issued yesterday cannot know any of that unless the system limits its life or checks current policy at use time.

For agents, expiry is not housekeeping. It is a boundary on how long an old decision can keep producing new actions.

Match credential lifetime to the assumption window

Every grant rests on assumptions: the user is still authorised, this workload instance is intact, the task remains active, the tool is the intended audience, and the requested action is within scope. Set access-token lifetime shorter than the shortest meaningful assumption—not merely to the identity platform’s default.

A research step lasting two minutes may need a token for one search service and one dataset. A long-running migration may need hours, but it should renew through checkpoints rather than hold one credential throughout. Renewal is the opportunity to re-evaluate user status, task state, risk signals and remaining scope.

Short life is not a complete control. If the agent can silently mint an identical token forever from a long-lived secret, the effective authority is long-lived. Protect and constrain the renewal path at least as carefully as the access token.

Keep the root of trust away from the model

Use workload identity or a credential broker to authenticate the executing service. The orchestrator requests authority for a structured action; the broker checks the task and delegation; and it returns a narrow credential directly to the tool adapter. The model sees neither a client secret nor an access token.

For delegated flows, OAuth token exchange defines a way to exchange one security token for another in a different context. Whether or not that protocol fits the platform, the security pattern is useful: do not pass the original user’s broad credential down the chain. Derive a restricted token whose subject, actor, resource and scope match the next hop.

Keep credentials out of prompts, memory, tool results, exception messages and observability payloads. Redact before logs leave the adapter. Scan evaluation traces and support exports for token-shaped material, because an otherwise well-designed credential can leak through diagnostics.

Treat local development and support tooling as part of the same boundary. Debug shells, replay consoles and copied production traces often have looser access than the running agent. Use synthetic tokens in test fixtures, restrict who can request production replays, and ensure support staff can inspect authorisation decisions without revealing the credential itself. The lifecycle is only as strong as the least governed place a token can appear.

Bind the credential to its destination and holder

An access token should name or otherwise be restricted to its intended resource. A token for the ticket server should fail at the document server. Audience validation also prevents an intermediary from forwarding a token to a downstream service and inheriting authority it was not meant to have.

Bearer tokens can be used by whoever possesses them. OAuth 2.0 security best current practice recommends sender-constrained access tokens to reduce replay of leaked tokens. Mutual TLS binds a token to a certificate; DPoP binds it to an application-held key and request proof. These mechanisms add operational complexity and do not protect a fully compromised holder, but they materially change the value of a token copied from a log or intercepted at another layer.

Bind further where the platform supports it: tenant, task identifier, action family, data classification and maximum transaction value. Enforce these claims at the resource server. A richly constrained token that the target never validates is only documentation.

Design renewal as a policy event

Avoid automatic renewal based only on “token nearly expired.” Require the active task, current delegator authority, healthy workload identity and unchanged policy. Reduce scope as the workflow advances. A discovery token should not automatically become an execution token; moving from read to write is a new decision.

Long-running agents need checkpoint expiry as well as clock expiry. End authority when the phase completes, the plan materially changes, a tool returns an unexpected redirect, or human review is requested.

Make revocation propagate to queued work

Revoking a token at the issuer is insufficient if workers have cached credentials, queued tool calls or already-created sessions. Document the propagation path: issuer, gateway, tool adapter, downstream API, queue and retry service. Define a maximum time to effective stop.

Revocation should cover the delegated chain. If a user’s access ends, derived mandates and child-agent capabilities should become unusable. If one workload instance is compromised, revoke its key without stopping every agent. This requires distinct workload identities and searchable issuance records.

Plan for partial revocation. A downstream API may validate self-contained tokens until expiry and never consult the issuer. In that design, short lifetime is the maximum containment time unless the resource server maintains a deny list or policy gateway. Record that bound explicitly. For high-impact actions, a final online policy check can shorten it without forcing every low-risk read through a fragile central dependency.

The emerging focus is not theoretical. The NCCoE’s agent identity and authorisation concept work explicitly asks how existing identity standards can support agent identification, authorisation, auditing and non-repudiation.

Test the credential lifecycle under failure

Build tests around events, not static configuration:

• copy an access token and try it at another resource;
• replay it from a different sender when sender-constraining is enabled;
• let it expire between planning and execution;
• remove the user’s role before renewal;
• cancel the task with queued writes outstanding;
• rotate the workload key while a run is active;
• deny access to the authorisation service and observe fail-open or fail-closed behaviour;
• revoke a parent delegation and test every child; and
• search logs, traces and model context for credential material.

Measure time to effective revocation and the number of actions that can complete during that window. A “401 received” assertion is weaker than showing that the protected state did not change.

Make protocol integrations prove the same properties

Agent protocols do not remove credential design obligations. The MCP authorisation specification requires protected servers to validate that tokens were issued for them, prohibits token passthrough to downstream services, recommends short-lived access tokens and requires secure handling. Review the version actually implemented; protocol security requirements evolve, and client or server libraries may lag.

For any integration, ask for evidence of audience validation, scope enforcement, storage, renewal, rotation, revocation and logging redaction. Test malicious metadata and redirects rather than assuming discovery is safe. The protocol supplies a contract; the deployment must still enforce it.

A credential design is ready when old trust fails closed: a cancelled task cannot keep acting, an expired phase cannot renew unchanged, a copied token cannot travel, and responders can identify and revoke one compromised chain quickly. Expiry is valuable because it forces authority to meet current reality again.