Security: Over-permissioned agents

An AI agent with access to merge_pull_request can merge code. An agent with delete_repository can delete repositories. Most agents don't need these capabilities, but MCP servers expose everything by default.

This creates shadow tooling—capabilities your agents technically have but shouldn't use. Traditional API security solved this with scopes and permissions. MCP needs the same treatment.

Efficiency: Context rot

Every tool you expose to an agent consumes context. The tool name, description, parameter schema — it all goes into the prompt. Load 40 tools, and you've burned thousands of tokens before the agent does anything useful.

Worse, the agent's ability to select the right tool degrades as options increase.

References:

• Chroma: Context Rot - How Increasing Input Tokens Impacts LLM Performance
• Factory AI: The Context Window Problem
• Arxiv: Solving Context Window Overflow in AI Agents

Model providers are responding. Anthropic's tool search feature addresses this directly:

• Claude can dynamically discover and load tools on-demand
• Tools aren't loaded into context upfront

This is the right direction. But it's Claude-specific. If your agents use multiple models, you need:

• Tool governance that works across OpenAI, Gemini, and open-source models
• Centralized control, not per-agent configuration

That's where gateway-level control comes in.

About the examples below

The examples throughout this post use GitHub's MCP server as the backend, though the patterns apply to any MCP server.

The configurations use Kong AI Gateway with the ai-mcp-proxy plugin. Kong is configured declaratively using YAML files that define:

• Services - backend MCP servers to connect to
• Routes - URL paths that agents use to access services
• Plugins - policies applied to requests (authentication, transformation, ACLs)
• Consumer groups - categories of agents with different permissions

You can apply these patterns with other gateways, but the specific syntax will differ.

Kong consumer groups primer

Consumer groups are Kong's mechanism for categorizing API consumers. The key pattern:

1. Identity first - Identify who's making the request (via JWT token validation)
2. Map to group - Extract a claim from the token that specifies the consumer group
3. Apply ACLs - Filter tools based on the consumer group's permissions

This means ACLs are attached to groups, not individual consumers. You define groups once, configure their tool access, then map any number of consumers to those groups via JWT claims.

Progressive security model

Kong's MCP gateway implements tool governance as a progressive security model with four layers:

Layer 1: Pass-through proxy

┌─────────┐      ┌─────────┐      ┌────────────┐
│  Agent  │ ───► │ Gateway │ ───► │ MCP Server │
└─────────┘      └─────────┘      └────────────┘
     │                                   │
     └── Agent provides GitHub token ────┘

Gateway proxies requests to MCP servers. Agents still provide their own credentials. You get centralized logging and analytics but no access control yet.

Layer 2: Gateway-managed credentials

┌─────────┐      ┌─────────┐      ┌────────────┐
│  Agent  │ ───► │ Gateway │ ───► │ MCP Server │
└─────────┘      └─────────┘      └────────────┘
     │                │                  │
     │                └── Injects token ─┘
     │                    from vault
     └── No credentials needed

Gateway injects backend credentials from a secrets vault. Agents never see the underlying tokens.

Layer 3: OAuth/OIDC authentication

┌─────────┐      ┌─────────┐      ┌────────────┐
│  Agent  │ ───► │ Gateway │ ───► │ MCP Server │
└─────────┘      └─────────┘      └────────────┘
     │                │                  │
     │                ├── Validates      │
     │                │   IDP token      │
     │                └── Injects GitHub ┘
     │                    token
     └── Presents IDP token (Entra, Okta, etc.)

Agents must present a valid token from your identity provider before accessing any MCP endpoint.

Layer 3b: Hybrid authentication (gateway auth with pass-through MCP credentials)

┌─────────┐      ┌─────────────────────┐      ┌────────────┐
│  Agent  │ ───► │       Gateway       │ ───► │ MCP Server │
└─────────┘      └─────────────────────┘      └────────────┘
     │                     │                        │
     ├── IDP token ────────┤                        │
     │   (validated)       │                        │
     │                     │                        │
     └── MCP credentials ──┼── Passed through ──────┘
         (GitHub PAT,         (gateway doesn't
          Jira key, etc.)      manage these)

Not every use case requires the gateway to manage MCP credentials. If your agents connect to multiple backend MCP servers—each with individual, user-specific access—you may want the gateway to handle authentication and governance while letting credentials pass through to the backend.

In this model:

• The gateway validates the agent's identity via JWT
• Tool-level ACLs still apply based on consumer group
• The agent provides its own credentials for the specific MCP server
• Credentials pass through to the backend unchanged

This is useful when users have varying access levels across different MCP servers, or when centralizing credential management isn't practical. The gateway still provides authentication, tool filtering, logging, and rate limiting—just not credential injection.

Layer 4: Tool-level ACLs

┌─────────┐      ┌─────────────────────┐      ┌────────────┐
│  Agent  │ ───► │       Gateway       │ ───► │ MCP Server │
└─────────┘      │                     │      └────────────┘
     │           │ 1. Validate token   │           │
     │           │ 2. Map to consumer  │           │
     │           │    group via claims │           │
     │           │ 3. Filter tools     │           │
     │           │    by ACL           │           │
     │           └─────────────────────┘           │
     │                                             │
     └── Sees only allowed tools ──────────────────┘
         (e.g., 2 tools instead of 40)

Based on JWT claims, the gateway maps agents to consumer groups and filters which tools each group can see.

Example JWT payload:

The github-mcp-access claim contains the consumer group name. When this token hits the gateway, the agent gets mapped to github-cicd-agents and sees only the tools allowed for that group.

Kong configuration:

The key insight: the tool list terminates at the gateway. The backend MCP server might expose 40 tools, but your security-scanner agent only sees 2.

Option 1: Consumer groups with JWT claim mapping

Your identity provider includes a claim (e.g., github-mcp-access) that specifies which consumer group the agent belongs to. The gateway maps this automatically.

Option 2: Static consumer assignment

Define consumers explicitly and assign them to groups. Useful when agents use API keys instead of JWT tokens. These keys are generated and managed by the gateway—essentially virtual credentials that never touch your backend systems.

Option 3: Route-based separation

Create separate routes for different agent types, each with its own tool configuration. Simpler to reason about, but requires agents to know which endpoint to use.

The common thread: default deny. Tools not explicitly listed in the tools array with an allow ACL are blocked.

Note: Tool names are illustrative and may differ from the actual GitHub MCP server implementation.

Notice what's missing: merge_pull_request, push_files, delete_file. No AI agent gets these. Human-in-the-loop by design.

Full configuration:

When the security scanner connects and requests the tool list, it sees exactly two tools. The CI/CD agent sees seven. The code reviewer sees eight. The backend GitHub MCP server still has 40+, but agents only see what they need.

Without gateway:
┌─────────┐                    ┌────────────┐
│  Agent  │ ─── GitHub PAT ──► │ MCP Server │
└─────────┘                    └────────────┘
     │
     └── Agent config contains the credential
         (compromised agent = exposed token)

With gateway:
┌─────────┐      ┌─────────┐      ┌────────────┐
│  Agent  │ ───► │ Gateway │ ───► │ MCP Server │
└─────────┘      └─────────┘      └────────────┘
     │                │
     │                └── GitHub PAT injected
     │                    from vault
     └── IDP token only (scoped to agent's permissions)

Even if an agent is compromised, the attacker gets an IDP token scoped to that agent's consumer group—not your GitHub PAT with repo admin access.

From day one:

• Default deny on all tool ACLs
• Gateway-managed credentials (agents don't hold backend secrets)
• Logging enabled (you'll want the audit trail)
• Gateway overhead for tool filtering is typically sub-10ms

As you scale:

• Define consumer groups by agent function, not by team
• Use JWT claims mapping if your agents already carry role information
• Review tool access quarterly—permissions accumulate

Signs you waited too long:

• Agents calling tools they shouldn't have access to
• Context windows filling up before agents finish tasks
• "We don't know what tools our agents are actually using"

The cost of adding restrictions later is higher than starting restrictive. Shadow tooling is easier to prevent than to clean up.

References

• Chroma Research: Context Rot
• Factory AI: The Context Window Problem
• Arxiv: Solving Context Window Overflow in AI Agents
• Anthropic: Tool Search Tool
• Mirantis: Securing MCP for Enterprise Adoption