The Lethal Trifecta Hiding in Your MCP Server, and How to Defuse It

In May 2025, Invariant Labs demonstrated an attack on the official GitHub MCP server that required no exploit at all. An attacker hid instructions inside a public GitHub issue; the agent read them as data-turned-command, pulled the user's private repo details, and published them in a pull request on the open internet. Every tool behaved exactly as documented — there was nothing to patch.

Simon Willison named this pattern the 'lethal trifecta': access to private data, exposure to untrusted content, and the ability to communicate externally, all present in one session. Any two legs alone are usually safe; combined, they let an attacker who only controls some text you read trigger exfiltration of secrets you hold. MCP's core convenience — bolting on new capabilities in one line of config — makes assembling this trifecta by accident remarkably easy.

The more common and harder-to-audit version isn't a malicious server (tool poisoning, rug pulls) but indirect prompt injection through perfectly honest tools returning ordinary data. Vetting your server list defends against the former and does nothing against the latter. Telling the model in a system prompt to 'ignore instructions in external content' doesn't hold either, since the same model enforcing that rule is the one the attacker is addressing.

The fix has to sit outside the model's reasoning loop: a deterministic broker between the agent and its MCP tools that enforces least-privilege credentials, tracks taint on untrusted data through the session, and gates any outbound call behind an allowlist plus human approval once taint is present. That turns an unsolvable prompting problem into an ordinary, enforceable systems-design problem.