A resource-locked token is an access token constrained to a specific resource, action, or task boundary. In agentic identity designs, it helps ensure an AI agent can only reach the API or service the customer approved. This reduces overbroad privilege and makes delegated access easier to audit.
Expanded Definition
A resource-locked token is a delegated credential that is intentionally narrowed to one resource, one action set, or one task boundary. In NHI security, that limitation matters because an AI agent, workflow, or service account should not inherit broad API reach simply because it needs a single approved operation. The closest standards language lives in least-privilege and authorization guidance, including NIST Cybersecurity Framework 2.0, although no single standard yet defines the term itself.
Definitions vary across vendors, especially when products describe scoped tokens, bounded grants, or delegated credentials as if they were equivalent. In practice, a resource-locked token should be distinguishable from a general bearer token by two properties: the issuer encodes the constraint, and the resource server enforces it before the request can execute. For agentic systems, this is what makes an approved tool call materially different from a reusable credential that could drift into adjacent systems. The most common misapplication is treating any token with an expiration date as resource-locked, which occurs when teams confuse time-limited access with resource-bound authorization.
Examples and Use Cases
Implementing resource-locked tokens rigorously often introduces more authorization design overhead, requiring organisations to weigh narrower blast radius against higher policy and token-management complexity.
- An AI agent is given a token that can create a single ticket in Jira, but cannot read other projects or export data from the workspace.
- A workflow token can invoke one payments API endpoint for a specific merchant account, while blocking list, admin, or diagnostic calls.
- A support automation is issued a resource-bound token for one customer’s case file, similar to the access constraints discussed in the Guide to the Secret Sprawl Challenge, where overbroad credential reach worsens exposure.
- A delegated integration uses an OAuth-style grant that is restricted to a single SaaS tenant, limiting lateral movement if the token is copied or replayed.
- A customer-facing agent is permitted to upload one document to one storage bucket, but not enumerate buckets, rotate keys, or access unrelated files, echoing lessons seen in the Salesloft OAuth token breach.
For implementation context, pairing scoped access with established identity guidance from the NIST Cybersecurity Framework 2.0 helps teams connect token design to governance, logging, and access review.
Why It Matters in NHI Security
Resource-locked tokens reduce the damage that follows compromise, but they only work when the target service validates the constraint on every request. If a token can be replayed across resources, copied from logs, or reused after a workflow completes, the security value collapses and the agent behaves like it has standing privilege. That is why resource-locking is central to modern NHI controls, especially where secrets are overexposed in tickets, chat systems, and code. NHIMG research shows 44% of NHI tokens are exposed in the wild and 91% of former employee tokens remain active after offboarding, underscoring how often credentials outlive their intended scope and owner. The same pattern appears in incidents such as the Vercel Context.ai OAuth Supply Chain Breach, where delegated access became a liability once trust boundaries were loose.
Organisations typically encounter the operational impact only after a token is replayed, at which point resource-locking becomes an unavoidable containment issue to address.
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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers overprivileged NHI credentials and the need for narrow delegated access. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to enforce least privilege for delegated identities. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero trust requires explicit authorization checks for each resource request. |
| NIST SP 800-63 | AAL2 | Assurance guidance informs the strength and binding of delegated access credentials. |
| OWASP Agentic AI Top 10 | A3 | Agentic systems must constrain tool and data access to approved boundaries. |
Issue tokens with the minimum resource and action scope required, then verify enforcement at the server.
