With the rise of AI agents, many organizations want to expose information that differentiates their business. This can lead to several potential business benefits, such as attracting new parties at internet scale, monetizing those connections, and enabling new and dynamic user experiences. To expose API data effectively, organizations need to consider security, as access to important data often requires security controls. In this article, we will explore a thought process to safely allow access to AI agents while maximizing API business value, focusing on the following key aspects:
1. **Security Considerations**:
– **API Security**: Before deploying an AI agent communication solution, ensure that the API is secure. This involves implementing appropriate access controls to restrict API access to sensitive data. The key is to use a message credential that provides API access, such as a JSON Web Token (JWT) or OAuth 2.0 access token.
– **API Gateway and Authorization Server**:
– **API Gateway**: A secure API gateway manages API entry points, allowing MCP clients to call APIs and authenticate their identity. The gateway should enforce API security by enforcing access controls, validating user identities, and managing API requests.
– **Authorization Server**: An authorization server implements multiple security standards from the MCP authorization specification to ensure secure communication between AI agents and APIs.
With the rise of AI agents, many organizations want to expose information that differentiates their business. Doing so has several potential business benefits: attracting new parties at internet scale, monetizing those connections, and enabling new and dynamic user experiences.
APIs expose data to the outside world and support many types of clients, like web or mobile applications and connections from business partners. In this article, I explain a thought process to safely allow access from AI agents while maximizing the API business value.
AI Agent Communications
Before you can go live with a solution that exposes data, you need to consider security, since access to important data almost always requires security controls. AI agents, therefore, need a message credential that provides API access.
AI agents are subject to internet threats and can also potentially interact with other AI agents. In fact, AI increases the potential for cyberattacks against weak APIs. You therefore need mitigations in case a malicious party manages to gain API access.
Evolving AI Protocols
The good news is that the community behind AI is introducing protocols for interoperability and security. Organizations can integrate multiple protocols, which should work together to enable a secure, open ecosystem where agents and servers can collaborate.
For example, the Model Context Protocol (MCP) specification explains how an AI agent can use an MCP client to interact with MCP servers, which can act as API entry points. The A2A (Agent2Agent) Protocol also introduces rules on how AI agents can call each other to discover features and collaborate.
In particular, the MCP Authorization specification explains an end-to-end security flow that involves MCP servers (APIs), MCP clients, and users. MCP authorization does not reinvent security and uses existing standards, which include the OAuth 2.1 authorization framework. In OAuth, clients like AI agents send access tokens in HTTP headers when they call APIs.
Therefore, to participate in an open ecosystem, AI agents must use access tokens as an API message credential. However, OAuth is a framework where you should apply security at every endpoint and where you have choices over the details. So, what should a secured MCP server deployment look like in practical terms?
Let’s explore the deployment foundations you need to use MCP authorization in the most productive ways. I also briefly summarize the most critical token-related behaviors so that you can control the level of data access you expose to AI agents.
AI-Ready API Deployments
To enable MCP clients to call MCP servers over HTTP, use a deployment that includes an API gateway and authorization server. The gateway manages dedicated API entry points for MCP clients, while the authorization server implements multiple security standards from the MCP authorization specification. Often, MCP servers provide tools that can call upstream APIs.
Your deployment setup should provide a security toolbox that enables you to adapt to changing security demands. You should be able to change security with minimal code impact on applications and APIs. The deployment should enable you to add further security tools in the future, if needed, like service meshes, workload identities, policy engines, and risk engines.
When planning AI integrations, start with the components you need to implement the MCP authorization flow. To see such a flow in action, you can run the Docker-based reference deployment on a local computer. You will see that, with the right separation of concerns, it is not too difficult to implement. The following sections break down some key behaviors.
Establish Trust
To apply OAuth, you can make trade-offs between security and other factors. The choices you make depend on the parties involved and the data sensitivity of resources that APIs expose. First, you need to establish trust so that an MCP client can act as an OAuth client and get an access token with which to call MCP servers. There are multiple choices:
- Allow any MCP client to dynamically register at the authorization server and rely on user authentication to establish trust.
- Restrict MCP clients to those you trust and issue them a client credential. User-facing MCP clients can route requests via a backend component that attaches the credential.
- Use a more advanced solution based on other secure ecosystems like open banking, to allow dynamic onboarding but restrict AI agents to those vetted by a trusted authority.
Design New API Entry Points
You can add new hostnames or paths to the API gateway to provide MCP server entry points. For example, receive all API requests at a subdomain that begins with ‘mcp’. You might apply additional security checks for MCP clients in the API gateway, like rejecting requests from known malicious IP addresses or if a client makes API requests in an unusual sequence.
Next, design how the MCP client will use access tokens. Use OAuth scopes to restrict the API operations and areas of data that the MCP client can gain access to. For example, trades:read might be a low-privilege scope that enables you to deploy an initial API solution for API agents without granting them access to higher sensitivity API data.
Before doing so, ensure that such a token from an MCP client cannot be successfully used at other API endpoints. To meet that requirement, access tokens for MCP clients should use an audience (aud) claim value such as https://mcp.example.com. Every API entry point (including MCP servers) should enforce the presence of its required audience and required scope.
Get Access Tokens in MCP Clients
The MCP client can run an OAuth code flow at the authorization server to get an access token. The user authenticates and chooses whether to consent to the MCP client’s requested level of access, represented by the OAuth scope.
This is another area where you have many choices on the types of user authentication and self-sign-up behaviors you want to allow. In some use cases, it might be sufficient to restrict access to existing corporate users, who use an external identity provider (IDP) to sign in with their organizational login policy.
Design End-to-End Token Flows
You should always issue opaque access tokens to MCP clients so that they cannot read sensitive data intended for APIs. Using opaque access tokens also ensures that large language models (LLMs) do not read token data and misuse it.
When the API gateway receives incoming requests, it can translate opaque access tokens to JWT access tokens using the phantom token pattern, and forward JWTs to APIs. MCP servers that call upstream APIs can use OAuth 2.0 token exchange to adjust values like the token audience before forwarding requests. You then get the following end-to-end token flow within your backend cluster.
Implement Business Authorization
The deeper security requirements are usually to restrict or filter access at the resource level. Often, the best place for the main authorization logic is APIs, so that you can use it for multiple API clients.
To authorize correctly, APIs receive JWT access tokens that contain claims like the user identity. JWTs should be short-lived and cryptographically unforgeable, so that it is difficult for an attacker to get hold of one. However, the primary usage of JWTs is to securely deliver claims.
Design scopes to include a set of claims, so that issuance of a scope triggers issuance of the claims. An example access token payload is shown here, which includes custom claims for trader_id, locations, and industries, which an API might use to filter the user’s authorized trading data at the resource level.
{
"sub": "556c8ae33f8c0ffdd94a5",
"iss": "https://login.example.com",
"aud": "mcp.financial.example.com",
"scope": "openid trades:read",
"trader_id": 1245,
"locations": ["USA"],
"industries": ["oil", "renewables"],
"exp": 1611674155,
}
The nature of AI agents is likely to increase the need for authorization servers to issue dynamic claims. Both user authentication and user consent can collect runtime values that the authorization server issues to access tokens and which APIs later use for authorization. For example, a user might consent to an AI agent’s level of access but impose runtime conditions like money limits, whose values become claims in access tokens.
Although end-to-end flows use security standards, the lower-level complexity is outsourced from APIs and MCP servers to the authorization server. API developers should be able to use straightforward code to implement authorization. They should be able to use the same code to authorize requests from any client, or impose extra conditions on AI-enabled ones. When APIs are correctly secured, organizations should be able to expose any API to the internet for maximum business value.
Adaptive API Security is AI Ready
Now that you understand how tokens flow between components in an MCP deployment, you should understand how the API gateway and authorization server play important roles. Choose an extensible API gateway that can translate tokens. Use an authorization server that supports the required security standards and gives you control over the scopes and claims in access tokens.
The longer-term business benefit is the ability to quickly adapt security in the future, to cope with new threats and requirements. Standards also enable the best interoperability with business partners, who might want to authenticate their employees with their organizational security policy before using AI agents to call your APIs. The authorization server also helps you to keep your login user experience up-to-date.
You still need to think carefully about threats and mitigations, of course, since AI has considerable potential to identify and exploit APIs that use weak security. With OAuth, you have a toolbox for establishing trust. You can follow API security best practices to enforce least privilege access, to prevent cyber attacks, and minimize the impact of any exploits.
