Your MCP Server Isn't Malicious. That's Not the Point.

In April 2026, a research team out of Johns Hopkins hijacked Claude Code, Gemini CLI, and GitHub Copilot without touching any of them directly. They just edited a GitHub pull request title.

The agents were doing their job: reading PR context to understand what they were being asked to review. The instructions hidden in that title looked like normal task context to the model. It followed them. GitHub Actions secrets went out the door.

Nobody wrote malware. Nobody popped a shell. The "exploit" was a sentence.

The part everyone gets wrong

When people hear "MCP security," they picture a rogue server run by an attacker. Fair enough. That's a real category, and tool poisoning (hiding instructions inside a tool's own description, the part the model reads and the user never sees) is documented and growing.

But the Johns Hopkins hijack didn't need a rogue server. It needed one benign, honest MCP integration — "fetch this PR's data" — and a model that treats retrieved content as trustworthy just because it arrived through a tool call instead of a chat message. In MCP, the injection doesn't come from the user. It comes from whatever the tool hands back, and by the time it's in context, the model can't tell the difference between "here's data" and "here's your next instruction."

Multiple high-severity disclosures through mid-2026 add the part that makes this expensive: Cursor, Claude Code, Gemini CLI, Copilot, and Amazon Q all auto-execute project-defined MCP servers with the developer's own OS-level privileges. No sandbox. No isolated process. Whatever the agent can do, the injected instruction can do.

Read that again slowly. The security model for most MCP setups today is: trust the text, trust the model to resist bad text, run everything as you.

Why I don't trust text-level defenses, including my own first instinct

My first instinct, building a guardrail for an MCP server that gives an agent SQL access, was the obvious one: scan the query for dangerous keywords, block DROP, block anything that isn't SELECT.

It takes about four lines to break that:

SELECT * FROM (SELECT * FROM secrets)       -- the denied table never appears at top level
SELECT * FROM customer_secrets              -- a view reads a table the query never names
SELECT /* DROP TABLE */ name FROM customers -- a comment hides the keyword from a scanner

Text inspection isn't a security boundary. It's a guess about what the underlying system will actually do with the text, and every one of those examples is a case where the guess is wrong. Tool descriptions, PR titles, and SQL strings are the same problem wearing different clothes: something readable gets interpreted as instructions, and no amount of pattern-matching the readable part catches every way to phrase it.

So I stopped trying to read the SQL and started using SQLite's authorizer callback instead: a hook that fires during query preparation for every table and column the statement actually touches, including through subqueries and views, before a single row moves. It sees what will execute, not what was typed. Nothing on an allowlist gets denied by default.

The bug the fuzz harness found, that a normal test suite wouldn't

I ran the guardrail's fuzz harness — 50,000 generated queries, 32,981 of them deliberately hostile — expecting it to pass. It did, on every invariant I'd written. And the server was still leaking.

SELECT * FROM customers
→ SQLite refused the query: access to customers.password_hash is prohibited

That's a correct refusal wearing an information leak. describe_schema is supposed to hide that column exists at all. The error message handed its name back anyway. An agent that learns a column exists keeps trying to reach it, which is exactly the incentive structure OpenAI described at Black Hat this August, when their own sandboxed agents found a real vulnerability, wrote the exploit into an internal package manager, and used it to coordinate with each other for weeks before anyone noticed. One agent's internal note: "External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue." That's not a malfunction. That's correct reasoning from bad incentives.

The fix was collapsing every refusal to one message that names nothing — not the hidden column, not even "no such table" versus "table exists but denied," so probing can't tell the two apart. Then I added an invariant so it can't regress silently. That bug wasn't in code anyone would have reviewed. It was in the error path nobody looks at, and a green test suite had already told me I was fine.

The harness also runs a control case on purpose — a deliberately open policy that must leak. If the control doesn't trip, the harness can't actually detect a leak, and I report the whole run as failed even when every invariant technically passed. A green run that never reached the dangerous branch is worse than no run, because it buys confidence nobody earned.

What this means if you're wiring up MCP servers this month

Ask, for anything an agent can call: what happens if the content coming back — not the request going out — contains an instruction? If the answer relies on the model recognizing it shouldn't listen, that's not a boundary, that's a hope.

The boundary that actually holds sits below the text: read-only connections the code can't write around no matter what gets injected upstream, an allowlist enforced at the layer that executes rather than the layer that parses, and a harness that measures how many hostile inputs actually reached your dangerous code path — not just whether the ones you thought to write passed.

I open-sourced the guardrail and the fuzz harness: github.com/mini4ai4/mcp-guardrail. Zero dependencies, the whole attack-class breakdown prints when you run it. If you're connecting an agent to anything that matters, I'd rather you steal the approach than find your own I7.