A capability token is a credential that grants its bearer a specific, limited set of permissions — typically with a constrained scope, a bound audience, and a short expiry — so that the token itself encodes exactly what is allowed. Where identity-based access asks "who are you?" and then looks up what that identity may do, a capability token is the authorization: presenting it demonstrates the right to perform the actions it names, and nothing more.
The idea descends from capability-based security in operating systems, and it has found its natural modern habitat in AI agent and tool infrastructure, where the principals are numerous, autonomous, and — crucially — manipulable. When an agent can be steered by adversarial content, the safest credential to hand it is one that cannot do much: scoped to the task, bound to the target, dead in minutes.
Anatomy of a capability token
A well-formed capability token carries its constraints inside itself, verifiable by any recipient without a callback:
- Scope — the operations and resource types permitted ("read calendar events," not "calendar access"). See scope.
- Audience — the specific system the token is valid for, so it is rejected everywhere else. This is the property the MCP authorization spec enforces via RFC 8707 resource indicators, covered in MCP OAuth 2.1 and PKCE explained.
- Expiry — a lifetime measured in minutes, making theft a rapidly depreciating asset.
- Subject and provenance — which principal the token was minted for, and by whom, keeping every use attributable.
- A signature — so recipients verify integrity and issuer locally.
Why capability tokens suit AI agents
Three agent-specific problems map directly onto capability-token properties:
- Manipulable principals. A goal-hijacked agent can only misuse what its credentials allow. Task-scoped tokens shrink that surface to near the task's own size — the blast radius argument applied to credentials.
- Delegation. When an orchestrator hands a subtask to a sub-agent, the safe currency is a capability token bounded by the delegator's own authority and the subtask's needs, expiring with the task. Delegated authority narrows at each hop and revocation is surgical — the pattern detailed in securing inter-agent communication.
- Machine-speed authorization. Because the token carries its constraints, enforcement points can validate locally and fast, which is what makes continuous authorization practical at agent volumes.
Capability tokens vs adjacent credentials
Against an API key: a key is identity-shaped (it names a caller; permissions live server-side and are usually broad and long-lived); a capability token is authorization-shaped (permissions live in the token, narrow and brief). Against an OAuth access token: a scoped, audience-bound, short-lived OAuth token is a capability token in practice — the terms converge as OAuth deployments adopt resource indicators and minimal scopes. Against a session: sessions accumulate ambient authority over their lifetime; capability tokens are the anti-session, minted per task and discarded.
The trade-off is issuance infrastructure: something must mint, sign, and (rarely) revoke tokens at task granularity, which is why capability-token architectures usually arrive as part of a broader identity and access layer for AI rather than as a standalone pattern.
Common questions
What is a capability token in one sentence? A short-lived, signed credential that encodes exactly which operations its bearer may perform against which target, so presenting the token is the authorization — nothing broader.
How is a capability token different from an API key? An API key identifies a caller and typically unlocks whatever the server has associated with it — broad, long-lived, all-or-nothing. A capability token carries its own narrow permissions, target audience, and expiry, so a stolen token is worth only what it names, only where it is aimed, and only for minutes.
Who issues capability tokens? An authorization service or control plane: the long-term credential (client secret, registered agent identity) authenticates to the issuer, which mints task-scoped tokens on demand. The long-term credential stays in a secrets manager; only the depreciating token travels.
Can a capability token be revoked before expiry? Yes, via deny-lists checked at enforcement points — but the design goal is to make revocation rarely necessary: lifetimes short enough that expiry is the revocation. For high-sensitivity actions, pair short tokens with per-action checks so policy changes take effect immediately.