What breaks when MCP traffic bypasses a central proxy?

Why This Matters for Security Teams

When MCP traffic bypasses a central proxy, the organisation loses the control point that makes the protocol governable. That is not a minor routing issue. It removes the place where policy can be checked, sessions can be tied to a specific client, and requests can be logged consistently. The result is a system that may still “work” functionally while becoming far harder to trust, investigate, or constrain.

This matters especially for agentic and tool-using workloads, where a single request can trigger chained actions across data stores, SaaS apps, and internal APIs. NHI Management Group’s research on MCP risk shows how quickly exposure grows when controls are embedded inconsistently: in The State of MCP Server Security 2025, 53% of MCP servers exposed credentials through hard-coded values in configuration files. That kind of weakness becomes far more dangerous when traffic can reach servers outside a controlled mediation path. In practice, many security teams discover this only after a tool has already been overused, a secret has been reused, or an investigation has run out of telemetry.

For current guidance on agentic exposure patterns, OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP Agentic Applications Top 10 both reflect the same operational reality: once the mediation layer disappears, enforcement becomes fragmented and confidence in the audit trail collapses.

How It Works in Practice

A central MCP proxy is the enforcement and observability layer, not just a traffic relay. It is where client identity is validated, tool access is scoped, secrets are mediated, request context is inspected, and logs are written in a way that supports forensics. If MCP traffic bypasses that layer, every downstream control becomes optional or inconsistent. That is why static allowlists and perimeter-only thinking fail here. A direct connection may still carry valid protocol messages, but it does so outside the policy engine that was supposed to interpret intent and constrain blast radius.

In practice, a well-designed proxy performs four jobs. First, it binds each session to a known client or workload identity, rather than trusting whatever endpoint reaches the server. Second, it evaluates policy at request time, which is essential when the same agent may call different tools in different contexts. Third, it enforces short-lived credential use so secrets are not reused across clients or tasks. Fourth, it records the full request path and decision outcome so investigators can reconstruct what happened later. For that reason, implementation guidance increasingly aligns with the OWASP Agentic AI Top 10 and the NHI-centric controls discussed in NHIMG’s Analysis of Claude Code Security.

• Use the proxy as the only approved ingress path for MCP traffic.
• Bind requests to workload identity, not shared user secrets.
• Evaluate policy at runtime with context, tool, and session state.
• Issue JIT credentials per task and revoke them on completion.
• Log both the request and the policy decision for later review.

These controls tend to break down when developers point clients directly at servers to reduce latency or simplify local testing because the bypass path becomes the production path without anyone reintroducing policy controls.

Common Variations and Edge Cases

Tighter proxy enforcement often increases operational overhead, requiring organisations to balance developer convenience against control consistency. That tradeoff is real, especially in fast-moving environments where local experimentation, CI pipelines, and production integrations all use MCP differently.

There is no universal standard for this yet, but current guidance suggests the safest pattern is to treat bypass as an exception that must be explicitly authorised, time-boxed, and monitored. Some teams allow direct MCP access in isolated development sandboxes, provided those endpoints never touch production secrets or production data. Others preserve a proxy for all production traffic but permit direct calls only for ephemeral test tooling. The key is that bypass must not become an invisible normal state.

Edge cases appear when proxying introduces performance concerns, when federated teams run their own servers, or when a vendor-hosted connector cannot be routed through the enterprise mediation layer. In those environments, the question is not whether traffic can bypass the proxy technically, but whether the organisation can still prove who acted, what was accessed, and which policy was applied. Astrix Security’s MCP findings reinforce why that proof matters: once credentials are exposed in configuration and traffic paths are fragmented, compromise becomes much easier to spread.

Related resources from NHI Mgmt Group

• What are MCP Authorization Extensions and how do they help organizations?
• What is MCP in the context of AI security?
• How should teams govern AI agents that use MCP?
• When is it appropriate to implement MCP in the context of AI systems?