# We're Entering the Age of AI Connectivity

**February 3, 2026**  
**9 min read**

**Deepak Grewal**  
Staff Solutions Engineer

For too long, the [Model Context Protocol (MCP)](/content/blog/learning-center/what-is-mcp/index.html) has operated on a principle of open access: connect an AI agent to an MCP server, and it gets access to every single tool that server offers. While this approach is simple for initial experimentation, it quickly becomes a liability in production. Exposing unneeded tools to an agent creates a significant security risk from over-permissioned agents and a severe performance hit known as "Context Rot" that degrades an LLM's ability to reliably select the right tool.

This post breaks down why traditional prompt-injection defenses miss the more fundamental issue of tool governance, and introduces a robust, gateway-level solution for implementing tool-specific Access Control Lists (ACLs), ensuring your AI agents only see — and can only use — the capabilities they absolutely need.

## TL;DR?

[MCP servers](/content/blog/engineering/mcp-servers-guide/index.html) expose all tools by default. There are two problems with this: security (agents get capabilities they shouldn't have) and performance (too many tools degrade LLM tool selection). The solution? Put a gateway between agents and MCP servers that filters tools based on who's asking. Default deny, role-based access, credential isolation.

### Who this is for:

- Platform engineers deploying AI agents to production
- Anyone connecting agents to multiple MCP servers
- Teams hitting context limits or seeing degraded tool selection
- People who want gateway-level security patterns for MCP

### Skip this if:

- You're experimenting with MCP locally
- Your agents use 1-2 MCP servers with <20 tools total
- You're looking for prompt injection mitigations (not covered here)

## Understanding MCP tool exposure

MCP servers expose tools by default — all of them. Connect an agent to an MCP server, and it gets access to every capability that server offers. No scoping, no filtering, no restrictions. This is fine for experimentation. It's a problem in production.

GitHub's MCP server exposes 40+ tools. Jira, Confluence, Slack — each adds more. Connect an agent to three or four MCP servers, and you're easily looking at 100+ tools loaded into context before your agent does anything useful.

Most MCP security discussions focus on prompt injection and tool poisoning. Important threats, but they miss something more immediate: what happens when you hand an AI agent a toolbox it can't effectively use? This post covers why restricting MCP tools matters for security and performance and how to implement tool-level access control at the gateway layer.

## The dual problem: AI agent security and context window limits

Restricting tools solves two distinct problems:

### 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.

## Context rot: Context window optimization research

Context rot refers to performance degradation when LLMs process increasingly long inputs. As context grows, models don't degrade gracefully — they become unreliable. They hallucinate parameters, call the wrong tools, and miss instructions.

Anthropic's guidance indicates that tool selection accuracy degrades significantly beyond 30-50 tools. In practice, using Claude Opus 4.5 with its 200K context window, I've observed reliability beginning to decline around 60% context utilization.

## The solution: AI gateway tool access control

The pattern is straightforward: put an MCP gateway between your agents and MCP servers. The gateway intercepts tool lists and filters them based on who's asking.

### 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 │  
└─────────┘      └─────────┘      └────────────┘  
```

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

#### 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.

```
yaml
plugins:
  - name: ai-mcp-proxy
    config:
      mode: passthrough-listener

- name: request-transformer-advanced
    config:
      add:
        headers:
          - '{vault://secrets/github-token}'
```

## 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)
```

### Example JWT payload:
```json
{
  "sub": "cicd-pipeline-agent",
  "iss": "https://your-idp.com",
  "aud": "kong-gateway",
  "exp": 1737312000,
  "github-mcp-access": "github-cicd-agents"
}
```

## Implementing MCP tool restrictions

The `ai-mcp-proxy` plugin supports multiple approaches to restricting tools:

**Option 1: Consumer groups with JWT claim mapping**
```yaml
- name: openid-connect
  config:
    consumer_groups_claim:
      - github-mcp-access  # Claim value becomes consumer group name
```

**Option 2: Static consumer assignment**
```yaml
consumers:
  - username: vuln-scanner-agent
    groups:
      - name: github-security-scanner
    keyauth_credentials:
      - key: ${SCANNER_API_KEY}
```

**Option 3: Route-based separation**
```yaml
routes:
  - name: mcp-github-readonly
    paths:
      - /mcp/github/readonly
    plugins:
      - name: ai-mcp-proxy
        config:
          tools:
            - name: search_code
            - name: get_file_contents

- name: mcp-github-cicd
    paths:
      - /mcp/github/cicd
    plugins:
      - name: ai-mcp-proxy
        config:
          tools:
            - name: search_code
            - name: get_file_contents
            - name: add_issue_comment
```

## Credential isolation for AI agent security

There's a secondary benefit to gateway-managed credentials: agents never see your GitHub token.

### When to implement MCP tool restrictions

1. From day one: Default deny on all tool ACLs
2. Gateway-managed credentials (agents don't hold backend secrets)
3. Logging enabled (you'll want the audit trail)
4. Start with these principles to avoid common pitfalls related to security and performance.