MCP tool access control is becoming the new AI gateway priority

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Kong's blog post: MCP tool exposure becomes a production security and reliability problem when every connected server publishes every tool by default.

Why it matters: It matters because IAM and platform teams need to govern tool visibility, not just model prompts, when AI agents and MCP servers are placed into production.

Context

MCP tool governance is the problem space here: when an agent can see every tool a server exposes, the issue is no longer just model quality but access scope. In production, that creates both unnecessary capability exposure and a larger operational surface for mistakes.

The underlying gap is that traditional prompt-injection defenses do not control which tools an agent is allowed to discover in the first place. For identity and access teams, the question is whether tool lists are governed as entitlements, not just as developer convenience.

This is primarily an NHI control issue because the subject is machine-to-machine authorization for agent access to backend capabilities. The article's starting position is typical for early MCP deployments, where convenience is common and governance lags behind adoption.

Key questions

Q: How should security teams restrict MCP tools for production agents?

A: Security teams should place a policy enforcement layer between the agent and the MCP server, then assign each agent persona a minimal allow list. The safest default is deny by default, because any tool that is merely visible can become usable if governance is weak or routing is misconfigured.

Q: Why does exposing too many MCP tools create security and reliability risk?

A: Excess tool exposure expands the number of capabilities an agent can potentially use and increases the chance of incorrect tool selection. In production, that means the same design choice creates both over-permission risk and lower execution quality, especially when several servers are combined into one context.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How do identity-based routing and tool ACLs work together in MCP governance?

A: Identity-based routing decides which requester is asking, and tool ACLs decide which capabilities that requester can see or use. Used together, they let teams keep one backend MCP server while presenting different tool views to different agent personas.

Technical breakdown

Why default tool exposure creates an authorization problem

MCP servers commonly publish the full tool catalog to any connected agent, which means discovery and authorization are collapsed into one open-ended step. In practice, the agent receives tool names, descriptions, and schemas before a governance layer can decide what it should actually use. That is why the issue looks like simple connectivity at first but behaves like an authorization defect once the environment reaches production scale. The control problem is not only whether a tool can be invoked, but whether it should ever be visible to that identity in the first place.

Practical implication: treat tool visibility as an authorization decision and deny unknown tools by default.

How context rot affects tool selection in large MCP estates

Context rot is the reliability drop that appears when too many tools compete for the model's attention inside the same prompt window. Each exposed tool adds metadata, which increases token load and raises the chance that the model picks the wrong capability, hallucinates parameters, or ignores the correct instruction. The article frames this as a performance problem, but in governance terms it is also an access design problem: excessive visibility degrades both operational accuracy and control confidence. The more tools an agent sees, the less deterministic its selection becomes.

Practical implication: reduce exposed tool counts per agent persona so selection accuracy stays within usable bounds.

Why gateway-level ACLs change the control boundary

A gateway inserts a policy enforcement point between the agent and the MCP server, so tool discovery can be filtered based on the requester rather than the backend catalog. That lets teams apply identity-based routing, consumer groups, and tool-level ACLs so different agent classes see different capabilities even when they share the same backend server. Gateway-managed credentials also separate backend secrets from the agent itself, which reduces the chance that one compromised or overreaching agent can act with broad inherited access. This moves the trust boundary from the model to the control plane.

Practical implication: enforce default-deny tool filtering and credential isolation before exposing MCP to production agents.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool visibility is becoming the control plane for MCP security: When every tool is exposed by default, the governance problem is no longer prompt safety alone. Identity teams have to decide which agent personas are entitled to see which capabilities, because visibility itself creates risk. The practical conclusion is that MCP must be governed like any other entitlement surface, not treated as a neutral transport layer.

Context rot is an access-control symptom as much as a model-performance symptom: As the number of exposed tools rises, tool selection becomes less reliable and the agent's operational behaviour becomes less predictable. That means oversharing tools is not only inefficient, it also weakens trust in whether the agent is acting within its intended scope. Practitioners should read tool sprawl as a governance failure, not a tuning issue.

Default-deny is the right starting assumption for production MCP: Open-ended tool catalogs assume that discovery and use can be left broad until something breaks. That assumption no longer holds once agents are tied to production identities, backend secrets, and business workflows. The implication is that teams need persona-scoped tool sets, not universal tool libraries.

Credential isolation and tool routing should be separated: The article shows that backend credentials can be injected or passed through independently of the agent's own identity, which makes the trust boundary explicit. That is important because one access decision should not automatically grant broad tool discovery and backend authority at the same time. Practitioners should design for separate control points rather than a single inherited trust chain.

Named concept: tool visibility debt: Every additional exposed MCP tool creates future governance overhead in review, selection accuracy, and blast radius. The debt accumulates fastest when multiple servers are combined into one agent context. Teams should measure tool exposure as a first-class risk, not an incidental implementation detail.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Tool visibility debt: The more MCP tools an agent can enumerate, the more governance work accumulates around review, selection accuracy, and blast radius. That means teams should measure tool exposure as a security control, not as a cosmetic configuration choice.

Default-deny routing is the cleanest way to stop tool sprawl from turning into privilege sprawl. When one gateway mediates discovery, identity, and backend access, the control boundary becomes auditable instead of implicit.

MCP exposure is already showing signs of secrets and credential leakage pressure across the protocol surface, with 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That scale makes entitlement review and secret isolation operational priorities, not theoretical ones.

For practitioners

• Define persona-scoped tool catalogs Map each agent persona to a minimal tool set and block every unlisted capability at the gateway. Keep the allow list smaller than the backend MCP server catalog so discovery never becomes default access.
• Separate identity validation from tool discovery Require a validated identity token before any MCP endpoint can enumerate tools, then apply consumer-group mapping to decide what that identity can see. This prevents anonymous or loosely authenticated agents from learning the full catalog.
• Isolate backend credentials from agent identities Inject backend tokens at the gateway or pass them only where necessary, so the agent never handles long-lived provider secrets directly. That keeps credential scope independent from the agent's own tool permissions.
• Limit exposed tools per model workflow Split read-only, review, and high-risk workflows into separate routes when one shared route would otherwise surface too many tools. The goal is to keep context size and operational authority aligned with the task.
• Review MCP tool inventories as an entitlement control Add MCP tool lists to access review and platform governance workflows, then retire tools that are no longer used by any production persona. Treat unused tools as dormant privilege rather than harmless clutter.

Key takeaways

• MCP tool exposure turns a convenience feature into an entitlement problem when agents can discover every capability by default.
• As tool catalogs grow, selection quality drops and governance confidence erodes, so security and reliability failures arrive together.
• Default-deny tool filtering, persona-based routing, and credential isolation are the controls that change production MCP from open-ended access to managed access.

Key terms

• MCP Tool Governance: MCP Tool Governance is the set of policies, controls, and review processes used to decide which tools an AI agent may access and how those tools are used. In Model Context Protocol environments, it defines authorization, scope, logging, approval, and revocation so tool calls remain traceable, bounded, and aligned to security and business intent.
• Context rot: Context rot is the loss of investigative focus that happens when an incident agent or analyst is forced to reason across too many logs, traces, and dependencies at once. The result is overconfidence in the wrong clue, which makes approval boundaries and evidence scoping more important than raw model size.
• Default-Deny Access: Default-deny access means no one receives access to a resource unless it is explicitly approved. This model reduces accidental exposure because requestable resources must be granted one by one, usually with an associated policy, duration, and revocation path that defines the permitted use.
• Identity-Aware Routing: A routing model that decides whether traffic may reach a private resource based on the authenticated identity and policy context. In this pattern, the network path is not the trust boundary; entitlement and session policy are, which makes internal access auditable and scoped.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.