Stop waiting for prompt injection to be fixed

The reassuring version of this story is that every model release closes the gap a little more, and that version has evidence behind it. Anthropic’s measured attack success rate against a browser agent under an adaptive attacker was 1% for Claude Opus 4.5 in November 2025 [4]. One in a hundred is a small number. It is not the number you need, though. What you actually need to know is whether the setup you build around your assistant this month is a temporary workaround you can dismantle next year, or a permanent part of how you work.

The honest answer today is permanent, and the reason is more specific than general pessimism. A paper accepted to ICML 2026 makes a narrow, testable claim about the mechanism underneath prompt injection: a model works out where a piece of text came from by how it sounds, not by the label attached to it [1]. If that is right, better training raises the skill required to attack you without ever removing the opening. This guide is for someone running a business alone or with a few people, who has already connected an assistant to real accounts and wants to know which decisions to make once and stop revisiting. It is not a security review, it is not written for people building agent platforms, and it will not teach you to detect an injection, because OWASP’s own entry says that “given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection” [2].

The model infers who is speaking from how the text sounds

When you talk to Claude, ChatGPT or Gemini, the system prompt, your message, a tool’s output and the model’s own reasoning all arrive as one stream of text with role labels wrapped around the parts. The intuition most people carry is that those labels work the way a database separates a query from the values inside it. They do not. The paper’s authors, Charles Ye, Jasmine Cui and Dylan Hadfield-Menell, state it plainly: models “see the world as a single stream of text, partitioned into roles like <user> or <tool>”, and they “perceive the source of text from how it sounds, not its labeled role” [1].

The evidence is the part worth keeping. The attack they build, CoT Forgery, injects fabricated reasoning into a user message or a tool output so the model reads it as its own thinking. Against agent hijacking defenses it “bypasses these defenses entirely, raising ASRs to 56–70% across all models”, from baselines near zero [1]. Then they took the same forgeries and had an auxiliary model rewrite each one, “preserving semantic content while stripping markers characteristic of the target model’s genuine CoT” [1]. The instruction survived intact; only the voice changed. “Destyling collapses ASR from 61% to 10%, consistent across all models” [1].

Put those two results side by side and the mechanism is hard to miss. Style is carrying the trust decision. That is why the researchers can say that “the degree of role confusion predicts attack success before a single token is generated” [1]. It also explains something you may have noticed without having words for it: a defense trained against a specific class of attack is not learning where text came from, it is learning what one disguise looked like.

A number near zero is a fact about a test set

Security figures in launch material are measured against a benchmark, and a benchmark is a set of attacks somebody wrote down in advance. Anthropic’s own Claude Sonnet 5 system card, dated 30 June 2026, says this out loud. Recent Claude models have nearly saturated its earlier ART prompt injection benchmark, which is why the card introduces a new Gray Swan indirect prompt injection benchmark spanning coding, computer use and tool use tasks [5]. The card reports that Sonnet 5 “demonstrates an improvement over Sonnet 4.6 in agentic safety evaluations, especially in prompt injection robustness” [5].

Saturation is what progress looks like on a fixed test. It is not what progress looks like against people who adapt. The role confusion paper puts the gap in one sentence: “Human red-teamers routinely achieve near-perfect attack success rates against models with extensive safety training” [1].

Google’s Gemini security team measured the same thing from the defender’s side and published it on 18 May 2025. Its report found that “many defenses that perform well on our static evaluation set can be tricked by small and subtle adaptations to an attack”, and that in 16 of 24 cases, across eight defenses and three attacks, the adaptive attack equalled or beat the non-adaptive one [3]. The team’s conclusion was that “enumerating the space of all possible attacks is intractable” and that “no single solution, including adversarial training, offers complete immunity” [3].

So when the next launch post reports a lower number, believe it, and then ask what it is a number about. It is a measurement of how a model performs against attacks that already existed when the test was written. Your assistant will meet attacks written after that.

The people selling this are the ones telling you it is not solved

The clearest guidance available is sitting in vendor documentation, stated by organisations with an obvious commercial reason to say the opposite. Read them as a set.

Anthropic, publishing its browser-use defenses on 24 November 2025, reported the 1% figure and then refused to round it down: “A 1% attack success rate—while a significant improvement—still represents meaningful risk. No browser agent is immune to prompt injection, and we share these findings to demonstrate progress, not to claim the problem is solved” [4]. The same page adds that prompt injection is “far from a solved problem, particularly as models take more real-world actions” [4].

OpenAI, writing on 7 November 2025, calls it what it is: “Prompt injection remains a frontier, challenging research problem” [7]. The company describes Instruction Hierarchy as research “to work towards models distinguishing between instructions that are trusted and untrusted”, which is the right goal and is described as a direction of travel rather than a finished feature [7]. Its closing framing is that “just like traditional scams on the web, we expect our work to be ongoing” [7].

Google’s position is the one quoted above about intractability [3]. OWASP’s is the one about fool-proof prevention being unclear [2]. Four organisations, four separate research programmes, and none of them will tell you this closes.

That consistency is useful to you in a practical way. It means you can stop treating your own configuration as an interim measure. Nobody is going to hand you a version where you can safely wire everything to everything.

The defenses that hold never ask the model to judge

There is a category of defense that does come with a guarantee, and it works by removing the model from the decision entirely. The clearest published example is CaMeL, from a team including Google DeepMind researchers, which extracts the control flow and data flow from your trusted request first, so that “the untrusted data retrieved by the LLM can never impact the program flow” [8]. Permissions are then enforced as capabilities at the moment a tool is called, rather than as instructions the model is meant to respect. On the AgentDojo benchmark, CaMeL solved 77% of tasks with provable security, against 84% for an undefended system [8].

Hold on to both halves of that. A real guarantee exists, and it costs about seven points of capability. That trade is the actual shape of this problem, and it is the same trade you make every time you decline a connector.

You can see the same instinct in shipped products. Anthropic’s write-up of Claude Code auto mode, published 25 March 2026, describes a classifier that reviews each action instead of you. The interesting design choice is what the classifier is allowed to see: assistant explanations and tool outputs are stripped out, so that “only user messages and the executable payload remain” [6]. The judge is protected by never being shown the attacker’s prose. That is a structural fix, not a perceptual one, and it is the pattern to copy at your own scale.

Copying it looks like this. Do not ask an assistant to decide whether a message is trustworthy before acting on it. Decide in advance what it is allowed to do, and enforce that with account scopes, connector settings and approval steps that exist outside the conversation. A read-only credential is a capability boundary. A sentence in your system prompt telling the model to ignore instructions found in documents is a style preference, and style is exactly what the attack forges.

Decide once, at the layer that does not move

The useful exercise is to go through your setup and sort each safeguard into two piles: the ones that assume the model behaves correctly, and the ones that hold if it does not. The second pile is your real security. The first pile is a bonus that gets better over time and should never be load-bearing.

Concretely, the second pile is made of scoped credentials rather than your main login, separate assistants for reading untrusted material and for touching money or customer records, browsing restricted to named sites where the tool offers it, and approval required on the actions you could not undo. In Zapier, n8n or Make, it means the outbound step is a fixed template the model fills in rather than a message the model composes and addresses, because a scenario runs whether or not you are watching. In Cursor or any coding agent, it means treating a repository you did not write as attacker-supplied input, including the README, the issue text and the dependency documentation.

Approval fatigue is the failure mode that quietly moves things from the second pile back into the first. Anthropic reports that users approve 93% of permission prompts in Claude Code, which is the honest reason auto mode exists [6]. The same write-up gives the cost of delegating that judgment: a 17% false-negative rate on real overeager actions, and an explicit warning that auto mode “is not a drop-in replacement for careful human review on high-stakes infrastructure” [6]. Keep the prompts rare enough that you still read them.

Run it with your own numbers. A rate of 1% against five hostile inputs a week averages out to one success roughly every twenty weeks, which is a different sentence from “1% is basically zero”. If your assistant reads inbound email, the exposure number is not five.

What still goes wrong

The largest limit is that none of this is detection. You are reducing what a successful attack can accomplish, not noticing it. A hijacked assistant that can only read will still produce a summary that is subtly wrong, and you will act on it with no log entry and no alert, because from the tool’s point of view nothing unusual happened. Integrity damage is much harder to catch than data theft, and no vendor cited here claims to have solved it.

The second limit is that capability boundaries cost capability, and the honest number for that is in the CaMeL result: 77% of tasks completed with provable security against 84% without [8]. Every configuration you choose below the maximum is a trade you are making deliberately, and you should be able to say what you gave up. If you cannot name the capability you lost, you probably have not actually restricted anything.

The third is that this guide could be wrong about permanence. One ICML paper is a strong empirical result with a provocative claim attached, not a proof of impossibility, and the field will spend the next year trying to break or extend it [1]. If someone builds architectures with genuine role separation, the picture changes and you can loosen things. Until then, the asymmetry favours planning for permanence: a setup built for a flaw that later gets fixed costs you some convenience, and a setup built on a fix that never arrives costs you an account. Watch the vendor security pages rather than the marketing, and change your mind when Anthropic, OpenAI or Google stops writing sentences like the ones quoted above [3][4][7].

Prompts from this guide

model-dependent-assumption-audit

I will describe an AI assistant or automation I have set up. Sort my
safeguards into two piles and tell me which pile each one is in.

Pile A: safeguards that only work if the model behaves correctly or
recognises that something is an attack.
Pile B: safeguards that still hold if the model has been fully
persuaded by hostile text it read.

The setup:
- What it reads, and who can put content in front of it: {inputs}
- What it can do, and with which credential: {actions_and_access}
- Where I have to approve something: {approval_points}
- What I have written in the system prompt or instructions: {instructions}

Then answer three things:
1. The single worst outcome achievable using only Pile B's limits,
   assuming everything in Pile A fails.
2. The one change that would move the most weight from Pile A to
   Pile B, and the capability I would lose by making it.
3. Anything in my description that is doing no security work at all
   and only feels reassuring.

If you need information I did not give you, say what is missing
instead of assuming it.