What is Man-in-the-Middle (MCP)?
A man-in-the-middle (MITM) attack on MCP intercepts and potentially modifies protocol traffic between client and server. This is relevant when using network transports like SSE or HTTP rather than stdio.
WHY IT MATTERS
MCP supports multiple transport mechanisms. Stdio transport runs the server as a local child process with communication over standard input/output — inherently resistant to network-level MITM because no network is involved. But SSE (Server-Sent Events) and HTTP transports send MCP messages over the network, exposing them to the same MITM risks as any network protocol.
An attacker positioned between the MCP client and server (through ARP spoofing, DNS poisoning, compromised network infrastructure, or a rogue Wi-Fi access point) can observe every tool call and response. This reveals tool names, arguments (including credentials and sensitive data), and server responses — complete visibility into the agent's operations.
Active MITM goes further. The attacker can modify tool calls in transit (changing parameters, redirecting operations), alter server responses (poisoning the agent's context), inject additional tool calls (triggering operations the agent didn't request), or block specific calls (selectively denying operations).
The risk is especially acute in remote MCP server deployments where the server runs on a different machine, in a cloud environment, or across the internet. Without transport-layer encryption and server authentication, every tool call is exposed.
HOW POLICYLAYER USES THIS
Intercept mitigates MITM risk by acting as a local proxy — the MCP client connects to Intercept over stdio (immune to network MITM), and Intercept manages the network connection to remote servers with proper TLS verification. YAML policies can enforce that all remote server connections use encrypted transports, and the audit trail provides a tamper-evident record of all tool calls that can be compared against server logs to detect modification.