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:

default_acl:
  - allow: null
    deny:
      - dev-team
    scope: tools

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:

tools:
  - description: Get KongAir planned flights
    method: GET
    path: /flights
    acl:
      allow:
        - dev-team  # Explicitly allow this tool

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

services:
- name: mcp-flights-service-acls
  url: http://localhost:8000/kongair
  routes:
  - name: mcp-flights-route-acls
    paths:
      - /flights-mcp
      - /.well-known/oauth-protected-resource/flights-mcp

Step 2: Add MCP OAuth2

plugins:
- name: ai-mcp-oauth2
  config:
    authorization_servers:
    - https://sandbox.oktapreview.com
    client_id: "{vault://ai/kong-mcp-clientID}"
    client_secret: "{vault://ai/kong-mcp-clientSecret}"
    insecure_relaxed_audience_validation: true
    introspection_endpoint: https://sandbox.oktapreview.com/oauth2/v1/introspect
    metadata_endpoint: /.well-known/oauth-protected-resource/flights-mcp
    resource: http://localhost:8000/flights-mcp
    scopes_supported:
    - openid

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

plugins:
- name: ai-mcp-proxy
  config:
    mode: conversion-listener
    consumer_identifier: username
    include_consumer_groups: true
    
    # Default deny policy for all tools
    default_acl:
      - allow: null
        deny:
          - dev-team
        scope: tools
    
    # Define tools with specific ACLs
    tools:
      # Allow read operations for dev-team
      - description: Get KongAir planned flights
        method: GET
        path: /flights
        acl:
          allow:
            - dev-team
            
      - description: Get a specific flight by flight number
        method: GET
        path: /flights/{flightNumber}
        acl:
          allow:
            - dev-team
            
      - description: Fetch more details about a flight
        method: GET
        path: /flights/{flightNumber}/details
        acl:
          allow:
            - dev-team
      
      # No ACL allow for write operations - blocked by default_acl
      - description: Book a flight
        method: POST
        path: /flights/{flightNumber}/bookings
        request_body:
          required: true
          content:
            application/json:
              schema:
                type: object
                properties:
                  passenger_name:
                    type: string
                  passenger_email:
                    type: string
                    format: email
                  seat_preference:
                    type: string
                    enum: [window, aisle, middle]
      
      # No ACL allow for delete operations - blocked by default_acl        
      - description: Delete a flight booking
        method: DELETE
        path: /bookings/{bookingId}

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.