How do identity teams know when a JWT should not carry permissions?

Why This Matters for Security Teams

JWTs are convenient because they are self-contained, but that convenience becomes a liability when teams use them as portable permission grants. If access changes after token issuance, the token can keep authorising actions long after policy has changed. That is especially risky for secrets-backed service accounts, CI/CD automation, and delegated API access, where revocation and scope changes must take effect quickly. NHI Mgmt Group notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which helps explain why stale authorisation is such a persistent failure mode in Ultimate Guide to NHIs.

The practical issue is not whether JWTs can encode claims. They can. The question is whether those claims should carry permissions that must remain accurate across the token lifetime. Current guidance from the OWASP Non-Human Identity Top 10 treats overstuffed tokens as a governance smell because it shifts enforcement away from live policy and into stale artefacts. In practice, many security teams encounter this only after a permission change fails to take effect and an incident review shows the token was still trusted.

How It Works in Practice

The safest pattern is to use the JWT for identity context, then evaluate permissions at request time against a live policy engine. That means the token can assert who or what the caller is, the issuer, audience, and a short-lived session reference, while the authorisation system decides whether the action is allowed right now. For non-human identities, this aligns with the broader NHI lifecycle guidance in the Ultimate Guide to NHIs — Key Challenges and Risks.

Identity teams usually treat a JWT as too permission-heavy when any of these are true:

• Permissions change more often than the token TTL.
• Revocation must take effect immediately or near immediately.
• The same caller can legitimately take different actions depending on resource, time, tenant, or workflow state.
• Access decisions depend on context that cannot be known when the token is minted.

In those cases, put only stable claims in the JWT and move the decision to runtime policy. That can be policy-as-code, a central authorisation service, or an internal entitlement check that reads the current state of the target system. The token becomes proof of identity, not proof of permission. This is consistent with modern Zero Trust thinking and with runtime controls described in the Top 10 NHI Issues. Best practice is to keep token TTLs short, make revocation paths explicit, and require fresh evaluation when the risk profile changes.

This approach tends to break down in legacy environments that cannot call a policy service on every request because the application was built to trust embedded claims as its only enforcement source.

Common Variations and Edge Cases

Tighter token design often increases operational overhead, so teams must balance simplicity against the need for accurate enforcement. There is no universal standard for this yet, especially across mixed environments where some APIs are stateless and others depend on rich transaction context.

Long-lived service-to-service tokens are the most obvious edge case. They may look efficient, but if a token can outlive a role change, key rotation, or incident response action, it starts acting like a cached permission set. In high-churn systems, that is usually the wrong tradeoff. By contrast, a short-lived JWT with no embedded permissions may be acceptable when the caller only needs coarse authentication and every sensitive operation is checked against a fresh entitlement source.

Another exception is when a permission claim is merely a hint for user interface selection or low-risk routing, not the final enforcement point. In that case, the claim may be tolerable if the backend still performs the real check. The rule is simple: if the claim can cause a protected action on its own, it should be treated as brittle. If it only improves efficiency and cannot grant access by itself, the risk is lower. Teams that ignore this distinction often discover the problem during breach analysis, not during design review, as seen in cases discussed in 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10.

Related resources from NHI Mgmt Group

• When should teams use step-up verification instead of relying on reusable identity?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How do teams know whether identity dark matter is actually shrinking?