When do JWTs become risky for non-human identities?

Why JWTs Become Risky for Non-Human Identities

JWTs are useful when an automated identity needs portable proof of who it is, but they become risky the moment they behave like long-lived bearer secrets. For service accounts, bots, and integrations, the problem is not just expiration time. It is the combination of reach, replayability, and weak operational visibility. Once a token is stolen, the attacker does not need to defeat the workload again.

This is why NHI guidance treats token handling as a lifecycle issue, not a format issue. NHI compromise is common enough to be a recurring control gap: the Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. A JWT with broad scope, weak audience checks, or no revocation path turns a routine integration credential into a durable access path, which is exactly the wrong shape for NIST Cybersecurity Framework 2.0 asset protection and recovery planning. In practice, many security teams discover token risk only after an integration has already been abused, rather than through intentional review.

How JWT Risk Shows Up in Real Operations

The operational failure mode usually starts with convenience. A JWT is issued to avoid repeated authentication, then copied into code, pipeline variables, or automation config because the workload must keep running. That works until the token lifetime, scope, or validation rules no longer match the actual trust boundary. For non-human identities, current guidance suggests treating JWTs as short-lived claims containers, not standing credentials.

Practitioners reduce risk by combining strict validation with tighter issuance and runtime controls:

• Validate issuer, audience, signature, expiry, and token type on every request.
• Keep TTL short and align it to task duration, not to team convenience.
• Prefer just-in-time issuance and automatic revocation for higher-risk workflows.
• Bind tokens to workload identity where possible so the token proves the caller is the expected machine or agent, not just anyone holding the string.
• Use RBAC and policy checks for coarse access, but add contextual authorisation when the token is used by an autonomous workload.

That last point matters because a bearer token cannot express intent. It says what the caller may do, not whether the current action is appropriate for the task. For workloads that chain tools, call APIs dynamically, or operate across multiple systems, the safer model is ephemeral secrets plus runtime policy evaluation. The Top 10 NHI Issues and OWASP NHI Top 10 both point to excessive privilege and poor secret handling as repeat failure patterns, which is consistent with the broader NIST Cybersecurity Framework 2.0 emphasis on least privilege and continuous monitoring. These controls tend to break down when tokens are shared across many pipelines because the validation logic becomes inconsistent and revocation becomes operationally slow.

Common Variations and Edge Cases

Tighter token controls often increase integration overhead, requiring organisations to balance security assurance against deployment friction. That tradeoff is especially sharp in environments with legacy APIs, multi-cloud automation, or third-party service dependencies, where token refresh and audience binding are not uniformly supported.

There is no universal standard for every JWT deployment pattern yet. For low-risk internal jobs, a short-lived JWT may be acceptable if it is tightly scoped, rotated aggressively, and monitored. For higher-risk autonomous workloads, especially AI agents or multi-step automation, best practice is evolving toward workload identity, JIT credentials, and policy evaluation at request time rather than static bearer access. This is where the distinction between human and non-human identity matters most: humans can be watched through sessions; automated identities often cannot.

Edge cases also appear when teams use JWTs as session substitutes for service-to-service trust. That is workable only if the organisation can prove who issued the token, who can use it, and how quickly it can be invalidated. The Ultimate Guide to NHIs - Key Challenges and Risks highlights how poor visibility and weak rotation practices compound exposure, and JetBrains GitHub plugin token exposure is a useful reminder that even developer tooling can leak tokens into places defenders do not inspect quickly enough. In environments with unmanaged secrets sprawl, JWTs stop being a control and become another durable asset for attackers to harvest.

Related resources from NHI Mgmt Group

• Why do non-human identities become a bigger risk in AI-speed attacks?
• Why does least privilege become harder with non-human identities?
• When do non-human identities pose the greatest risk to organizations?
• What is the first step in managing non-human identities at scale?