Why do exposed JWTs and API tokens create such high risk?

Why Exposed Tokens Are So Dangerous

JWTs and API tokens are powerful because they are already trusted by the target system. When they are exposed in code, chat tools, tickets, logs, or browser storage, the attacker often does not need a password reset, MFA prompt, or interactive session at all. That makes them ideal replay material for cloud consoles, CI/CD systems, and internal APIs. NHIMG’s 52 NHI Breaches Analysis shows this pattern repeatedly: once a token leaks, the blast radius depends on scope, lifetime, and whether it can be revoked fast enough.

The risk is amplified by the reality that secrets now leak outside source code as well. GitGuardian’s The State of Secrets Sprawl 2026 reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is a strong indicator that detection without revocation is not a defence. Current guidance from NIST also emphasises that identity assurance must be paired with access control and lifecycle management, not treated as a one-time check, as reflected in the NIST Cybersecurity Framework 2.0.

In practice, many security teams only discover exposed tokens after automated abuse has already touched data, pipelines, or admin APIs.

How Tokens Get Replayed in Real Environments

Attackers do not need to “log in” in the human sense. A valid bearer token is often enough to call APIs, fetch secrets, read object storage, trigger jobs, or impersonate an integration account. If the token is a JWT, the attacker may inspect claims to understand roles, audience, and expiry, then reuse it until it expires or is revoked. If it is an opaque API key, the system still has to trust the bearer unless additional controls are in place.

The practical response is a layered control set: short-lived credentials, explicit audience restrictions, tight scopes, and fast revocation paths. For workload-to-workload access, identity should be bound to the workload itself rather than to a reusable secret alone. That is why many practitioners look to workload identity models and zero trust patterns rather than static shared credentials. The Ultimate Guide to NHIs — Why NHI Security Matters Now explains why overused identities and duplicated secrets expand the impact of a single leak, while the Guide to the Secret Sprawl Challenge shows how duplication makes containment harder.

• Use JIT-issued tokens where possible, with short TTLs and automatic expiry.
• Bind tokens to the narrowest possible audience and workload identity.
• Rotate and revoke from a central control plane, not manually per service.
• Monitor for replay from unusual IPs, tooling, or CI/CD runner contexts.

For standard-setting language around identity assurance and access governance, the NIST Cybersecurity Framework 2.0 and the Anthropic report on an Anthropic — first AI-orchestrated cyber espionage campaign report both reinforce that tool access must be tightly bounded when automation can act faster than human operators. These controls tend to break down when secrets are reused across multiple services because one compromise can then pivot across the entire integration chain.

Where the Risk Gets Worse

Tighter token controls often increase operational overhead, so organisations have to balance usability against containment. That tradeoff becomes sharper when legacy systems, long-running jobs, or vendor integrations still depend on static tokens that are difficult to replace quickly. Best practice is evolving, but there is no universal standard for every environment yet, especially where third-party applications cannot support short TTLs or workload-bound authentication.

One common edge case is the “valid but stale” token: a former employee or abandoned service account still has access because revocation never propagated cleanly. NHIMG research has shown that exposed NHI tokens are often sent or stored in collaboration tools and code commits, which makes lifecycle failure as dangerous as the original leak. That aligns with the patterns seen in the Salesloft OAuth token breach, where token exposure translated into direct access rather than an authentication warning.

Another edge case is API-to-API automation at scale. If a platform uses one token for many services, broad replay risk can persist even after one endpoint is secured. Organisations should treat shared tokens, copied JWTs, and embedded API keys as high-severity findings, not routine hygiene issues. The same is true for CI/CD runners and service meshes, where automation can mask abuse until data movement is already underway.

In these environments, token exposure becomes most dangerous when revocation is slow, ownership is unclear, and the same credential can reach multiple systems.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• What are the implications of using OAuth tokens in third-party integrations?
• Why do ephemeral credentials still leave risk in machine access models?
• What makes OAuth tokens risky in NHI environments?