By-Value Token

Expanded Definition

By-value tokens are common in modern service-to-service and agentic workflows because they package claims, scope, and expiry into the token itself. That makes them efficient for distributed systems and federated access, especially when a verifier can validate the signature locally without a round trip to an authority. In NHI security, the practical distinction is not just that the token is self-contained, but that it can also be copied, replayed, forwarded, and cached in places the original issuer never intended. Definitions vary across vendors on whether short-lived JWTs, bearer tokens, and access tokens are all treated as by-value tokens in every context, so teams should focus on the operational property rather than the label. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity data and access control must be handled according to risk, not convenience. In practice, by-value tokens sit at the boundary between portability and exposure, which is why they are often used for APIs, AI tools, and delegation chains where bounded trust is acceptable. The most common misapplication is treating a by-value token like a harmless reference credential, which occurs when teams store it in logs, chat, or shared tickets without considering replay.

Examples and Use Cases

Implementing by-value tokens rigorously often introduces revocation and replay-management overhead, requiring organisations to weigh verification speed against control over token circulation.

• A service mesh issues a signed access token to an AI agent so the agent can call downstream APIs without querying the issuer on every request.
• An external integration receives a time-bound bearer token for a limited scope, which simplifies federation but raises exposure if the token is copied into telemetry.
• A pipeline job uses a short-lived token for deployment actions, similar to the risk patterns discussed in the JetBrains GitHub plugin token exposure and the Guide to the Secret Sprawl Challenge.
• A federated SaaS connection carries claims inside the token so the receiving system can authorize without persistent lookup, a model aligned with the portability assumptions of RFC 7519: JSON Web Token.
• Teams use by-value tokens for delegated automation when the receiving service needs fast, local authorization and the token can be constrained by expiry, audience, and scope.

The main tradeoff is that stronger portability often means wider blast radius if the token is exposed, so the design must match the sensitivity of the action it unlocks.

Why It Matters in NHI Security

By-value tokens are central to NHI governance because they are both identity-bearing and highly movable. Once a token is duplicated into chat, ticketing, build logs, or browser storage, the organisation loses the containment that a reference lookup or session-bound credential might have provided. NHIMG research shows that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, a reminder that modern agent interfaces can become unexpected token distribution paths. The same pattern appears in incidents such as the Salesloft OAuth token breach and the Internet Archive breach, where token handling choices shaped the extent of compromise. For NHI programs, the key issue is lifecycle control: issuance, scope, expiry, storage, and revocation all need to be explicit because validation alone does not reduce exposure once the token is out in the wild. Organisations typically encounter the full impact of by-value token design only after a leak or replay event, at which point token scope and lifetime become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does DPoP add more value than bearer-token rotation alone?
• Why do AI programs need more than token spend dashboards to prove value?
• What is the difference between measuring AI token usage and measuring business value?
• When should organisations measure coding-agent value by outcomes instead of raw token spend?