JWTs fail for AI agent access because authorization is static

At a glance

What this is: This is an analysis of why JWT-based authorization is too static for AI agent access, with runtime policy and relationship graphs presented as the better fit.

Why it matters: It matters because identity teams now need authorization models that can follow delegated action, changing context, and revocation across AI agents, service accounts, and human-granted access.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read PermitIO's analysis of JWT limits for AI agent authorization

Context

JWTs were built for static claims and predictable request flows, not for AI agent identity and delegated authorisation. In agentic systems, the central problem is not whether a token can be issued, but whether access can still be judged correctly after the agent has chained decisions, delegated subtasks, or seen its context change mid-session.

That is why this topic sits squarely in AI agent governance and non-human identity management. When identity becomes a runtime actor rather than a passive bearer of pre-set claims, access control has to follow relationships and context, not just token contents.

For practitioners, the issue is not token format preference. It is whether the authorisation layer can represent delegation, revocation, and live context without turning every AI action into a brittle refresh-and-reissue problem.

Key questions

Q: What breaks when JWTs are used for AI agent authorization?

A: JWTs break when an AI agent needs to act on changing context, delegate to other agents, or inherit access across a chain of relationships. A JWT freezes claims at issuance, so it cannot recalculate privilege as conditions change. That makes the token a poor source of truth for agentic authorization, especially when revocation, delegation, and auditability all depend on current state.

Q: Why do AI agents complicate access control compared with service accounts?

A: AI agents complicate access control because they can initiate actions, choose paths, and create delegation chains during execution rather than simply consuming pre-assigned permissions. Service accounts are usually governed as stable non-human identities, but agents need runtime evaluation. That shifts the problem from entitlements at provisioning time to authorisation at action time.

Q: How should security teams evaluate policy-based authorisation for agent workflows?

A: Security teams should test whether policy decisions are made against live relationships and context, not against stale token claims. The key question is whether the system can revoke access, trace delegation, and enforce conditions without waiting for a new token to be issued. If it cannot, the authorisation model is still too static for agentic use.

Q: What is the difference between JWT-based access and relationship-based access control?

A: JWT-based access encodes permission claims into a bearer token, while relationship-based access control resolves access from current relationships such as ownership, delegation, and group membership. In dynamic agent workflows, ReBAC is better suited because the authorisation decision can change when the relationship changes. JWTs describe; ReBAC decides.

Technical breakdown

Why JWT claims fail in agentic workflows

JWTs encode identity facts at issuance time, including subject, scope, and expiry. That works when the access relationship is stable, but it fails when an AI agent acts as a delegator, sub-delegator, or orchestrator across systems. The token cannot recalculate privilege when the original user’s context changes, when data sensitivity shifts, or when the agent needs to combine multiple permissions at runtime. The result is a static artefact being asked to represent a dynamic relationship. Practical implication: use JWTs as pointers to current relationships, not as the source of truth for authorisation.

Practical implication: treat JWTs as identity signals, not fixed permission containers.

Delegation chains need runtime policy evaluation

Agentic authorisation is fundamentally about transitive access. One actor delegates to another, which may delegate again, creating a chain that only makes sense if the policy engine can evaluate the current relationship graph. Relationship-based access control, or ReBAC, models users, agents, and services as nodes connected by edges such as delegated_by or can_view. A policy decision point can then resolve whether the action is valid in the present context rather than assuming the token captured the whole story. That is a different control plane from static entitlements. Practical implication: model delegated access in policy, not in longer token payloads.

Practical implication: move delegation logic into policy decisions instead of expanding token scope.

Why token chaining becomes brittle at scale

Trying to express more context inside a JWT creates practical failure modes. Large payloads strain headers, refresh cycles add latency, and every added claim increases the chance that authorisation becomes stale before the action completes. In multi-agent systems, that staleness compounds because each hop may need its own token and its own refresh logic. The architecture becomes harder to audit as well, because the authoritative relationship between action and approver is smeared across multiple artefacts. Practical implication: if the access decision depends on current state, policy evaluation must happen at request time.

Practical implication: do not turn runtime access decisions into token engineering problems.

NHI Mgmt Group analysis

Static bearer tokens are the wrong mental model for agentic identity. JWTs assume access can be captured as a fixed set of claims, then replayed safely until expiry. That assumption was designed for human and service flows where the subject is relatively stable. It fails when the actor is an AI agent because the access path is created, combined, and sometimes delegated during execution. The implication is that authorisation design has to move from precomputed entitlement to live relationship evaluation.

Relationship-based access control is the right structural response, not a token enlargement exercise. The article correctly points toward ReBAC because agents, users, and services are better represented as connected nodes than as isolated claim holders. That approach aligns with OWASP NHI and ZT-NIST-207 thinking: identity should be evaluated in context, with policy deciding whether the relationship still authorises the action. Practitioners should treat graph-based authorisation as the baseline for AI agent governance.

Accountability depends on preserving the delegation chain, not just the token string. When the system can trace who granted access, which relationship existed, and why an action was allowed, governance becomes defensible. That matters across NHI, human identity, and agentic AI because the approval trail must survive role changes, offboarding, and delegated subtasks. The implication is that auditability must be built into the authorisation model itself.

Least privilege for AI agents cannot be defined once and assumed to hold. A scope string is only useful if the underlying access context stays stable, and agentic systems invalidate that premise. This is a runtime governance problem, not a static permission problem. Practitioners need to reframe privilege as continuously evaluated relationship state rather than a bearer token attribute.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader baseline on agentic risk, see OWASP Agentic AI Top 10 for the controls most often stressed by runtime delegation and tool misuse.

What this signals

A token-first identity stack will not age well as AI agents become more common inside application and infrastructure workflows. The programme signal to watch is whether authorisation can be re-evaluated continuously, with live relationships replacing static claim assumptions. With 70% of organisations granting AI systems more access than a human employee doing the same job, according to The 2026 Infrastructure Identity Survey, the access model itself is now part of the attack surface.

Identity relationship graphs: the practical shift is from stored entitlements to evaluated relationships, and that change affects human offboarding, service-account governance, and agent delegation in the same control plane. If your access reviews cannot explain who authorised what, and under which live relationship, they will not scale to agentic systems. For standards alignment, practitioners should map these decisions to the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework where autonomous behaviour is in scope.

For practitioners

• Audit static token dependencies in agent flows Map every AI agent workflow that still relies on JWTs for delegated action, then identify where claims, scopes, or expiry values are being used as a proxy for current authorisation. Replace those assumptions with live policy checks where the action path can change at runtime.
• Move delegated access into policy decisions Use a policy decision point to evaluate current relationships, context, and resource sensitivity before the agent acts. Keep the token as an identity pointer, but make the policy engine responsible for deciding whether the current relationship still authorises the request.
• Represent agents and services as relationship graphs Model users, agents, and workloads as nodes with explicit delegation edges so access can be recalculated when roles change or access must be revoked. This makes offboarding, revocation, and audit tracing possible without rebuilding the access model for every workflow.
• Test token refresh as a failure mode Simulate multi-agent flows where context changes before token expiry and confirm whether access remains safe, traceable, and revocable. If the answer depends on more token chaining, the authorisation design is already too brittle for agentic use.

Key takeaways

• JWTs are too static to represent the live delegation and context changes that define AI agent authorization.
• Agentic access control needs runtime relationship evaluation because token claims freeze privilege at issuance.
• Practitioners should treat policy decision points and relationship graphs as the baseline control pattern for AI agent governance.

Key terms

• JSON Web Token: A compact token format that carries identity claims between systems. In practice, it is a bearer artefact with fixed fields such as subject, scope, issuer, and expiry, which makes it useful for simple authentication but weak for dynamic authorisation decisions.
• Relationship-Based Access Control: An authorisation model that grants access from current relationships rather than from static role assignments alone. For AI agents and service identities, the key advantage is that delegation, ownership, and trust edges can be evaluated at runtime instead of being frozen into a token.
• Policy Decision Point: A component that evaluates whether a request should be allowed by applying policy to live identity, resource, and context data. In agentic systems, it becomes the control layer that decides access at the moment of action instead of relying on pre-issued claims.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Why JWTs Can’t Handle AI Agent Access. Read the original.