Token enrichment is the practice of adding useful identity and context claims to a token so downstream systems can make faster, local decisions. It is only effective when the added data is stable enough for authorization and limited enough to avoid stale or bloated tokens.
Expanded Definition
Token enrichment means attaching additional identity, device, workload, or request-context claims to an access token so downstream services can evaluate authorisation locally without a round trip to an identity provider. In practice, the value of enrichment depends on whether the added claims are stable enough to trust for the token lifetime and bounded enough to avoid turning the token into a bulky, overexposed data container.
In NHI and agentic AI environments, token enrichment is used to reduce latency, support offline policy checks, and carry attributes such as tenant, service role, environment, or attested workload identity. The design question is not only what can be added, but what should be added. Industry usage is still evolving, and definitions vary across vendors on whether enrichment happens at issuance, at exchange, or at gateway mediation. For operational clarity, NHI Management Group treats enrichment as a control-plane decision, not a place to stuff every available claim. The relevant standards baseline for local authorisation and token validation sits alongside guidance such as NIST Cybersecurity Framework 2.0 and token-oriented federation practices such as RFC 9068.
The most common misapplication is treating token enrichment as a substitute for live policy decisions, which occurs when teams embed rapidly changing entitlements or secrets into long-lived tokens.
Examples and Use Cases
Implementing token enrichment rigorously often introduces a freshness versus performance tradeoff, requiring organisations to weigh faster downstream checks against the risk of stale claims and harder revocation.
- A service token is enriched with tenant ID and environment so a microservice can authorise requests without calling back to the identity provider on every transaction.
- An agentic workflow receives a token enriched with a workload attestation claim, allowing a downstream tool to confirm the caller is the approved automation runner before executing a privileged action.
- A gateway adds risk or network zone context to short-lived tokens so internal APIs can apply local policy during high-volume machine-to-machine traffic.
- A federated session uses enriched claims for role and business unit, reducing repeated lookups while keeping the token small enough to avoid transport overhead.
- NHIMG analysis of the Guide to the Secret Sprawl Challenge shows why enrichment must stay away from secrets, because leaked tokens often travel through code, tickets, and chat. That is consistent with OWASP guidance for AI-facing systems that emphasizes minimising sensitive data exposure in transit and at rest.
- In a federated access design, token enrichment may carry proof-of-assurance or client class claims aligned to the consuming system, especially where the token is validated by edge services rather than a central authorisation layer.
Why It Matters in NHI Security
Token enrichment becomes a security issue when teams confuse convenience with authority. Over-enriched tokens widen the blast radius of a compromise, because any data placed in the token can be inspected, replayed, or abused until expiry. Under-enriched tokens, by contrast, push every decision to downstream systems and can create inconsistent authorisation paths that are difficult to audit. In NHI environments, that matters because workload identities, API clients, and AI agents often authenticate at machine speed and at scale.
NHIMG research has shown how often tokens and related secrets are mishandled in the wild, including the finding that 44% of NHI tokens are exposed in the wild, being sent or stored across collaboration tools, tickets, and code commits. That exposure risk is amplified when enrichment payloads are too broad or too persistent. The same lesson appears in incidents such as the Salesloft OAuth token breach, where token misuse turned access into data exposure. Practitioners should align token handling with NIST Cybersecurity Framework 2.0 by limiting claim scope, validating claim freshness, and revoking tokens quickly when trust changes. Organisations typically encounter the limits of token enrichment only after a token leak or privilege misuse, at which point the design becomes operationally unavoidable 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 address the attack and risk surface, while NIST CSF 2.0 and 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 | Token enrichment must avoid embedding sensitive secrets or overbroad claims. |
| NIST CSF 2.0 | PR.AC-4 | Local authorisation depends on controlled access and least-privilege decisions. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification rather than trusting token contents blindly. |
Use enriched claims to support least-privilege checks without replacing policy governance.
