Why JWTs Can’t Handle AI Agent Access

As we continue to embed AI agents more deeply into our applications and infrastructure, a new class of security problems is emerging. These are challenges we are not equipped to handle with the tools we relied on just a few years ago.

Authorization is at the core of this shift.

We are entering a world where autonomous agents, not just users or services, initiate actions, make decisions, and interface with systems. Most of our current authorization architecture, especially token-based models like JWTs, was not designed for this environment. As the complexity of agent interactions increases, the fragility of these legacy approaches becomes more evident.

JWTs and the Static Mindset

JWTs, or JSON Web Tokens, have been the default mechanism for encoding identity and access information in distributed systems. They are stateless, portable, and simple to integrate. However, they come with several assumptions that do not hold in agentic workflows.

A JWT carries pre-defined claims: issuer, subject, scopes, expiration, and possibly some contextual information. Once the token is issued, its contents are fixed. If a user’s role changes, or if the access context shifts, the token does not reflect that change unless it is reissued. This model works reasonably well in direct user-service flows, but it breaks down in scenarios involving delegation, transitive permissions, or runtime context evaluation.

// Static JWT payload
{
  "sub": "agent-b",
  "scope": "read:docs",
  "delegated_by": "agent-a",
  "exp": 1720000000
}

Agentic systems introduce all of these complexities as a default behavior.

The Delegation Problem

In a traditional system, a user is authenticated, a token is issued, and it is validated on each request. In contrast, agentic flows involve users delegating actions to agents. These agents may then delegate subtasks to other agents or orchestrate service chains on the user's behalf. These are not edge cases; they are fundamental to how modern AI agents function.

Consider a scenario where Agent A delegates to Agent B, which performs an action on behalf of a user. If the user’s permissions change mid-process, or if the context (such as data sensitivity or the origin of the action) becomes relevant, the original token cannot account for that. Now Imagine the agent chain to be longer...

Trying to model all this using JWTs would require issuing multiple tokens, each carrying limited scope and each needing frequent refreshes. This approach is operationally complex and prone to security issues.

Tokens, by nature, represent static facts, not dynamic relationships. Agent authorization depends on understanding how entities are connected and under what circumstances those connections apply. This is a gap JWTs were never designed to fill.

Why Policy Decision Points Are Better Suited

Policy Decision Points (PDPs) provide a dynamic alternative. Rather than encoding access decisions into static tokens, they separate the logic from the token entirely and evaluate it in real time.

Tools like Open Policy Agent (OPA), Google Zanzibar, or Permit.io’s own Policy Decision Points , allow developers and security teams to define granular access control rules using policy as code. These rules can incorporate runtime attributes, conditions, and relationships. They can be updated and evaluated continuously.

# Check if user or agent has transitive access
allow {
  has_relationship(input.actor, input.resource, "can_view")
}

has_relationship(actor, resource, rel) {
  graph.traverse(actor, resource, rel)
}

A key capability we rely on at Permit.io is relationship-based access control, or ReBAC, modeled as a graph. In this model, users, agents, and services are nodes; relationships are edges. For example, “Agent B was delegated access by Agent A,” or “User X is the owner of this resource.” These relationships are resolved at runtime, allowing the system to determine what access should be granted based on the current context.

This model supports:

• Delegation chains involving multiple agents and users
• Live updates to permissions when relationships change
• Clear audit trails that trace actions back to the original authorizer
• Contextual enforcement based on time, geography, or risk scores.

This approach is both scalable and maintainable.

What We’re Seeing in the Field

Organizations we work with, including some of the world's leading Fortune 100, consistently ask for help translating user stories into enforceable policies. They are not simply looking to grant access; they need control, visibility, and resilience. They want to model trust explicitly, not assume it is implicitly encoded in a token.

At the same time, developers building agent frameworks and integrating LLMs into their products are running into limitations. They are trying to extend OAuth2 and JWTs to accommodate delegation, but these tools were not built for that. Token chaining is fragile; scope modeling is rigid; and delegation remains a difficult problem.

MCP, the Metadata Communication Protocol developed by OpenAI and others, attempts to define how agents communicate and authenticate. While it covers aspects of agent metadata and context, its authorization scope is limited. The protocol still leaves critical pieces, such as delegated action enforcement, undefined.

We are participating in working groups such as AuthZen, under the OIDC, to help address these gaps. But standardization is a slow process. In the meantime, many developers are forced to build ad hoc solutions, often by increasing the number of tokens in circulation and hoping they hold up under pressure.

Why Shoving More into Tokens Won’t Work

A common suggestion is to embed additional information in structured tokens. In theory, you could encode delegation chains, scopes, and time constraints into a JWT. In practice, this becomes unmanageable.

Tokens have size limitations; HTTP headers are not built for kilobyte-sized payloads. Refreshing tokens in a multi-agent flow adds latency and fragility. And the more data you push into the token, the less dynamic and more brittle your system becomes.

A better approach is to use tokens to describe relationships, not entitlements. Then, a policy engine with access to current data can determine what actions are allowed. This keeps the system lean and adaptable.

This also improves accountability. When an agent performs an action, the system can trace the delegation chain to the human or service that granted it access. If that individual’s role changes or they leave the organization, the graph updates automatically and access is revoked.

Looking Forward

Agent-first applications are already here. Developers are building AI agents into SaaS platforms, CI/CD systems, support flows, and more. These agents require autonomy to be useful; they also need boundaries to be safe.

We believe the right model looks like this:

• Agents present delegation tokens that point to relationships
• The authorization layer uses a policy engine to evaluate these tokens in context
• Permissions are derived through graph traversal, not assigned directly
• Accountability always traces back to a responsible party.

At agent.security by Permit.io, we are building tools to support this model. Our open source project, OPAL, keeps policies and data live and synchronized. Our policy engine supports OPA, and custom Google Zanzibar implementation. We have built native support for graph-based delegation, and we are working with other ecosystem players to help define standards.

Tokens are not going away, but their role is changing. They should no longer be treated as complete permission payloads. Instead, they should act as signals—pointers to relationships that a policy engine can evaluate in real time.

The future of agent authorization will not be pre-computed; it will be derived, dynamic, and governed by policies that adapt to the systems we are building.