What is Dependency Confusion (MCP)?

Dependency confusion exploits the gap between a name and what it resolves to. In traditional software, attackers publish malicious packages with the same name as internal libraries to public registries — the build system fetches the attacker's version instead. The same class of attack applies to MCP server resolution.

When an MCP client configuration references a server by name, the resolution process determines which binary, container, or endpoint actually handles traffic. If an attacker publishes a malicious MCP server package with the same name as a legitimate internal one — or a near-identical typosquatted name — agents may connect to the wrong server entirely. Every tool call then goes to an attacker-controlled endpoint.

The consequences are severe: the malicious server can return poisoned data, capture sensitive arguments (credentials, file paths, database queries), or manipulate tool responses to steer agent behaviour. Unlike traditional dependency confusion where the damage is at build time, MCP dependency confusion is at runtime — every agent session is compromised.

This is particularly dangerous because MCP server configurations are often shared across teams via config files, dotfiles, or documentation. A single poisoned server reference propagates to every developer who copies the configuration.

Intercept mitigates dependency confusion by acting as the single enforcement point between client and server. Because all MCP traffic routes through Intercept, policies can pin specific server identifiers, restrict which servers are permitted, and enforce allowlists of known-good MCP server endpoints. Even if an agent's configuration is manipulated to reference a malicious server, Intercept's policy denies connections to any server not explicitly listed. The audit trail also surfaces unexpected server connections for investigation.