Use a gateway to filter the manifest centrally, so the agent sees only the tools allowed for that role and session. This is the cleanest option when server sprawl already exists, because it changes the exposed surface without forcing every upstream team to redesign its server.
How gateway control changes MCP exposure
When mcp server are already proliferating, the practical control point is the manifest, not each upstream implementation. A gateway can present a filtered tool catalog per role and session, so the agent only learns about tools it is allowed to invoke. That reduces exposure without forcing every server team to redesign its own interface or authorization logic.
The key benefit is that control moves from “every server must be perfect” to “the exposed surface is consistently mediated.” That matters because tool exposure is often the first thing that becomes inconsistent across teams, environments, and deployments. A central gateway can also enforce a common policy for newly added servers before they are visible to agents.
What the gateway must actually enforce
A useful gateway does more than hide tool names. It should filter the manifest, bind exposure to the active user or agent context, and ensure the tool set changes when role, task, or session changes. If the gateway only proxies requests after the agent has already discovered every tool, you still have an exposure problem, even if later calls are blocked.
Good practice is to treat the manifest as a controlled advertisement surface. The agent should see only the minimum tool set needed for the current workflow, and the gateway should prevent direct discovery of unsupported or higher-risk operations. This is especially important where one MCP server exposes both low-risk utility functions and sensitive administrative actions.
Model Context Protocol: Authorization specification helps define how the gateway should behave when MCP servers are treated as protected resources, rather than as open tool registries.
AI Agent Tool and Plugin Security Guide
When central filtering is the right compromise
Central filtering is usually the right compromise when the organisation has multiple servers, uneven implementation quality, or no realistic path to reworking every upstream team immediately. It gives you a single place to enforce scope, review changes, and retire risky tools from exposure while the underlying services stay intact.
It is less suitable when the gateway becomes a passive routing layer with no policy authority. In that case, you have only added another hop, not reduced risk. The control works best when it owns tool visibility, not just transport.
AI Agent Identity Security: The 2026 Deployment Guide
OWASP API Security Top 10 is relevant where the gateway must also prevent overexposure of backend actions that would otherwise become API-style abuse paths.
Risk and Threat Considerations
Without central control, MCP sprawl creates a broad attack surface for tool discovery, overbroad access, and accidental exposure of administrative or data-retrieval functions. The main threat is not only malicious use, but also agent misuse once too many tools are visible and eligible for invocation.
Failure mechanism: If exposure is managed per server, teams will drift in policy, naming, and scope, so the agent can still enumerate or invoke tools that exceed the intended role or session. A gateway that filters the manifest centrally breaks that pattern by making visibility and invocation depend on one enforced policy layer.
Impact: Reduced tool visibility lowers the chance of accidental overreach, prompt-influenced misuse, and lateral movement through overly powerful functions. It also gives security teams a practical choke point for deprovisioning risky tools when server sprawl has already outpaced governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Tool exposure is governed by agent role and session scope. |
| Recommendation — Limit visible tools to the minimum role-scoped set. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Gateway filtering prevents agents from reaching functions beyond allowed scope. |
| Recommendation — Enforce function-level authorization at the gateway before tool exposure. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The gateway must enforce who can see and invoke each tool. |
| IA-5 — Authenticator Management | Session-bound exposure depends on controlled credentials and token handling. | |
| AC-6 — Least Privilege | Only the minimum tool set should be exposed for each role and session. | |
| Recommendation — Apply access enforcement to filter tool visibility and invocation. Manage credentials so gateway decisions remain bound to current session context. Expose only the minimum tool set required for each role and session. | ||
Practitioner Guidance
What to prioritise: Put the gateway in front of tool discovery first, not just tool execution. If the agent can still list everything, the control is incomplete even if invocation is later checked.
What to verify: Confirm that the manifest differs by role, session, and environment, and that newly registered tools are hidden until they are explicitly approved for exposure.
Practitioner takeaway: The most effective retrofit control is a policy-enforcing gateway that reduces what the agent can see, because visibility is often the real source of unnecessary MCP risk.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- How do organisations decide whether to use tool filtering before execution or rely on the model to pick the right MCP server?
- Why do MCP servers change the way organisations think about access control and data exposure?
- How should organisations control PII exposure in GenAI applications without creating excessive latency or operational friction?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org