Why should AI agents use short-lived credentials, and how?

AI agents should use their own identity and short-lived, narrowly scoped credentials because a static key outlives the task, the session and sometimes the employee who created it. Tokens that expire in minutes limit what a leak, a prompt injection or a runaway loop can reach.

What goes wrong with a long-lived key?

Picture a coding agent configured with a developer's personal access token so it can open pull requests. The token never expires, covers every repository the developer can reach, and appears in the agent's environment where tools and logs can read it. If a malicious web page steers the agent into printing its environment, that key is gone.

OWASP lists excessive agency as a top risk for LLM applications: too much functionality, too many permissions, or too much autonomy. A shared long-lived credential is the permissions half of that problem, made permanent.

What does a better identity look like?

Three pieces work together.

A distinct identity per agent. Not the human's login, not a shared service account. Logs then say which agent did what.

Short-lived tokens issued on demand. The agent asks an issuer for a token valid for the single task or a few minutes. OAuth 2.0 Token Exchange (RFC 8693) defines how a service can swap one token for another, including for delegation, so an agent can act on behalf of a user with a token narrower than the user's own. Cloud providers offer comparable security token services.

Workload identity instead of stored secrets. SPIFFE, a CNCF project, specifies short-lived verifiable identity documents for workloads (as X.509 or JWT SVIDs) so a process proves who it is without a baked-in password.

Should the token be bound to the agent?

A bearer token works for anyone who holds it. RFC 9449 (DPoP) describes sender-constraining tokens with proof of possession, so a stolen token cannot simply be replayed by another party. RFC 8705 does a similar job using mutual TLS certificates. Either way, a leaked token is less useful.

What about agents that call other agents?

Chains make identity harder. If a planner agent hands work to a tool agent, which calls an API, whose identity does the API see? Passing the human's token down the chain gives every link the human's full reach. A better pattern is delegation with narrowing: each hop exchanges its token for one limited to the next step, and the audit trail records the chain of who acted for whom. RFC 8693 describes the token exchange mechanics, including delegation semantics.

Also plan for the offline case. A scheduled agent that runs at night cannot ask a person to approve. Give it a dedicated identity with a narrow, pre-approved scope and alerts on any use outside its schedule.

How to check or apply this

1. Inventory agents and list every credential each one holds. Include environment variables and config files.
2. Replace human tokens and shared keys with a per-agent identity.
3. Set token lifetimes to the length of the task, measured in minutes, and test that expiry actually stops access.
4. Scope each token to the specific resources and actions the agent needs.
5. Require a fresh approval for high-impact actions such as deletes or production deploys.
6. Log token issuance and use per agent, and alert on use outside the expected window.
7. Rotate or revoke on any sign of leakage, and test the revoke path before you need it.

Safeguard's MCP Guardrail and agent identity features are built for this class of problem: guarding what an agent can call and tying actions to an identity. They reduce exposure but do not replace sound issuer design.

Quick check

Sources

• RFC 8693, OAuth 2.0 Token Exchange
• RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• SPIFFE Overview
• OWASP LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.