An MCP proxy is an intermediary service that sits between an MCP client and one or more MCP servers. It forwards, filters, or rewrites protocol messages, often to enforce policy, logging, authentication, or network isolation around tool and data access.
What an MCP proxy does
An MCP proxy is not just a relay, it is a control point. By sitting between the MCP client and one or more servers, it can enforce policy, shape the request path, and centralise logging so tool and data access is mediated rather than direct.
This matters because the proxy can change the trust boundary of the whole integration. It can block unsafe calls, redact or rewrite messages, and separate client behavior from server exposure, which makes it a common place to add governance around model-driven tool use.
Where an MCP proxy fits in the protocol stack
In practice, a proxy may be deployed as a local shim, a gateway, or a network intermediary. The deployment shape determines what it can actually see and control: some proxies only pass protocol messages, while others also enforce authentication, audience restrictions, or server allowlists.
That placement makes the proxy useful for both connectivity and control. It can sit in front of remote servers, standardize how clients reach them, and reduce direct exposure of backend services, especially where the organisation wants a single inspection point for multiple MCP integrations.
Security functions an MCP proxy commonly provides
An MCP proxy often becomes the practical place to enforce MCP security rules such as token handling, request filtering, and isolation between clients and servers. It may also be used to mediate tool calls, apply per-server policy, and reduce the chance that a client reaches a server it should not trust.
When the proxy is used as a gateway, it can support the same governance concerns covered in the MCP Gateway Buyers Guide and the MCP Gateway and MCP Server Governance Guide, especially around client allowlists, audience-bound tokens, and server approval. A well-designed proxy can also help reduce confused-deputy behavior by keeping the client, the proxy, and the upstream server’s authority more clearly separated.
Common failure modes and design trade-offs
A proxy can improve control, but it can also become a concentration point for trust and failure. If it misroutes messages, over-rewrites protocol content, or logs sensitive material without care, it can create a larger blast radius than the direct client-to-server path it replaced.
There is also a security trade-off between visibility and interception. More inspection can mean better enforcement, but it can also create token exposure, message tampering risk, or availability dependency if the proxy is down or misconfigured. For that reason, proxy behavior should be treated as part of the security architecture, not just a networking convenience.
Risk and Threat Considerations
An MCP proxy can reduce exposure, but it also becomes a valuable target because it sits on a high-trust path. If it is over-permissive, compromised, or incorrectly configured, an attacker can use it to intercept credentials, alter tool requests, or pivot into downstream MCP servers through a trusted control point.
Failure mechanism: The proxy becomes a single place where token passthrough, tool forwarding, or request rewriting can be abused, turning policy enforcement into a control bypass or a data exposure path.
Impact: Compromise or misuse of the proxy can expose sensitive prompts, server responses, secrets, or tool actions, and may let an attacker impersonate legitimate client behavior across multiple servers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP proxies often mediate client and server authentication flows. |
| NHI-05 — Overprivileged NHI | Proxies can concentrate and overextend tool-access privilege across servers. | |
| NHI-10 — Human Use of NHI | Proxy-mediated MCP access can blur human and machine authority boundaries. | |
| Recommendation — Validate proxy-authenticated MCP sessions and prevent insecure token handling. Constrain proxy-mediated access to the minimum server and tool scope required. Separate human requests from machine-mediated tool execution and approval paths. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | An MCP proxy enforces allowed message flows between client and server. |
| IA-5 — Authenticator Management | MCP proxies often handle tokens or other authenticators in transit. | |
| AU-2 — Event Logging | Proxy-mediated MCP traffic benefits from audit logging of tool and policy events. | |
| Recommendation — Enforce message flow restrictions through the MCP proxy boundary. Protect, scope, and rotate authenticators handled by the proxy. Log proxy decisions, denied calls, and rewritten requests for review. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Policy Enforcement Point | A proxy is a classic enforcement point in a Zero Trust path. |
| SC-7 — Boundary Protection | MCP proxies commonly sit at the boundary between client and server trust zones. | |
| Recommendation — Use the proxy as a policy enforcement point with explicit decision logic. Place the proxy at the trust boundary and restrict direct server reachability. | ||
Practitioner Guidance
Why practitioners should care: An MCP proxy is only useful if it preserves protocol integrity while adding real control. The main governance question is whether the proxy is enforcing the rules you intend, or merely adding another service that must itself be trusted and monitored.
What to watch for: Pay close attention to token handling, request rewriting, server allowlisting, and logging scope. If the proxy can see everything but cannot reliably distinguish approved from unapproved tool access, it is probably acting as a visibility layer rather than a control boundary.
Practitioner takeaway: Treat the proxy as an enforcement component with explicit ownership, not as a passive transport helper.