The 93% Problem: When Your AI Detects Attacks but Doesn't Clean Them Up A practical look at stored injection in MCPs and Agents, with the receipts.
by Blessed UyoAbstract Prompt injection just grew a stored variant. A University of Washington study this year found something worse than models acting on malicious instructions: whether a model acts on a poisoned memory is uncorrelated with whether it cleans it up. Their strongest model had the lowest attack-success rate and the highest persistence — it detected the injection, refused it, asked the user to delete it, and left it in the file 93% of the time. Your safest model becomes a delivery mechanism for your weakest one. This is a practical, evidence-first talk. From real testing of production MCP servers and AI agents. SQL injection and stored XSS reaching live backends through tool-call arguments, cross-tenant reach by chaining "safe" tools, memory injections accepted because they're dressed as a user preference. I'll show the gap between "detected" and "removed" is not hypothetical. Then the receipts: a production dashboard where 25 of 25 critical alerts sit unactioned and 77,000+ incidents stay open, while the only things cleaned up were the ones that didn't matter. The second half is what to do about it: snapshot the surface your agents can write to, diff it after every session, and treat "detected but not removed" as its own failure mode plus the deterministic rails (a signed-token check that stopped 178 of 178 write attempts; an interlock that blocked 58 of 58 destructive commands) that work because they don't rely on the model's judgment. The autonomy is theirs; the blast radius is yours. What you'll leave with - A new attack class: stored injection in your agents and MCP tools, and how to spot your own exposure. - Why your strongest model can make it worse, with production data. - A defense you can ship Monday: snapshot, diff, and fail the run on "detected but not removed."