API Security Best Practices for AI Agents
On this page
AI technology can produce pretty impressive results. As a consequence, AI agents are a popular way for users to consume data and, internally, to call APIs. The questions are, what exactly are AI agents and — more importantly — if you have an API, how do you properly secure API access for calls from AI agents?
This article explains security best practices for your APIs that you should follow when handling traffic from AI agents.
What are AI Agents
An AI agent is an application that a user operates (at least in some part) and interacts with using natural language with the goal to have it perform tasks on the user's behalf.
When you work with applications like ChatGPT or Claude, you use what the industry calls an AI application (or GenAI, or simply AI). It enables you to query the underlying Large Language Model (LLM). You send a query to the model — "say" something to the application — and you get a response back. The application can only give you a text response to your input — it cannot do anything else. If you ask it to book you a restaurant table, it will provide you with the steps you should follow to do it.
If you now expand the chat's abilities to actually do something, you get an AI agent. The application can achieve the thing you ask it for, not only describe how to do it. When you have an AI agent and ask it to book you a table, it will search for the restaurant and place the booking.
There are different approaches to how the AI agent can "do" things. For example, the application might be able to operate a browser and click through a page. Another approach is for the application to call APIs. This means that you have LLM-powered applications that are able to send requests to APIs.
AI agents can call the same APIs that are available to other types of clients. Such APIs are commonly located behind an API and access-protected. The novel characteristics of AI agents imply that you need to consider specific requirements and solutions to continue protecting API access.
Requirements for Agentic API Access
When a user lets an AI agent perform some action, they essentially delegate authorization to a semi-autonomous entity. In contrast, when a user operates a regular application, they have to click the "delete" button to delete their record from the database. With LLM-powered applications, there is always risk that the application will determine that it needs to perform certain tasks to fulfill the assignment, even if the user intended something completely different. For example, the application could delete some data when the user asked it to only make some updates.
Using AI agents can result in a divergence between user intention and the actual actions that an AI agent performs. This is why AI agents should always get least-privilege access to APIs. The AI agent should only have permissions to perform the actions that the user expects it to do. If the AI agent performs high privilege actions, the security solution should collect explicit approval from the user.
Giving consent on high privilege actions, allows the user to stay in control of what the AI agent does. The AI agent will not be able to perform any action that the user is not aware of. Such an approach gives both the user and the API provider proper auditability and governance. All actions will have a clear responsibility assigned, which is especially important for sensitive operations. If the API is used to perform a transaction, money transfer, or cancel an insurance, both parties will want to be able to verify who was responsible for taking that action.
These requirements should drive the authorization design of APIs, taking into consideration the best practices described below.
Model Context Protocol Authorization is not Enough
As of late 2025, the most popular way of calling APIs with AI agents is by using Model Context Protocol (MCP), a protocol that standardizes such interactions. The protocol includes a dedicated chapter on about authorization, but it does not solve all the issues you may face when providing APIs.
In MCP you use two pieces of software:
- an MCP client, which runs as part of the AI application, and
- an MCP server, which acts as a gateway to the API.
The specification's authorization deals with properly securing access from the MCP client to the MCP server. This in itself is important, as you don't want to allow anyone to connect to the server freely, also because it is capable of more things than just proxying to APIs. Thanks to implementing authorization between an MCP client and server, developers can control the visibility of the server's capabilities.
However, this authorization does not meet the requirements discussed before. The API itself needs to follow the following best practices.
1) Use OAuth
OAuth is a set of established security standards used to protect API access. It gives developers a solid foundation on which they can build the authorization logic. With OAuth, the API deals with short-lived access tokens issued by a central authority — the OAuth authorization server. The tokens are associated with attributes about the user or the application (claims), that APIs use to make authorization decisions.
OAuth defines flows that allow applications to securely obtain the tokens. It also offers extensions that can add functionality in a standardized way. For example, Dynamic Client Registration can be used to automatically register new AI agents at the authorization server. Token Exchange can become useful to manage the permissions of tokens that AI agents handle.
OAuth is a well-established standard, so there are a lot of tools and libraries that already support it, which facilitates implementation and interoperability. The MCP specification also uses it, so organizations that plan to use MCP will need to work with OAuth regardless.
If your APIs are not protected using OAuth, now is a good time to start working on the migration.
2) Use Scopes to Limit Access
Scopes are a good place to start working with authorization. They are simple strings with fixed values, prepared at the API design time. They allow limiting the endpoints that an application with a given access token can access.
Scopes provide coarse-grained authorization. For example, by issuing a token with scope transactions:history, you can ensure that an AI agent will be able to read the user's transaction history, but will not be able to call endpoints that create new transactions.
You should always use scopes to limit the token's privileges. They help to ensure that AIagents gain access only to the parts of APIs that they should. They are also useful when asking users for consent. A scope value can be associated with a meaningful description so that the user knows what capabilities the AI agent will receive with the given scope.
Yet scopes are only useful for coarse-grained authorization, and they do not provide the full solution. For that, you also need claims.
3) Use Claims for Fine-Grained Authorization
Claims, the attributes associated with the token, give APIs great power to take informed authorization decisions. For example, once an API receives a request for a user's transactions, and it validates that the token contains the required scope, it must now ensure that it returns only the given user's transactions. The API can use the token's subject claim to know which transactions it should return. This gives the API relevant information to perform authorization in a more fine-grained way as compared to only using scopes.
Claims allow APIs to make sophisticated decisions. Maybe you want to ensure that AI agents can only view transactions up to a given amount, or only from the last month, or ones that do not contain products from a sensitive category? This can all be achieved with claims in the token, with values similar to this:
{"subject": "dana.demo","scope": "transactions:history","transaction_not_older_than": "2025-10-01","transaction_amount_limit": "1000","excluded_categories": ["health"]}
Thanks to having these values as access token claims, the APIs have certainty that these attributes have not been tampered with. The values are assigned to the token by the authorization server, which can ask the user to consent to them. Once they end up in the token, the AI agent is not able to modify them, and the user stays in control of what the AI agent has access to.
4) Use AI Context and Audience Restrictions
There are many components involved when calling APIs from AI agents, like the AI application, the MCP client, the MCP server, APIs, and gateways. As a consequence, to secure communication between the components, the architecture involves different tokens. Each access token gives access to certain resources — it has an audience. For security reasons, do not reuse access tokens for audiences and purposes other than they are intended for.
For example, when an MCP client receives an access token that allows it to connect to the MCP server, then that same token should not be used to call an API from the MCP server. The MCP client's access token might have low privileges that allow the client to list and call the MCP server's tools. However, the API might require a high-privilege token, with specific claims, that ensure proper governance of the API request, and could require additional consent from the user. If the MCP server was supposed to reuse the MCP client's access token, then the token would need to already contain the high privileges. This means that it would be very hard for the user to stay in control of the token's privileges, or have least-privilege tokens.
Use techniques like token exchange or transaction tokens to ensure that APIs are called with least-privilege tokens, tailored to the concrete request. This will be especially important in agent-to-agent scenarios, to ensure that one AI agent does not give another too much privilege.
With MCP, you can also use a technique called elicitation, where the API can ask the AI agent for a higher-privileged token, and the user gets redirected to the authorization server to get one. This technique allows for obtaining tokens that contain claims which limit the agent's capabilities as needed. In such a scenario, the authorization server could even issue a token valid for only one concrete request that the AI agent is about to make.
5) Mark API Traffic from AI Agents
To achieve auditability of AI agents' behavior, APIs will need a way to properly mark traffic coming from them. Again, claims are a good fit for that purpose. Authorization servers should issue claims that properly mark that the application is an AI agent.
You can later use claims from tokens for logging and audits to help differentiate traffic coming from LLM-powered applications. They are also useful for adjusting authorization policies when an AI agent calls the API. For example, to globally deny AI agents performing sensitive actions, or to require additional confirmation from the user when a request comes from an AI agent.
6) Use AI Agent Identity
Claims can be further used to differentiate between different types of AI agents. For example, there will be AI agents that can operate as OAuth confidential clients — applications capable of storing secrets. Such applications cannot easily be impersonated by malicious actors, and their access tokens can contain higher privileges.
There are also public clients — applications that cannot hold secrets — that can be easily impersonated by others. Such AI agents should be properly marked in tokens so that APIs can take that into consideration when making authorization decisions. Some actions initiated by an AI agent that is a public client should require additional confirmation from the user, and that can be easily achieved when the API gets this information from the token.
7) Use Short-Lived Access Tokens Only
When the authorization server issues tokens that the AI agent will use to call APIs, it should not issue any refresh tokens. The AI agent should get time-limited access, only for the duration it needs to fulfill its task at hand. Whenever the AI agent needs a new access token, it should ask the authorization server again.
It allows the server to remain in control of whether the user should give another consent. Sometimes the AI agent might request tokens to access low-privilege actions, and the server might issue new tokens without asking the user again. Still, the authorization server has greater auditability capabilities and control when AI agents do not receive refresh tokens.
8) Use Confidential Access Tokens
Whenever your systems issue access tokens to AI agents, ensure that the tokens are opaque — the token should be a random string that serves as a reference to the data associated with it (such tokens are sometimes called by-reference tokens).
That means that AI agents should never handle JSON Web Tokens (JWT). Especially if there is a possibility that the token will be passed to the LLM or to another AI agent. JWTs are by-value tokens — they can be decoded, and their value can be easily accessed by anyone in possession of the token. Should the token contain any personal information, it could get leaked through the AI agent.
Design a Solid Security Foundation
The above best practices create a security architecture that can cover many scenarios. Adjustable, fine-grained authorization gives APIs a solid foundation on which you can build different integrations. Such an architecture is necessary for the agentic revolution and fits well into MCP, which is currently the most popular protocol for AI agents.
However, AI agents are relatively new, and things change dynamically in that space. Agentic protocols other than MCP are emerging, like the Universal Tool Calling Protocol (UTPC), or specifications that support commercial operations, like the Agentic Commerce Protocol (ACP).
With a solid architecture, your APIs will be ready for any future integration, whether or not they are powered by AI.
Michał Trojanowski
Product Marketing Engineer at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
