The Credential Graveyard Problem
Agentic systems accumulate credentials the same way software accumulates technical debt: gradually, invisibly, until the weight becomes dangerous. A chatbot is deployed with a scoped API key and calendar access. The product team adds email integration. Six months later, the product pivots. The chatbot is deprecated but never fully decommissioned — and it still holds live OAuth tokens for the organization's CRM, email server, and cloud storage.
Research from 2026 found that 65% of agentic chatbots across enterprise deployments held live credentials for systems they had not accessed in over 90 days. In many cases, the teams responsible for decommissioning those agents were not the teams who provisioned the credentials. The credentials outlived the agents. The authorization outlived the intent.
This is the foundational token lifetime problem: credentials issued to AI agents tend to be long-lived by default, rarely revoked proactively, and almost never tied to the specific task that justified their issuance. When a token is eventually leaked — through a prompt injection, a compromised dependency, or a misconfigured log — the attacker inherits not what the agent needed right now, but everything it was ever given access to.
Why Agents Are Worse Than Services
Traditional service-to-service authentication has well-understood patterns. A microservice gets a scoped API key, and that key covers a narrow, static set of operations. The attack surface is bounded because the service's behavior is bounded: it does the same things, in the same ways, every time.
AI agents break this model completely. An agent's behavior is dynamic — it decides at runtime which tools to invoke, which data sources to query, which actions to chain together. This means the credential surface needs to flex with the task. But most implementations do the opposite: they give the agent maximum credentials at deployment time so it can do anything the user might eventually ask for. The agent gets the keys to every door on day one, regardless of which rooms it will actually visit.
The result is a mismatch between the principle of least privilege — which requires scoping access to the minimum needed for a specific task — and the operational reality of agentic deployment, where scope is determined before the task is known. Long-lived, broad tokens are the lazy resolution of that mismatch.
In the Salesloft incident affecting over 700 organizations, the initial vector was a single OAuth token held by a deprecated AI sales agent. The token had not been used in four months but remained valid. Once extracted via a prompt injection in a connected CRM plugin, the token granted access to email, contact data, and calendar APIs across every customer organization that had authorized the integration — because the token was organization-scoped, not task-scoped. One stale credential, seven hundred breach notifications.
The Two-Tier Session Architecture
The correct model separates credential lifetime into two distinct tiers, each sized to its actual risk profile. User sessions are long-lived because they represent a persistent relationship between a user and a system — logging in and out repeatedly is friction, not security. Agent sessions are short-lived because they represent a single, bounded task — the credential should not survive the task that justified it.
User Session Layer
- Lifetime: hours to days
- Backed by refresh tokens
- Human-authenticated
- Revocable at logout
- Scope: user's full authorized access
Agent Task Layer
- Lifetime: minutes (task duration)
- Non-refreshable by design
- Derived from user session at task start
- Auto-expires on task completion
- Scope: minimum for this specific task
The agent session is derived from the user session at task start via a token exchange (RFC 8693 or equivalent), with scope explicitly narrowed to what the task requires. A summarization task gets read-only document access. An email scheduling task gets calendar read and email send — nothing else. When the task ends, the agent token expires. The user session persists for the next task.
The non-refreshable property is critical. An agent that can refresh its own token can effectively extend its own authorization window without human re-consent. This is the mechanism by which a task-scoped credential becomes a long-lived credential — not through explicit mis-configuration, but through a refresh loop that nobody audits.
Per-Task Issuance in Practice
The unit of issuance determines the unit of attribution. Per-task tokens let you answer "what was the agent doing when this access occurred" with precision. Agent-global tokens can only tell you the agent existed — not what task, what user intent, or what chain of reasoning justified the specific access.
# Per-task token issuance pattern (RFC 8693 token exchange) # At task start — derive narrowly-scoped agent token POST /oauth/token { "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange", "subject_token": "<user_session_token>", "subject_token_type": "urn:ietf:params:oauth:token-type:access_token", "requested_token_type": "urn:ietf:params:oauth:token-type:access_token", "scope": "calendar:read email:send", # task-specific scope "actor_token": "<agent_identity_token>", "expires_in": 900 # 15 min — task duration } # Token carries full provenance { "sub": "user:alice@org.com", "act": { "sub": "agent:scheduling-v2" }, "scope": "calendar:read email:send", "task_id": "task_8f3a2b", "exp": 1747651800, "refresh_token": null # non-refreshable by design }
The EU AI Act Deadline
Token lifetime is about to become a compliance question, not just an engineering one. Article 14 of the EU AI Act, entering enforcement on August 2, 2026, requires organizations to demonstrate that every AI-driven action was authorized at the time it occurred. A token issued three months ago for a deprecated agent does not satisfy that requirement. Authorization must be contemporaneous with action.
The penalty for non-compliance is up to €35 million or 7% of global annual revenue — whichever is higher. The organizations most exposed are those running agentic systems that were built before token lifecycle management was treated as a first-class concern. The Salesloft pattern — stale credentials, orphaned agents, no revocation audit trail — is precisely what Article 14 was written to prevent.
Audit all currently-live agent credentials and their last-used timestamps. Revoke any token inactive for more than 30 days. Implement per-task token issuance for all new agent deployments. Set agent tokens to non-refreshable with a maximum lifetime of 15–30 minutes. Tie every token issuance to a task_id that appears in both application logs and audit logs. Run a quarterly credential inventory against all registered agents — including deprecated ones. Begin building the authorization audit trail that Article 14 will require before August 2026.
Short-Lived Is Necessary But Not Sufficient
Short-lived credentials reduce blast radius when a token is extracted — but they do not prevent extraction. A 15-minute token is still 15 minutes of access to calendar, email, or file systems if leaked via prompt injection. The correct posture treats token lifetime as one layer in a defense-in-depth stack, not a complete solution.
The complementary controls are: least-privilege scope (limit what the token can do), DPoP binding (tie the token to the client that requested it so it can't be replayed by a different party), continuous credential monitoring (detect when tokens appear in unexpected places — logs, responses, error messages), and human-in-the-loop for irreversible actions (require explicit approval before the agent takes actions that cannot be undone regardless of token validity).
The goal is not to make token theft impossible — it is to make a stolen token useless as quickly as possible and as narrowly scoped as possible while valid. Short lifetime + narrow scope + client binding + continuous monitoring is a meaningful defense-in-depth. Any one of those alone is just a checkbox.