Topic starter
09/07/2026 3:26 pm
TL;DR: MCP gateways that stop at routing and authentication leave blind spots around identity, intent, and tool sensitivity, according to Linx Security. The central issue is that existing IAM models assume stable principals and visible sessions, while agent tool calls often lack both, making access control theater.
Editorial analysis by NHI Mgmt Group, based on content published by Linx Security: “What We Learned Building an MCP Gateway: It's Not a Routing Problem”.
Key questions
Q: What fails when an MCP gateway only checks routing and authentication?
A: It leaves the organisation unable to evaluate who is really behind the tool call, why the call is happening, and how sensitive the target tool is.
Q: Why do privileged MCP tool calls create more risk than normal API requests?
A: Because the protocol path can hide the human, service, or agent context that normally supports authorisation decisions.
Q: What signs show that an MCP access model is failing in practice?
A: The main signs are hardcoded tool secrets, runtime credential injection that bypasses secrets management, and tool calls that are allowed even when the prompt or mission does not fit the action taken.
Practitioner guidance
- Define MCP gateway policy around identity, intent, and sensitivity Require every tool call to resolve the full principal chain, validate why the call is being made, and classify the tool before execution is allowed.
- Move credential delivery into the gateway path Replace hardcoded tool secrets and direct agent injection with gateway-mediated credential retrieval from the secrets store under the caller's entitlements.
- Scope access with just-in-time issuance Issue time-bound credentials for specific invocations so an agent session does not retain persistent access to downstream systems.
Bottom line: MCP security breaks down when organisations authenticate the client but fail to govern the delegated action behind the call.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 3:45 pm
Identity context, not routing, is the core control plane for MCP. The article describes a delegated-action problem that existing IAM models were not built to solve: the system may know a client connected, but not who truly stands behind the tool call. That matters because the enforcement point has to reason about principal chains, not just sessions. Practitioners should treat MCP as a governance boundary where identity resolution becomes the first control.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: How should teams govern MCP at scale without overexposing tools?
A: Teams should govern MCP as a capability-based control plane, with explicit approval for server provenance, granular scoping for each tool, and monitoring that covers every request and response. The goal is to keep discoverability useful while preventing shared interfaces from becoming shared privilege.
👉 Read our full editorial: MCP gateway security is an identity problem, not routing