MCP impersonation happens when a malicious server spoofs a legitimate Model Context Protocol service, harvesting session tokens and sensitive tool outputs from an agent that believes it's talking to something it can trust. The agent doesn't see a red flag. It sees a server that answers like the one it expected.

Why this attack works

MCP was built to let agents discover and call tools across a growing ecosystem of servers, often with minimal friction by design. That same ease of connection is what makes impersonation viable. If an agent's trust in an MCP server is based on little more than a name, an address, or a description it was given, a server that mimics those surface details can insert itself into the interaction without the agent or the user ever noticing the substitution.

Once that substitution happens, everything downstream is compromised by extension. Session tokens the agent would have sent to the legitimate server go to the attacker's instead. Tool outputs the agent trusts as authoritative can be manipulated before they ever reach the user.

The install-to-execution problem, applied to MCP

This is the same install-to-execution trust gap that runs through the rest of agent skill security, applied specifically to external dependencies. A static review at install time can confirm what an MCP server claims to be. It cannot guarantee that the server responding at invocation time, tomorrow or next week, is still the same server, still owned by the same party, or still returning the same kind of output it did during review.

Post-review behavior change is a defining trust failure across the AI supply chain: a previously reviewed reference stays trusted even after its controller or content has changed, which is exactly the mechanism MCP impersonation and server rebinding exploit.

What actually defends against it

Effective mitigation focuses on the protocol layer, not just the endpoint's apparent identity: rigorously validating token audience and issuer rather than trusting them by default, enforcing short-lived credentials so a compromised token has a narrow window of usefulness, and restricting OAuth scopes per tool so a compromised connection can't reach further than the specific capability it was granted.

FAQ

Is MCP impersonation the same as a compromised MCP server? Related but distinct. A compromised server was legitimate and got taken over. An impersonating server was built from the start to mimic a legitimate one's identity, name, or behavior closely enough to be mistaken for it.

Can a client detect impersonation just by checking the server's name or URL? Not reliably. Name and URL similarity is exactly the surface an impersonation attack is designed to exploit. Token audience and issuer validation, not surface-level identity, is what actually confirms a server is who it claims to be.

Does short-lived credentialing fully solve this? It significantly limits the damage window rather than preventing impersonation outright. Combined with strict scope restriction, it means a successful impersonation yields far less than an indefinitely valid, broadly scoped credential would.

Related reading: "Beyond the Code: Tool Poisoning and Agent Goal Hijacking Explained," "Why Static Analysis Alone Can't Catch Malicious Agent Skills"