Security teams should centralize MCP tool discovery behind a single gateway, then expose only the tools an agent actually needs at runtime. This reduces catalog noise, limits unnecessary context growth, and makes access policy easier to govern. In Kubernetes, a shared embedding layer and one gateway endpoint can standardize behavior without per-agent configuration or local model sprawl.
Why This Matters for Security Teams
A centralized mcp gateway is not just an architectural convenience. It is the control point that keeps tool discovery, authorization, and auditability from collapsing as the number of servers and agents grows. Without that layer, each agent can accumulate its own tool catalog, local configuration, and implicit trust paths, which quickly turns governance into drift. Current guidance suggests treating tool discovery as a security boundary, not a developer preference. That matters because MCP servers often expose more than teams intend, and NHIMG research on The State of MCP Server Security 2025 found that only 18% of deployments implement any form of access scoping for tool permissions.
For agentic workloads, static IAM assumptions break down fast. Agents do not follow fixed user journeys, and they can chain tools in ways that are hard to predict at design time. That is why security teams increasingly pair centralized discovery with runtime policy evaluation, as reflected in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework. In practice, many security teams encounter tool sprawl only after an agent has already discovered and used an overbroad capability that was never meant to be visible.
How It Works in Practice
The practical pattern is to place a single MCP gateway between agents and every downstream server, then make the gateway the only place where tools are published, filtered, and logged. Agents should query the gateway for discovery, but the gateway should return only the tools that match the agent’s purpose, environment, and current task. That keeps the visible tool surface small even when backend servers are numerous.
Security teams should treat the gateway as a policy enforcement point, not a simple routing proxy. At request time, the gateway can evaluate identity, workload context, ticket metadata, environment, and sensitivity labels before allowing discovery or invocation. This aligns well with runtime decisioning models described in CSA MAESTRO agentic AI threat modeling framework and with the architectural intent of NIST Cybersecurity Framework 2.0. In Kubernetes, a shared embedding layer can standardize how tools are classified and matched, while the gateway publishes a curated catalog rather than the raw server inventory. That keeps context windows smaller, reduces prompt injection exposure, and gives audit teams one record of who saw what, when, and why.
- Use one gateway endpoint for discovery and invocation.
- Classify tools by task, risk, and data sensitivity before exposing them.
- Issue short-lived access tokens per task, not persistent broad access.
- Log both discovery events and tool calls for later review.
- Block direct server access so bypass paths do not undermine policy.
NHIMG’s Top 10 NHI Issues and NHI Lifecycle Management Guide both reinforce the same operational point: discovery must be governed as part of identity lifecycle, not bolted on after deployment. These controls tend to break down when agents can reach MCP servers directly from local plugins or sidecar routes, because the gateway no longer controls the effective tool catalog.
Common Variations and Edge Cases
Tighter centralization often increases latency and operational overhead, requiring organisations to balance governance against developer velocity and resilience. In distributed environments, best practice is evolving rather than settled: there is no universal standard yet for how much tool metadata should be normalized at the gateway versus retained on the server. Some teams keep the gateway thin and enforce policy externally, while others embed richer classification and transformation logic to reduce downstream complexity.
Multi-tenant deployments need extra care. A single gateway can still leak tool visibility if catalog filters are too coarse, especially when different agents share the same namespace or model runtime. That is why runtime context matters more than static role labels. Where agents operate across regulated and unregulated data zones, the gateway should suppress any tool that is not explicitly needed for the current task, and it should revoke discovery rights as soon as the task ends. For deeper context on agent overreach and discovery risk, NHIMG’s OWASP NHI Top 10 is especially relevant, alongside the NIST AI Risk Management Framework. The main exception is highly autonomous agent fleets that must discover tools offline or at the edge, where central control may need to be paired with signed policy bundles and strict cache expiry to avoid stale catalogs.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agentic tool sprawl and runtime misuse map directly to agent control failures. |
| CSA MAESTRO | GOV-02 | MAESTRO emphasizes centralized governance and policy enforcement for agent tool access. |
| NIST AI RMF | GOVERN | AI RMF governance supports accountability, logging, and decision ownership for agents. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Central gateways reduce uncontrolled NHI tool exposure and credential sprawl. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is the core control behind curated MCP discovery. |
Assign ownership for gateway policy, logging, and escalation across the full agent lifecycle.
Related resources from NHI Mgmt Group
- How should security teams govern an AI gateway that brokers LLM traffic, MCP servers, and agents across enterprise environments?
- How should security teams implement AI security posture management across models, agents, and MCP servers?
- How should security teams implement authorization for MCP servers in Python without exposing external credentials?
- How should security teams handle tool discovery for AI agents in MCP environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
