Why do direct MCP client connections create more risk than proxied access?

Why proxied MCP access is easier to govern than direct client-to-server connections

Proxied access gives you one control point for authentication, policy enforcement, and inspection. That matters because MCP clients often talk to multiple remote servers, and each extra hop or server makes it harder to maintain a consistent rule set. With a proxy, the organisation can centralise how requests are mediated, logged, and constrained.

That central point also reduces the chance that teams bypass security controls in different ways for different servers. A direct model can be workable, but it tends to spread trust decisions across clients and endpoints, which makes governance harder to standardise.

For MCP specifically, that distinction is important because the protocol is tightly tied to tool invocation and delegated access. NHIMG’s MCP Security Guide covers the authorisation model, token handling, and gateway patterns that become much simpler to manage when access is mediated.

What visibility and audit losses direct connections create

Direct connections reduce the organisation’s ability to see which tool was called, which request path was used, and which identity authorised the action. When every client can speak directly to many remote servers, audit logging becomes fragmented, and investigations depend on the quality of each server’s logs rather than one consistent control plane.

That fragmentation is not just a reporting problem. It weakens the ability to correlate user intent with tool execution, compare behaviour across servers, and confirm whether a session was properly scoped. A proxy can preserve a single audit trail and make anomalies easier to spot.

Where the system is using standards-based machine authentication, the underlying trust model also benefits from central mediation. The MCP authorization specification and OAuth 2.0 both assume explicit control over token audience and authorisation flow, which is much easier to validate when requests are routed through a gateway.

NHIMG’s NHI Authentication Guide is also relevant because it explains how machine-to-machine authentication choices affect containment, token scope, and auditability across service and agent access paths.

Why direct paths increase compromise and blast-radius risk

When a client connects directly, any leaked credential, overbroad token, or weak client configuration can be used against multiple downstream servers with fewer interception points. That enlarges blast radius because the client effectively becomes the enforcement boundary, and the boundary is often the least observable part of the workflow.

Direct access also makes it easier for a compromised client or malicious tool response to move laterally across remote targets without first passing through a gateway that can apply consistent allowlists, audience checks, or session constraints. The result is not only more exposure, but a weaker ability to prove that the right identity was authorised for the right action at the right time.

For practitioners evaluating the threat path, the relevant control question is whether each server is trusted to enforce the same authorisation and logging rules. If the answer is no, direct access creates a trust gap that a proxy can narrow by concentrating those decisions in one place.

Risk and Threat Considerations

Direct MCP connections create a larger attack surface because the client becomes responsible for identity, routing, and request discipline across many remote servers. If a token is overprivileged, intercepted, or replayed, an attacker may gain broad tool access without first defeating a central enforcement point.

Failure mechanism: The weak point is usually inconsistent token scope, poor session binding, or server-by-server logging that cannot reconstruct the full tool call chain. A compromised client, stolen credential, or misconfigured remote server can then turn a single access path into repeated unauthorised actions.

Impact: The practical consequence is reduced traceability, harder containment, and wider blast radius when something goes wrong. Incident responders may be able to see that a server was used, but not reliably prove which identity authorised the action or whether the request should have been allowed at all.

Practitioner Guidance

What to prioritise: Put a proxy or gateway in front of remote MCP servers when the environment has more than a small number of tools, identities, or tenants. The proxy should be the place where audience restriction, session scoping, and logging expectations are enforced consistently.

What to verify: Confirm that the control point can preserve a complete audit trail from caller identity to tool invocation, and that you can revoke or narrow access without reconfiguring every downstream server. If you cannot answer those two questions quickly, the direct model is too loose for production use.

Practitioner takeaway: Direct access is not risky merely because it is “less centralised”, it is risky because it makes policy, identity, and evidence harder to keep aligned as the number of servers grows.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Why do direct MCP connections create compliance risk?
• Why does direct AI access to enterprise security systems create more risk than an MCP-mediated approach?
• Why do raw MCP connections create more risk when an agent needs access to several developer tools?