The Authorization Gap in AI Agents: Three Critical Token Design Flaws

1. Why Can the Same AI Agent Access Different Users’ Data?

In enterprise systems, an AI agent may be able to query employee compensation data as well as customer orders. The central question is: whose authority is the agent using to perform these actions, and how does the system determine what it is allowed to access?

Consider a developer using an AI coding assistant. A developer asks the assistant to refactor a section of code. In this case, the actual user is the developer, and the assistant is executing a task explicitly delegated by that user. The assistant may read the code repository, modify files, and run tests, but all of these actions should remain within the developer’s own permissions.

This scenario appears straightforward, but it exposes a core authorization problem: an access token expresses who has been authorized, not necessarily who is actually performing the operation.

2. The Basic OAuth 2.0 Model

OAuth 2.0, defined in RFC 6749, addresses how a third-party application accesses resources with a user’s authorization. The model includes four roles:

• Resource owner: the user
• Client: the application initiating the request
• Authorization server: the service that issues tokens
• Resource server: the service that stores data and validates tokens

Tokens include scopes. The resource server uses the token’s subject and scopes to decide whether to allow or deny a request.

When an AI agent is integrated into this model, it is technically a client. This creates an immediate problem: a single client often holds one token, and that token may cover multiple data domains.

3. Gap One: Confusing the Acting Identity

A token usually contains a single subject, or sub, that identifies the user. When the resource server receives a request, it may only see “a token belonging to Xiaoli.” It cannot distinguish between the following situations:

• Xiaoli is performing the operation directly;
• An agent delegated by Xiaoli is executing the current task;
• The agent has deviated from the authorized task because of prompt injection or another cause.

This is a classic confused deputy problem. The deputy holds more authority than the original requester should have for a particular operation, but the request is still accepted because the deputy is treated as an authorized actor.

One way to address this issue is to represent both the authorizing user and the actual executor in the token. The token exchange mechanism defined in RFC 8693 allows a token to record both sub for the user and act for the acting agent. Audit logs can then reconstruct the complete delegation chain.

Example pseudocode, using generic semantic fields:

claims = {
    "sub": "user:xiaoli",                      # Authorizing end user
    "act": {"sub": "agent:code-refactor"},     # Agent executing the task
    "scope": "repo:read repo:write",           # Task-specific scopes
    "task_id": "task-20261113-001",            # Bound task identifier
    "exp": 1731463200                          # Short-lived expiration timestamp
}

4. Gap Two: Overly Broad Permission Scopes

For convenience, many integrations give an agent a single “all-purpose” token. Once the agent obtains that token, it can access every data domain covered by it.

Returning to the previous example, suppose the same token grants permission to read employee compensation data and query customer orders. While the agent is checking an order status, it could technically read compensation data as well. The authorization model does not prevent this access. Instead, it relies on the prompt or application logic to ensure that the agent behaves appropriately. That is not a reliable security boundary.

The principle of least privilege requires the following:

1. Divide scopes by task rather than granting access to the entire system.
2. Authorize sensitive data domains, such as compensation and identity information, separately and deny them by default.
3. Require confirmation or stronger authentication for high-risk operations.
4. Have the resource server independently validate permissions rather than trusting scopes reported by the client.

The fourth point is especially important. The resource server must enforce its own access policies and reevaluate every request. It should not allow an operation merely because the token appears to be valid.

5. Gap Three: Weak Alignment Between Token Lifetime and Task Lifetime

Traditional applications often rely on one-time user consent and long-lived tokens. AI agents behave differently. An agent may invoke dozens of tools within a few minutes, or it may run on a schedule when no user is present.

This creates two risks. First, if a token remains valid for too long, a token leak creates a larger attack window. Second, if the token is not tied to a specific task, the same token can be reused for arbitrary later operations, while the user has little visibility into what the agent is doing.

Recommended practices include:

• Use short-lived access tokens together with a refresh mechanism.
• Bind a task identifier to the token or request context.
• Prompt the user for real-time confirmation before sensitive operations.
• Maintain complete audit logs, including the delegation chain, request parameters, and summarized results.

6. Authorization Design for Three Common Scenarios

Scenario 1: A developer’s coding assistant.
The user delegates the task directly, so the executor’s actions are aligned with the user’s intent. Authorization should focus on limiting access to the relevant code repositories and preventing access to production credentials.

Scenario 2: An internal enterprise business agent.
A single agent may serve multiple employees. Each request should query data under the identity of the currently authenticated user. The agent itself should not hold a global, cross-user read permission. Otherwise, any unauthorized call could expand the scope of the breach.

Scenario 3: An unattended automation task.
When no user is online, the system should use a dedicated service identity and restrict its permissions to the minimum set required for the specific task. It should also retain a human approval path for operations that exceed the predefined scope.

7. Implementation Checklist

• Give each agent an independent client identity instead of sharing credentials with other services.
• Include both the user and the executor in the token.
• Define scopes at task level and disable sensitive data domains by default.
• Use access tokens with lifetimes measured in minutes, extending access through a refresh mechanism when necessary.
• Require the resource server to validate permissions independently rather than relying on client declarations.
• Ensure audit logs can reconstruct the full delegation chain and operation results.

The goal of agent authorization is to make every data access answer three questions:

Who is the agent acting for? Which task is it performing? How much authority does it have?