A short-lived credential that grants a narrow, explicit right for a single task or action. Unlike a broad role, it encodes what the agent may do, for how long, and often where. This makes it better suited to unpredictable agent work and easier to revoke when the task ends.
Expanded Definition
Capability tokens are a form of fine-grained authorization for agents and NHIs, designed to express a single allowed action rather than a reusable identity or broad role. In practice, they are closest to object-capability thinking: possession of the token implies the right to perform a narrowly scoped operation under explicit constraints such as time, target, or rate. That makes them especially useful when an AI agent must act autonomously but should not inherit standing access. Definitions vary across vendors on whether a capability token is a bearer token, a delegated grant, or a signed permission envelope, so the important point is the operational boundary it creates, not the marketing label attached to it. Compared with RBAC, capability tokens reduce overauthorization because they describe the task, not the user category; compared with secrets, they are meant to be consumed as authorization artifacts rather than reused as long-lived credentials. The most common misapplication is treating a capability token as a durable service credential, which occurs when teams reuse it across workflows or fail to constrain its scope and expiry.
For broader governance context, NIST’s NIST Cybersecurity Framework 2.0 remains a useful reference point for mapping authorization controls to risk management outcomes.
Examples and Use Cases
Implementing capability tokens rigorously often introduces orchestration overhead, requiring organisations to weigh tighter task-level control against the operational cost of issuing, tracking, and revoking many short-lived grants.
- An agent receives a token that may read one customer record, generate a summary, and expire after five minutes, with no permission to enumerate other records.
- A CI/CD bot is given a token that can sign one release artifact in a specific repository, preventing lateral use in other pipelines.
- A workflow assistant gets a token to call a single MCP tool once, which limits abuse if the agent is prompt-injected or misrouted.
- An incident-response agent uses a token that can quarantine one workload during a defined maintenance window, then self-expires.
These patterns are easier to reason about when paired with NHI incident data such as the Guide to the Secret Sprawl Challenge, which shows how widely distributed credentials amplify exposure. For implementation detail on secret and token handling, the NIST Cybersecurity Framework 2.0 helps connect these grants to access governance and recovery workflows.
Capability tokens are also useful in response to real-world credential abuse patterns documented in NHIMG research, including the Salesloft OAuth token breach, where token misuse enabled access beyond the intended task boundary.
Why It Matters in NHI Security
Capability tokens matter because they shrink the blast radius of an exposed credential. When tokens are short-lived and narrowly scoped, compromise does not automatically translate into broad system access, which is a major advantage in agentic environments where execution paths are hard to predict. This matters even more when tokens move through collaboration tools, logs, and build systems, because NHIMG research shows 44% of NHI tokens are exposed in the wild, often through places teams do not treat as formal secret stores. The security lesson is simple: if a token can be reused, shared, or left active after the task ends, it is no longer acting as a capability grant but as an unmanaged standing credential. That distinction is central to NHI governance, especially for autonomous agents that can chain actions faster than a human reviewer can intervene. Organisations typically encounter the practical need for capability-token controls only after a token leak, a privilege escalation, or an offboarding failure, at which point the issue becomes operationally unavoidable to address.
Related NHIMG context also appears in the Internet Archive breach and the JetBrains GitHub plugin token exposure, both of which reinforce how quickly token sprawl turns into real access risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and token misuse, including overbroad or exposed NHI credentials. |
| OWASP Agentic AI Top 10 | A3 | Agent tool access controls depend on narrowly bounded delegated permissions. |
| NIST Zero Trust (SP 800-207) | SC.L2-3 | Zero trust requires explicit, continuous verification of every authorized request. |
Issue capability tokens with minimal scope, short expiry, and rapid revocation paths.
