Notifications
Clear all
Topic starter
24/06/2026 8:06 pm
TL;DR: MCP servers commonly expose every tool by default, which creates both over-permissioned AI agents and context rot that degrades tool selection accuracy, according to Kong. The governance lesson is that production MCP needs default-deny tool filtering, identity-based routing, and credential isolation, not just prompt-injection defenses.
NHIMG editorial — based on content published by Kong: Model Context Protocol (MCP) Security: How to Restrict Tool Access Using AI Gateways
By the numbers:
- 91% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
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.
Q: Why do large MCP tool catalogs create security and reliability risk?
A: Large MCP tool catalogs expand both privilege and prompt size.
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.
Practitioner guidance
- 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.
- Enforce default-deny tool filtering at the gateway Block any tool that is not explicitly allowed for the agent persona or consumer group.
- Separate backend secrets from agent identity Use gateway-managed credential injection so agents do not hold reusable backend tokens.
What's in the full article
Kong's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Kong ai-mcp-proxy configuration examples for gateway-managed credentials and ACL enforcement
- Declarative YAML patterns for consumer groups, routes, and tool allow lists across multiple MCP backends
- Concrete GitHub MCP persona setups showing which tools are exposed to each agent class
- Implementation notes on claim mapping, default deny, and hybrid authentication modes
👉 Read Kong's analysis of MCP tool access control for AI gateways →
MCP tool exposure in production: are your controls keeping up?
Explore further
25/06/2026 5:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP tool access control is becoming the new AI gateway priority
