The New Prompt Injection Attack Surface: MCP, Tools, and Your Browser

Every developer who has shipped a web app knows the shape of SQL injection. Someone types ' OR 1=1;-- into a login box, your code pastes that string into a query, and suddenly the attacker is reading your database. It was the scariest bug on the internet for years. Then we more or less solved it. Parameterized queries keep the code and the data in separate channels, so user input can never be mistaken for a command. Problem closed.

Prompt injection is the same idea, aimed at LLMs, and it's the reason I keep telling people the AI agent gold rush is running ahead of its own security story. Here's the uncomfortable part. The exploit primitive is weirder than SQLi, and the defenses are worse. There is no prepared statement for a language model. OWASP agrees: it ranks prompt injection (LLM01) as the number one risk in its 2025 Top 10 for LLM Applications, ahead of every other AI-specific threat.^[1]

Why there is no parameterized query for an LLM

The whole reason SQLi got fixed is structural. A prepared statement gives the database two physically separate inputs: here is the query template, and here is the data to fill it. The data can contain any characters it wants and it will never be parsed as code, because it arrives on a different channel. Code and data are separated by construction, not by filtering.

An LLM has exactly one channel. Everything is tokens in the same context window: your system prompt, the user's question, the web page it just fetched, the tool output it just read. The model has no reliable way to know which of those tokens are trusted instructions and which are untrusted data, because to the model they are all just text that predicts the next text. That is the entire vulnerability in one sentence. OWASP puts it plainly, the problem is that LLMs process instructions and untrusted data in the same channel with no reliable separation between them.^[1]

So the defenses are not boundaries, they're probabilities. You train a classifier to spot injection attempts. You wrap untrusted content in delimiters and beg the model to ignore instructions inside them. You add a second model to review the first one's actions. Every one of these is a filter that catches most attacks and misses some, and “misses some” is a very different security posture than “cannot happen.” When the agent on the other side of that filter can read your email or run SQL against production, some is a lot.

The exploit that should scare you: EchoLeak

If you want a single case study for why this matters, it's EchoLeak. Aim Security disclosed it in June 2025 as CVE-2025-32711, and it carried a CVSS score of 9.3, which is about as high as scores get.^[2] It was the first documented zero-click prompt injection to cause real data exfiltration from a production LLM system. Zero-click means the victim does nothing. They don't click a link. They don't open an attachment. An attacker sends one crafted email to someone using Microsoft 365 Copilot, and later, when Copilot reads that email as part of doing its normal job, it quietly leaks the user's sensitive data to the attacker.

What makes EchoLeak a good teaching example is that it wasn't one clever trick, it was a chain of bypasses, each defeating a specific defense Microsoft had already built:^[2]

• It evaded Microsoft's XPIA classifier, the Cross Prompt Injection Attempt detector whose entire job is to catch this.
• It defeated link redaction by using reference-style Markdown, so the exfiltration URL didn't look like the links the redaction was watching for.
• It abused images that the client auto-fetches, turning a rendered image request into a channel to carry data out.
• It routed the stolen data through a Microsoft Teams proxy that the content security policy already trusted, so the exfiltration went to an allowed destination.

Read that list again. Every layer was a real, reasonable defense. Microsoft is not a small shop that forgot to think about security. They built a dedicated injection classifier and a CSP and link redaction, and the attack walked through all of it by composing weaknesses. Microsoft patched it server-side and said there was no exploitation in the wild, which is the good news.^[2] The bad news is the shape: defense-in-depth held for a while, then one researcher found a path that threaded every needle at once.

MCP and the tool-poisoning problem

We wrote about MCP's security problems before, so I won't relitigate the protocol design. The point here is narrower and more general: MCP is just one vector for the same primitive. When you give an agent tools, every tool is a mouth that can speak instructions into the model's context. A tool's description, its parameters, and the data it returns are all text the agent reads. Poison any of that, and you have injected the agent without ever touching the user.

The MCPTox benchmark put real numbers on this. Researchers ran it against 45 live, real-world MCP servers with 353 authentic tools and 1,312 malicious test cases across 20 different LLM agents.^[3] The average tool-poisoning attack success rate was 36.5%. Some models were far worse: o1-mini hit 72.8% and Phi-4 hit 70.2%. More than a third of poisoning attempts succeeded on average, and against the weakest models, closer to three-quarters.

Two findings from that paper deserve to be tattooed somewhere. First, more capable models were often more vulnerable, not less, because tool poisoning exploits exactly the thing we train frontier models to be good at: following instructions carefully.^[3] The smarter the intern, the more reliably it does what the poisoned note says. Second, agents almost never refused. The highest refusal rate in the whole study, from Claude-3.7-Sonnet, was under 3%.^[3]The models don't sit there suspicious of a malicious tool. They read it and comply.

There's a real-world version of this that reads like a security parable. In mid-2025, Supabase's Cursor agent was running with privileged service-role database access and processing support tickets that contained user-supplied text.^[4]Attackers embedded SQL instructions inside a support ticket. The agent read the ticket, treated the embedded text as a command, and executed it, reading and exfiltrating sensitive integration tokens. Notice the loop closing: this is literally SQL injection again, except the injection point isn't a query builder, it's a language model that was helpfully being an agent. The old wound, reopened one abstraction layer up.

Your browser is the biggest attack surface of all

Now put an agent in a browser and let it act with your logged-in session. This is the part that keeps me up at night, because a browser agent by design runs with your full authenticated privileges. It is you, as far as every website you're signed into is concerned. Same-origin policy and CORS, the two rules that normally stop one site from reading another, don't help, because the agent isn't a hostile site, it's your own trusted browser doing what it was told.

Brave's security team documented this on Perplexity's Comet browser, twice. In the first disclosure, on August 20, 2025, they showed that asking Comet to summarize a malicious Reddit post let instructions embedded in that post read the victim's email and a one-time password, then take over their account.^[5] The user asked for a summary. The page contained a command. The agent, running as the user, obeyed it and reached into a different origin entirely, because to the agent there are no origins, just tabs it can drive.

The second disclosure, on October 21, 2025, is even more unsettling. Brave found that nearly invisible malicious text embedded inside a screenshot, the kind you'd ask the assistant to analyze, got executed as commands rather than treated as untrusted image content.^[6] Text you literally cannot see, riding inside an image, becomes an instruction. And Brave was explicit that this is not a Comet-specific bug. It affects the entire category of AI-powered browsers.^[6]The surface isn't one product. It's the whole idea.

So how good are the defenses, really

Here's where I'll give the defenders their due, because the numbers are genuinely improving, and then I'll tell you why that's still not a fix. Anthropic red-teamed Claude for Chrome with 123 test cases across 29 attack scenarios. With no safety mitigations, autonomous browser use had a 23.6% attack success rate. With mitigations added, that dropped to 11.2%.^[7] In a November 24, 2025 follow-up that gave an adaptive attacker 100 attempts per environment, they drove the browser-use success rate down to about 1%.^[8]

One percent is a big win over 23.6%. But Anthropic themselves called that residual 1% a meaningful risk, and said plainly that no browser agent is immune to prompt injection.^[8]I appreciate that honesty, because a 1% success rate against an agent that can move your money is not the same category of thing as a bug that's been eliminated. Run any agent enough times against enough hostile content and 1% is a certainty, not a maybe.

The AgentDojo benchmark makes the other key point, which is that your risk depends enormously on what the agent can reach. Targeted attacks succeed against the best agents under 25% of the time overall, but the domain variance is wild: roughly 53.7% in Banking and 36.4% in Slack versus 17.3% in Travel and 11.1% in Workspace.^[9] Same models, same attacks, wildly different outcomes based purely on the tools available. Adding a secondary attack-detector defense dropped the rate to around 8%.^[9] Better, still not zero.

The lesson I take from every one of these numbers is the same. Filters and detectors move the success rate down by an order of magnitude, which is real and worth doing. They do not move it to zero, and they can't, because the underlying channel confusion is still there. So the defense that actually changes your exposure isn't a better classifier. It's limiting what the agent can touch, so that even a successful injection has nowhere valuable to go.

What this means if you're building with agents

I'm not in the “don't use agents” camp. The leverage is real, and this is where a lot of software is going. But I'd build with a specific mental model: assume any content your agent reads may contain instructions, and assume your filters will occasionally miss. Then make that assumption survivable.

• Least privilege is the whole game. The Supabase incident happened because the agent held service-role access while reading untrusted tickets. AgentDojo shows Banking-level tools are where the damage is. Scope agent credentials down hard, and never let one agent both read untrusted content and hold powerful, sensitive permissions at the same time.
• Separate the reader from the actor.An agent that summarizes hostile web pages should not be the same agent, with the same session, that can move money or send email. EchoLeak and the Comet exploits both chained “read something” into “exfiltrate something” through a trusted path. Break that chain.
• Watch the exfiltration paths, not just the input. EchoLeak got out through an allowed Teams proxy and auto-fetched images. Injection prevention is porous, so also constrain where data can go: lock down outbound destinations and be suspicious of anything that auto-fetches a URL an attacker can influence.
• Add the second reviewer, but don't trust it alone. A secondary detector took AgentDojo to roughly 8% and Anthropic's layered defenses reached about 1%. Use them. Just size your blast radius for the case where they fail, because at scale they will.

Zoom out and the trend line is not comforting. Google's Threat Intelligence Group scanned Common Crawl snapshots of the public web using Gemini plus human review and found a 32% relative increase in malicious indirect prompt injection content between November 2025 and February 2026.^[10]The web is being seeded with payloads aimed at the agents we're all rushing to deploy. The attackers understand the primitive perfectly well.

The way I think about it: we spent twenty years learning to never trust user input, and we built clean structural boundaries to enforce it. LLMs erased the boundary. Until someone invents the prepared statement of language models, and I'm not convinced that's even possible in the current architecture, the only durable defense is to assume the agent will get fooled and make sure it can't do much damage when it does. Build like the injection already happened. Because statistically, given enough runs, it will.