MCP tool access control is becoming the new AI gateway priority

At a glance

What this is: This is a technical analysis of why MCP tool exposure becomes a security and performance problem in production and how AI gateways can enforce tool-level access control.

Why it matters: It matters because IAM teams now have to govern tool entitlement, credential boundaries, and agent access patterns as part of NHI and agentic AI security, not just traditional API access.

By the numbers:

• 91% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Kong's analysis of MCP tool access control for AI gateways

Context

MCP security is really a tool entitlement problem. When an AI agent can see every tool on an MCP server by default, the issue is no longer just whether the agent is authenticated, but whether its runtime access is constrained to the minimum set of actions it actually needs.

That makes MCP governance a practical identity problem for NHI and agentic AI programmes. The same controls IAM teams already use for access scoping, credential isolation, and least privilege now need to extend to tool discovery, tool execution, and gateway-level enforcement across multiple backend systems.

Key questions

Q: How should security teams restrict MCP tool access in production?

A: Security teams should enforce tool-level authorization at the gateway, not at the model. The safest pattern is default-deny access, explicit allow lists per agent persona, and identity-based routing from a trusted IdP claim. That keeps unneeded tools out of the agent's context and limits the blast radius of misuse.

Q: Why do large MCP tool catalogs create security and reliability risk?

A: Large MCP tool catalogs expand both privilege and prompt size. The more tools an agent can see, the more chances there are for it to select the wrong one, infer an unsafe action, or call a capability it should not have. That makes tool sprawl an access-control problem and a model-performance problem at the same time.

Q: What is the difference between gateway-managed credentials and agent-held credentials?

A: Gateway-managed credentials stay outside the agent and are injected only when needed for backend access. Agent-held credentials travel with the agent and can be reused, copied, or exposed if the runtime is compromised. For production MCP, gateway-managed secrets give the security team a cleaner audit and revocation boundary.

Q: How can teams tell whether MCP governance is actually working?

A: MCP governance is working when agents only see the tools their role requires, backend secrets never appear in the agent runtime, and access changes can be traced through identity claims and gateway policy. If every agent sees the same tools or privileges are managed manually, governance is still too loose.

Technical breakdown

Why default tool exposure creates over-permissioned AI agents

MCP servers often expose the full tool catalog to any connected agent unless a gateway or policy layer intervenes. That design is convenient for prototyping, but in production it creates a broad authorization surface because the agent can reason over capabilities it should never reach. The problem is not only excess privilege. Large tool catalogs also increase context size, which makes tool selection less reliable as prompts grow. In practice, security and model performance fail together: more tools mean more possible misuse and more room for wrong-tool execution.

Practical implication: treat tool visibility as an entitlement boundary and restrict tool lists before they enter the model context.

How gateway-managed credentials separate agent identity from backend secrets

A gateway can inject backend credentials while withholding them from the agent, which changes the trust model materially. The agent authenticates to the gateway, while the gateway handles downstream secret presentation to the MCP server or API. That separation matters because it prevents agent-side leakage of long-lived tokens and gives the security team a single control point for logging, rotation, and revocation. In effect, the gateway becomes the identity broker for tool access rather than letting each agent carry its own backend privilege.

Practical implication: terminate backend secrets at the gateway so agent sessions do not inherit reusable credentials.

Why consumer groups and ACLs are the right control model for MCP

Consumer groups let teams apply tool ACLs to classes of agents instead of managing permissions one consumer at a time. When mapped from an identity provider claim, the gateway can decide which tools a given agent persona may see and use. That is important because agent populations tend to multiply quickly, and manual per-agent rules become fragile. A default-deny ACL model also aligns with classic zero trust thinking: the backend server should not be the place where privilege is narrowed after exposure. It should be narrowed before tool discovery.

Practical implication: define agent personas centrally and enforce default-deny ACLs at the gateway edge.

Threat narrative

Attacker objective: The objective is to make the agent reach or misuse tools that were never intended for its role, expanding blast radius and increasing the chance of unintended data or system changes.

1. Entry occurs when an AI agent connects to an MCP server and inherits the server's full tool catalog, creating broad initial capability exposure.
2. Escalation happens when over-permissioned tools and large context windows make the agent more likely to select or invoke actions it should not use.
3. Impact follows when privileged tools such as repository modification, issue creation, or secret-bearing workflows are reachable without a separate authorization boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool visibility is the new entitlement boundary for MCP. Traditional API security assumes the server enforces privilege after a request is made, but MCP changes the problem because tools are exposed into the agent's decision space before use. That means excess privilege is not just an authorization issue, it is a model-behaviour issue. The practical conclusion is that tool catalogs must be treated like sensitive capability inventories, not harmless metadata.

Context rot is a governance problem, not only a model-quality problem. As tool count rises, selection reliability degrades and the wrong action becomes more likely even when the agent is behaving as designed. That makes tool sprawl a control failure because the security team loses predictability over which capability the agent will choose. IAM and platform teams should view large MCP tool sets as a signal that authorization is being stretched past operational usefulness.

Default-deny ACLs fit MCP better than post-hoc monitoring. Once an agent has seen a tool, the governance problem has already moved into runtime reasoning. Filtering at the gateway keeps unavailable tools out of the prompt and out of the action path. That is the only point where security can reduce both exposure and model confusion at the same time.

Credential isolation and tool ACLs should be governed as one control plane. If the gateway injects secrets but does not restrict tool access, it simply concentrates risk in a different place. If it restricts tools but leaves credentials in the agent, leakage still defeats the model. NHIMG's position is that MCP governance only holds when backend secrets and tool entitlements are controlled together, with the gateway acting as the policy choke point.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader governance lens, read OWASP Agentic Applications Top 10 for the runtime risks that make gateway policy enforcement necessary.

What this signals

Tool ACLs are becoming a first-class identity control for agentic platforms. The practical shift here is that access governance no longer stops at API authorization, because the model also needs a constrained view of available capabilities. Teams that already manage IAM, PAM, and NHI policy should expect MCP gateways to become part of the same control plane, especially where multiple agents share infrastructure and backend services.

Agent sprawl will force security teams to govern tool catalogs the same way they govern secrets. The larger the visible tool set, the harder it becomes to justify trust in any single agent persona. That is why default-deny exposure and claims-based access mapping are likely to become baseline design expectations rather than advanced hardening.

The governance question is no longer whether an agent can authenticate. It is whether the authenticated agent can discover more capability than its role can safely support, which is where the next generation of identity policy will be judged.

For practitioners

• Inventory every MCP tool exposed to production agents Map which tools each agent can currently discover, not just which ones it is expected to use. Then classify tools into read-only, write, and high-impact actions so policy decisions can be made on exposure, not on intention alone.
• Enforce default-deny tool filtering at the gateway Block any tool that is not explicitly allowed for the agent persona or consumer group. This prevents unnecessary capability disclosure and keeps the model from reasoning over actions it should never be able to call.
• Separate backend secrets from agent identity Use gateway-managed credential injection so agents do not hold reusable backend tokens. That makes revocation, rotation, and audit centralized and reduces the chance that a compromised agent session can reuse a secret elsewhere.
• Bind agent personas to identity provider claims Map JWT or OIDC claims to consumer groups so access follows the authenticated identity rather than a static endpoint or ad hoc configuration. That gives security teams one place to change permissions when a role changes.

Key takeaways

• MCP creates a governance gap when agents can discover every backend tool by default.
• Gateway-level ACLs and credential isolation reduce both misuse risk and context-window degradation.
• Production AI agent governance now depends on constraining tool visibility before execution begins.

Key terms

• MCP Gateway: A gateway that sits between AI agents and MCP servers to control which tools are exposed, which credentials are used, and how requests are logged. In practice, it becomes the enforcement point for tool-level authorization instead of leaving access decisions to the backend server alone.
• Tool ACL: A tool access control list defines which agent personas or identity groups can see and invoke specific MCP tools. It is the mechanism that turns a broad tool catalog into a role-aware permission model, reducing unnecessary exposure and limiting the actions available to each runtime identity.
• Context Rot: Context rot is the decline in model reliability as more tools, instructions, or tokens are loaded into the prompt. For agentic systems, it can cause wrong-tool selection, hallucinated parameters, and poor execution even when the underlying credentials and APIs are otherwise valid.
• Consumer Group: A consumer group is a set of identities managed together for policy enforcement. In an MCP environment, it lets teams assign tool access to classes of agents rather than to each agent individually, which makes access control more scalable and easier to govern across changing workloads.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Model Context Protocol (MCP) Security: How to Restrict Tool Access Using AI Gateways. Read the original.