The evolution of AI agents and autonomous systems has created new challenges for enterprise organizations. While securing API endpoints is well-understood, controlling access to individual AI agent tools presents a unique authorization problem. Today, we're excited to announce a powerful solution to this challenge: MCP Tool ACLs in Kong AI Gateway 3.13.

Modern AI agents interact with external systems through the Model Context Protocol (MCP), accessing various tools and capabilities to accomplish their tasks. However, until now, organizations faced a binary choice: either grant full access to all tools exposed by an MCP server or deny access entirely. This all-or-nothing approach created significant security and governance challenges.

Consider a flight booking system: you might want developers to query flight data and retrieve booking details, but restrict the ability to actually book or delete flights to specific teams or applications. Traditional API authentication couldn't solve this problem at the tool level — you needed true authorization capabilities.

MCP Tool ACLs (Access Control Lists) enable organizations to implement granular authorization policies that control which tools within an MCP server can be accessed by specific users, applications, or AI agents. This feature operates at the gateway layer, allowing you to:

• Filter tools based on identity: Different consumers receive different subsets of available tools based on their authenticated identity
• Implement default-deny policies: Start with zero access and explicitly grant permissions to specific tools
• Leverage consumer groups: Organize authorization policies using Kong's existing consumer group functionality

Maintain RESTful upstream APIs: Continue using standard REST APIs while exposing MCP interfaces at the gateway.

One of the most powerful aspects of Kong AI Gateway is its ability to bootstrap an MCP interface from existing RESTful APIs. Here's how the complete workflow operates:

1. Start with Your Existing API

Let's say you have a flight service API with several operations:

• GET flight data (all flights, by flight number, flight details)
• POST book new flights
• DELETE existing bookings

This API is defined in OpenAPI specification and works with standard REST clients.

2. Deploy the MCP Proxy Plugin

Kong AI Gateway's MCP Proxy Plugin transforms your RESTful API into an MCP-compatible interface. Incoming requests from AI agents, IDEs, or MCP inspectors use the MCP protocol, while Kong translates these to standard RESTful upstream requests.

3. Secure with OAuth2/OIDC

Integration with authorization servers with the MCP OAuth2 plugin provides robust authentication, identifying the developer, application, or agent attempting to access your MCP server. The MCP OAuth2 plugin acts as an extension to OpenID Connect (OIDC), allowing for seamless integration with compliant identity providers. In our implementation, we use Okta as the identity provider, generating OAuth2 tokens that authenticate each connection.

4. Apply Tool-Level ACLs

Here's where the magic happens. In your Kong configuration, you define a default ACL policy and then explicitly grant permissions:

This creates a default-deny policy where the dev-team consumer group is blocked from all tools by default. Then, for specific tools you want to expose:

This approach ensures that only explicitly permitted tools are accessible. Tools without an allow ACL—like booking and deletion operations—remain blocked by the default policy.

5. Dynamic Tool Filtering

When an MCP client connects and executes the tools/list RPC call, Kong intercepts the response from your upstream API and filters the tool list based on the authenticated user's permissions. Clients only see the tools they're authorized to use — they never even know about restricted tools.

Developer Environment Separation

Development teams can query production data and test integrations without risk of modifying critical records. QA teams receive read-write access to staging environments, while production write access remains restricted to specific service accounts.

Multi-Tenant SaaS Applications

Different customers or tenants can access different subsets of tools from the same MCP server. A basic tier might access read-only tools, while premium tiers unlock advanced capabilities—all managed through declarative ACL policies.

AI Agent Safety Rails

Deploy AI agents with confidence by limiting their tool access based on risk profiles. Customer-facing agents might only access retrieval tools, while internal agents receive broader permissions for automated workflows.

Compliance and Audit

Organizations in regulated industries can enforce strict segregation of duties by ensuring that users who can query sensitive data cannot also modify or delete it—a common compliance requirement.

Let's walk through a practical example using Kong's declarative configuration. We'll expose flight operations via MCP and give the development team read access while restricting booking and deletion operations.

Step 1: Configure the Service and Route

Step 2: Add MCP OAuth2

This configuration integrates with your OAuth2 identity provider (Okta in this example) and validates the presented JWT Token.

The MCP OAuth2 plugin also offers RFC 8707 compliance, exposing a resource metadata endpoint. This allows MCP clients to discover the authorization server and resource location automatically.

Step 3: Configure MCP Proxy with Tool-Level ACLs

Understanding the ACL Logic

The configuration above implements a default-deny approach:

1. The default_acl blocks all tools for the dev-team consumer group

2. Individual tools explicitly allow access by adding the dev-team to their allow list

3. Tools without explicit allow ACLs (like booking and deletion) remain blocked

4. This creates a secure-by-default posture where new tools are automatically restricted

Step 4: Connect and Verify

When developers authenticate via OAuth2 and connect their MCP client (such as the Insomnia MCP inspector), the tools/list call returns only the three GET operations. The POST and DELETE tools are completely filtered out—clients never see them in the available tools list.

The MCP Tool ACL feature integrates seamlessly with Kong's existing capabilities:

• Authentication layer: MCP OAuth2 plugin handles OAuth2 introspection and JWT validation
• Identity resolution: Authenticated principals are mapped to Kong consumers and consumer groups
• Authorization enforcement: MCP Proxy Plugin evaluates ACL policies against the consumer's group memberships
• Response filtering: Tool lists are dynamically filtered before being returned to clients
• Audit logging: All access attempts and tool invocations are logged for compliance

MCP Tool ACLs are available now in Kong AI Gateway 3.13. To start using this feature:

1. Update your Kong Gateway to version 3.13 or later
2. Configure the MCP Proxy Plugin with your OpenAPI specification
3. Define your ACL policies using declarative configuration
4. Set up authentication using the OpenID Connect plugin
5. Map users to consumer groups based on your organizational structure

For detailed documentation and configuration examples, visit the Kong AI Gateway 3.13 release notes and the MCP Proxy Plugin documentation.

Better together: Insomnia + Kong AI Gateway as MCP trust layer

Kong’s MCP support isn’t locked down to the AI Gateway. You can also use Kong Insomnia to inspect and test MCP workflows–and even test how certain AI Gateway policies work when used for MCP use cases.