The application and API security industries are rethinking access control for AI agents. However, the underlying foundations remain the same ones the industry has relied on for years. What’s changing is how and when those foundations are applied.

Depending on the use case, a given approach may work best at runtime, with proper contextual signals, or at the point of token exchange. This article highlights how API security is reorienting three cornerstones of access control — identity validation, token handling, and policy enforcement — to meet the demands of agentic systems.

1. Identity Validation Methods: Authentication and Authorization

The first core pillar of access control is validating identity while adhering to established standards and best practices, especially regarding authentication and authorization.

The application and API security industries have relied on authentication and authorization mechanisms to secure access to applications and APIs for years now. For example, OAuth flows allow applications to obtain short-lived or long-lived tokens for securely accessing web-based resources.

While OAuth authorizes resource access, OpenID Connect (OIDC) enables relying parties to verify identity via an ID token issued by an identity provider.

OAuth and OIDC are often used together to create a security framework that verifies who each user is and what they are allowed to do. These mechanisms were initially designed with human users in mind, but they also play a critical role in access control for AI agents.

Delegated Access and Permissions

Autonomous AI agents are applications that often act on behalf of human users while maintaining their own identity. In other words, they perform delegation, and OAuth is well-suited for this purpose. Chris Posta, CTO at Solo.io, aptly explains the concept of OAuth delegation:

“OAuth is fundamentally an authorization delegation protocol. What is being delegated? A user delegates limited access of their data to a specific application. In OAuth terms, the user is the resource owner, the application is the client, and the backend API is the resource server.”

In terms of AI agents, OAuth handles what an agent can do. OIDC serves as the identity layer, verifying who the agent is and on whose behalf the agent is acting.

AI agents can also delegate to other agents. Access control gets significantly more complex when permissions need to propagate across chains of agents. Therefore, it is critical to accurately determine who authorized the access and if that authorization carries through the chain.

Moving Towards Runtime Authorization

Traditionally, access is based on broad, pre-granted permissions. However, the application and API security industries are shifting toward just-in-time authorization that makes every access decision contextual, precise, and real-time. Access is evaluated continuously at every step. This approach minimizes the attack surface because access is determined at runtime instead of being provisioned in advance. Plus, there is no permission inventory to exploit.

Runtime authorization also enables security solutions to have effective authentication and authorization flows for emerging AI agent protocols, such as Model Context Protocol (MCP) and Agent2Agent Protocol (A2A). MCP is primarily about connecting agents and LLMs to tools and data, while A2A is about agent-to-agent collaboration.

MCP adds a layer where each agent must be authorized to access only the tools and resources required for their task. A2A adds another layer where agents (or chains of agents) act with delegated permissions that need to be scoped, verified, and revoked dynamically.

Without secure access flows for these protocols at runtime, AI systems could be exposed to risks such as privilege escalation and unauthorized tool invocations.

2. Token Handling Practices

Another core principle of access control is effective token handling. Tokens have been used for decades to verify user identity and grant authorization, and they’re just as foundational in the agentic AI age.

Implementing OAuth and OIDC involves handling tokens using scopes, claims, and sometimes Token Exchange (RFC 8693).

A claim is an assertion (message) made by an issuer about a subject that allows an application to trust the subject’s attributes. Clients request scopes to signal intended access. It’s up to the authorization server to decide which claims to include in a token. That decision is based on the scopes granted.

When you design an API, you can use scopes to determine which access tokens it will accept, so you can set security boundaries. However, an API can also use attributes from claims to restrict access to certain resources.

Token Exchange is an OAuth 2.0 extension for exchanging one token for another with different attributes. It’s about transforming a token’s type, audience, or delegated identity. Examples of tokens that can be exchanged through this mechanism include ID tokens, access tokens, and SAML assertions.

Handling Tokens for AI Agents

A standard practice for controlling access for AI agents is granting least-privilege, explicit authorization. The idea being that an agent should only have the permissions it needs for the current task. And those permissions should be scoped to the shortest possible time window. Scopes are how you define and limit what a token is authorized to do.

Each token reflects who is acting, who they represent, and what they are allowed to do. Claims are the pieces of information embedded inside a token that answer those questions. These controls help ensure that an AI agent only has permission to complete the actions the user wants it to do.

Another practice is to issue opaque (by-reference) access tokens to external AI agents so that they cannot read the values contained within. This security measure reduces the risk of sensitive information being leaked through the agent. With human users, the concern is primarily token theft leading to unauthorized access to accounts, systems, or data. The concern with AI agents is that, if they’re compromised, they might read and exploit token contents (claims) to expand their own access.

More Token Exchange for Agentic Systems

API security systems continue to use the above mechanisms consistently to control access for human and AI agent users. However, Token Exchange is where significant adaptations are occurring.

The use of Token Exchange is increasing because most AI agents need to call multiple services to perform an action. With this extension, the agent makes an exchange request for each service, but the user doesn’t have to re-authenticate. Also, the agent doesn’t need a separate pre-granted credential for each service.

It’s becoming a common practice to implement Token Exchange flows specifically designed for agent-to-agent delegation. Each hop in a chain of AI agents may require a new token scoped for that specific service and delegated identity. These flows carry forward provenance information about the original authorizing user through each exchange.

3. Policy Creation and Enforcement Approaches

Controlling access to APIs and applications has long involved creating and enforcing various policies. Policies play a critical role in access control. The application and API security industries employ different mechanisms for creating and enforcing access policies.

Role-Based Access Control (RBAC)

RBAC is a common approach to authorization where access policies are based on pre-defined user roles, with users having static responsibilities. RBAC often leads to an excessive number of roles (role explosion) because it relies on static definitions that can’t account for overlapping responsibilities or minor variations in each position. Role explosion is not necessarily a technical flaw in the RBAC model. Instead, it is a problem caused by poor role management and policy governance.

Not Designed for AI Agents

RBAC is not well-suited for access control scenarios involving AI agents. An agent’s role can change at any time during a session, especially a lengthy one. Consider the following scenario.

A developer is using an AI coding agent like Claude Code to investigate, diagnose, and resolve a software regression. The agent starts with read-only access to scan and read various sources, such as codebases, logs, and git commits. It identifies the problem as a slow database query caused by a missing index introduced by a recent update and proposes a fix. The developer approves the proposed solution, and the agent’s role is elevated. It can now write code, modify files, and deploy a hotfix to production.

RBAC wasn’t designed for agents that need roles and permissions changed during a session. However, it’s becoming a common practice to use RBAC as a baseline for human users while layering on top of it dynamic, attribute-based policies specifically for agents.

Attribute-Based Access Control (ABAC)

ABAC is a broad authorization approach that relies on attributes, which allow for flexible access policies that can be enforced externally or internally, depending on the implementation. ABAC has four categories of attributes: subject, resource, action, and environment.

A role by itself can only tell you that the user is a “developer.” Attributes can tell you if they are a developer working at the New York office, accessing a codebase, and using a company-issued device. All these attributes impact the authorization decision.

This approach to authorization aligns with the context-awareness needs of AI agents, as it can evaluate multiple attributes to determine access. ABAC policies can also be adjusted without the need to redefine roles, so this approach can adapt and scale as AI agents evolve and handle more complex tasks.

Evolving ABAC Implementations

One of the most significant shifts in policy creation and enforcement involves ABAC. For human users, like the developer in the scenario above, most attributes remain the same in a session. For example, the office location and device type shouldn’t change. On the other hand, more security solutions evaluate dynamic and agent-specific attributes, such as tools invoked, task context, and position in the agent chain. Some solutions also look at the human behind the agent when making an access decision. These are patterns not commonly present in traditional ABAC implementations.

Open Policy Agent (OPA)

RBAC and ABAC let you create access policies. However, creating policies isn’t enough. You must also enforce those policies. One way to automate policy enforcement is with an open-source authorization engine like OPA, which is commonly used to implement both RBAC and ABAC policies.

Note that policy-based access control (PBAC) is a model where access decisions are driven by policies that combine attributes, roles, and contexts. PBAC unifies the elements of both RBAC and ABAC into a single policy framework.

More Use of OPA and Agent-Specific Contexts

Another shift in approaches involves automating policy enforcement, with more technical decision-makers opting to implement OPA, particularly for AI agent use cases.

OPA can be used to create external access boundaries for AI agents and enforce them at runtime, before tool invocation. They also use this policy engine to ensure policies are adhered to regardless of what an AI agent does or how users prompt the agent. External OPA policies act as a hard guardrail against malicious actors — they are enforced automatically, reducing the risk of being talked out of their restraints by bad actors (which is a risk with AI agents).

Traditional OPA implementations involve policies written in advance, often in Rego, and evaluated against known inputs. It is becoming increasingly common to evaluate policies against inputs that include agent-specific contexts like tool call sequences and delegation chains. This approach for AI agents requires policy authors to anticipate more unpredictable inputs than you’d have with human users.

Same Foundations, Shifting Approaches

The access control mechanisms used for years work just as well for AI agents as they do for human users, but with a caveat. They work effectively for AI agents with a shift in how and when they are used.

Some mechanisms, like authorization and automated policy enforcement, are proving more effective for AI agents when deployed at runtime. Token Exchange is still used the same way but invoked more frequently as agents navigate multiple services and more systems include agent-to-agent delegation. Finally, evaluating and enforcing policies is increasingly done based on runtime context and agent-specific attributes.

When it comes to access control for AI agents, the application and API security industries aren’t reinventing the wheel, they are instead fitting reliable wheels on a new kind of vehicle.