Data Report · By Chris Sowa · Published
Last updated
Will Prompt Injection Ever Be Fixed at the Model Level?
Not on any date a buyer can plan for: the benchmarks reviewed here find current defenses only partly effective, and the vendors that explain their reasoning describe layers of control rather than a model that cannot be fooled. Ask a vendor for a measured failure rate, then for what the model still receives when a defense fails.

The question is worth separating from the one beside it. A model can be made harder to fool, and measurements show that it has been; whether training can ever end instruction smuggling is a different claim, because a language model receives its instructions and the content it acts on through the same channel of text. Every account reviewed here says the same thing in different words: the attacks keep moving, the defenses are layered, and no layer is described as complete. What follows is a research summary rather than a forecast. It asks what a fix would have to cover, what the benchmarks measure, what the vendors document instead, where the controls that work sit, and what changes when the model reads a token. Does a Smarter Model Stop Prompt Injection? tests whether capability moves the rate, and How Does Prompt Injection Get Into a Coding Agent? traces how an instruction arrives. The scope note matters: a governed environment of the kind described at the end covers the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP.
Key findings
- The agent benchmark reviewed here reports that its results "reveal critical vulnerabilities in different stages of agent operation" and finds "limited effectiveness shown in current defenses" (Zhang et al., 2025).
- A benchmark from 2024 evaluated "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks", which is the scale at which defenses have been measured rather than fixed (Liu et al., Formalizing, 2024).
- A study of agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., Your, 2026).
- Perplexity's account of Comet says it "knew from the start that a single defense mechanism wouldn't be enough" and describes a multi-layered approach, with no measured failure rate published alongside it (Perplexity, 2026).
- A governed environment replaces values with consistent tokens before any model reads the screen, so an injection that succeeds inside the model collects a placeholder such as ACCT_001 and not the account number it stands for (What Is the Lethal Trifecta for AI Agents?).
- Real values resolve only at the approved destination at the moment of an approved action, so a hijacked run can finish its task without carrying the value to a page that nobody approved (What Should an AI Agent Security Review Cover?).
What would a model-level fix have to cover?
A model-level fix is a change inside the model: training, an instruction hierarchy, refusal behavior, or a classifier in the same weights that recognizes a hidden instruction and declines it. To end prompt injection, the model would have to separate instruction from data reliably when both arrive as the same text, in every language and every encoding a page can carry. OWASP's entry for excessive agency frames the harm one layer out: the risk is "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, 2025). A model that refuses more often lowers the frequency of manipulated output; it does not remove the action path.
The scope of this page follows from how an agent reads. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages, issue pages and sign-up forms. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. On those surfaces an injection arrives as a file, a repository comment or a tool response, and no browser-layer control sees it. A model-level fix is the only kind that would reach those paths.
What a fix would have to break is the combination the lethal trifecta names: private data, untrusted content and an external channel, and an agent holding all three can be made to steal the data by content it reads, as What Is the Lethal Trifecta for AI Agents? records. A model-level defense would have to recognize malicious intent and refuse every time, against an attacker who can read the same defense. That is why the sections below examine measurement and architecture instead of a release date.
What does the research record show about a model-level defense?
The three benchmark papers reviewed here describe the state of defenses, and none reports one that holds. Agent Security Bench, which formalizes attacks and defenses for agents, reports that its results "reveal critical vulnerabilities in different stages of agent operation", with "limited effectiveness shown in current defenses" (Zhang et al., 2025). Its abstract does not say which defense performed best or by how much. What it does say is that the stages of an agent's operation fail in different places.
The earlier benchmark is the cleanest statement of the measurement problem. Its authors "conduct a systematic evaluation on 5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks" and offer the result as "a common benchmark for quantitatively evaluating future prompt injection attacks and defenses" (Liu et al., Formalizing, 2024). Ten defenses is a survey of a field, not a fix, and the word future concedes that the set will change.
The coding-editor study is the sharpest number in the record. It reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., Your, 2026). The abstract gives no trial counts and no tool versions, so the figure is a direction rather than a rate to quote at a vendor. A model's willingness to follow content is not a settled parameter.
The proposal that looks most like a fix is not model-level at all. Willison's design patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks" (Willison, 2025). That constrains what the agent may do, not what the model has learned. Does a Smarter Model Stop Prompt Injection? covers capability; the conclusion here is narrower: no paper reviewed for this page reports a model-level change that ends the class.
What do the vendors themselves say?
Three vendor pages and one cloud provider's guidance describe controls that ship today, each with a limit stated in the same breath.
Perplexity's Comet post is the most direct about strategy. It says "Prompt injection attacks are constantly evolving, and defending against them requires a multi-layered approach", and it "knew from the start that a single defense mechanism wouldn't be enough" (Perplexity, 2026). The post publishes no measured effectiveness or failure rate.
Anthropic's permissions page is the most concrete about mechanism. It tells a team to "add a Read deny rule for its path" to block the file tools, and it states that a .claudeignore file "has no effect", so its entries have to move into deny rules (Anthropic, 2026). The page then names the gap: the rules "don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file" (Anthropic, 2026). The control is a list of paths, and the agent's routes are not.
OpenAI's Codex Cloud page puts the network in the control position: "By default, Codex blocks internet access during the agent phase", while "Setup scripts still run with internet access so you can install dependencies", and the advice is to "allow only the domains and HTTP methods you need" (OpenAI, 2026). The page is marked Legacy and does not explain how the allowlist is enforced.
AWS's guidance goes to identity rather than content, asking for a separation that makes "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). That is a condition for investigating an incident, not a way to prevent one.
| Source | What the page documents | The limit it states | What a buyer should verify |
|---|---|---|---|
| Perplexity, Comet security | Layered defenses, no single mechanism enough | No measured effectiveness or failure rate | Whether a rate exists outside the post |
| Anthropic, Claude Code permissions | Read deny rules; .claudeignore has no effect |
Rules miss a command that reads files without naming them | Whether the agent's route is a named path |
| OpenAI, Codex Cloud (Legacy) | Internet blocked in the agent phase; setup scripts exempt | Allowlist advice; enforcement not explained | Which phase the allowlist covers |
| AWS, Agentic AI Lens | Separate agent and human identity | Attribution after the action, not prevention | Whether separation exists before the first action |
| OWASP, LLM06 | Excessive agency as the harm path | Root causes are functionality, permissions and autonomy | Which of the three the deployment reduces |
Why is a benchmark result not a fix?
A benchmark fixes a set of attacks and scores defenses against it. That makes the numbers comparable and stale. The benchmark paper reviewed above offers "a common benchmark for quantitatively evaluating future prompt injection attacks and defenses", a phrase that concedes the set will change. A defense tuned to today's attacks is being scored on attacks its authors already know, and an attacker who reads the same paper starts from the failures it reports.
The second reason is the one a buyer feels. A single figure, such as the 84% success rate reported above for agentic coding editors, compresses a scenario into a number without saying which model, which tool or which injection. The abstract behind it gives no trial counts and no tool versions. A team cannot tell whether its own stack sits above or below the figure, and no vendor page reviewed for this article publishes a measured failure rate for its own model. That absence is not a claim that a vendor's defenses fail; the number a buyer would need is not described in the pages reviewed.
The third reason is structural. A defense inside the model has to be updated whenever the attack distribution moves, which makes the fix a process rather than a release. A defense outside the model, in what the agent may do after the model proposes an action, does not need to know the attack: a rule that the agent cannot post to an unlisted host holds whether the instruction arrived in a web page, an issue comment or a tool response. That is why the design patterns in the record constrain actions, and why the vendor pages above stop at permissions and network rules.
Where does the fix land if it is not in the model?
The controls that act today sit at four layers, each stating the route it misses.
The first is the tool and the filesystem. Claude Code's deny rules are a path list that blocks the file tools, with the documented gap that a command reading files without naming them is not covered (Anthropic, 2026).
The second is the network. Codex blocks internet access during the agent phase by default, with setup scripts exempt, and advises allowing only the domains and methods a task needs (OpenAI, 2026). That bounds where a successful injection can send data, not what it can ask the model to do.
The third is identity. AWS asks that audit logs attribute every action to an agent or a human (AWS, 2026). According to Is It Safe to Let an AI Agent Set Up Your Cloud Environment?, AWS strongly recommends not creating access keys for the root user. According to What Can an AI Agent See in Your GitHub Settings?, GitHub tells users to treat access tokens like passwords and documents fine-grained tokens limited to specific repositories. Scope and attribution shrink an incident; they do not stop the instruction.
The fourth is the review. The four questions a review can answer are what the AI saw, where it could go, what it did and what an attacker gets (What Should an AI Agent Security Review Cover?). Those questions are answerable now, and a model-level fix would leave them unchanged. Does Prompt Injection Matter If the Agent Has No Credentials? takes the case where the answers come back empty.
What does a governed environment change?
A governed environment is a control class that acts where the screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, such as ACCT_001, so the model works on placeholders that carry no value an attacker can use. Real values resolve only at the approved destination, at the moment a named person approves the action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring, and that record is where the four review questions get their answers.
For this page's question, it changes what a successful injection collects rather than whether injection succeeds. If the model reads a token where a card number, an account balance or a credential would sit, an injected instruction that redirects the task returns placeholders. The action path OWASP names is gated: a payment, a submission or a record change waits for a named approval, and the approver sees the destination and the token rather than the value. A model fix, if one arrives, would lower how often an attacker reaches that point; the token layer bounds what the attacker gets when one does.
The scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential in an environment variable or a file the agent opens stays with the controls a team configures for that layer. What the control class adds is the part no model-level defense supplies: a statement of what the model was shown, screen by screen, and a record of who approved what.
Methodology and limitations
This page rests on three research preprints on prompt injection benchmarks and attacks against agentic coding editors, vendor pages from Perplexity, Anthropic and OpenAI, one AWS Well-Architected guidance page, the OWASP entry for excessive agency, and one practitioner's design notes. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from the benchmark papers are cited as their abstracts report them, not as independently measured results. None of the preprints reports a deployment figure, and the vendor pages report controls rather than measured effects.
RedactSure did not test any product hands-on. Where a page does not state something, this article says so rather than inferring it; a vendor's current documentation may carry an answer the reviewed page does not. Vendor features change and the page carries its date, so a release after it should be treated as unreviewed until the test at the end is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Where a control is documented without an effect, this page describes the control and leaves the effect unstated. The example in the closing section describes a record type, a repository settings page opened to rotate a deploy key, and not an organization.
Determinations about whether an agent deployment meets a contractual, regulatory or sector requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own workflow.
What the record shows
The record gives one answer to the title and no date. Every benchmark reviewed finds current defenses partial, the vendor pages describe layers with stated gaps, and the proposal that constrains what an agent may do is architectural rather than learned. Two of the three benchmarks describe defenses without ranking them, and the vendor pages describe controls without an effect. That makes a model-level fix something to welcome rather than something to schedule. RedactSure's control class does not wait for it: it bounds what a failing model can collect, screen by screen. Testing this takes a single agent and task: ask what an injection that succeeds would return, then check whether the answer is a value or a token.
Frequently asked questions
Will prompt injection ever be fixed at the model level?
Not on a schedule a buyer can plan for. The benchmarks reviewed here find current defenses only partly effective, and the vendors that publish their reasoning describe layered controls with stated gaps rather than a model that cannot be manipulated. No page reviewed here offers a date. A fix may arrive as an improvement in the rate, and an improvement is worth having. The decision in front of a security team is what a successful injection can collect in the meantime.
Why can a model not simply learn to ignore instructions in content?
Because the instruction and the content arrive as the same kind of text, with no separator the model can rely on across languages, formats and encodings. Training can teach a model to weight some text as data, and the coding-editor study suggests how much room is left. It cannot tell which text is data on syntax alone. A defense that depends on the model recognizing intent competes with an attacker who reads the same research and adapts the text.
Does a benchmark score tell me how my agent will behave?
Only against the attacks the benchmark contains. The 2024 evaluation scored five attacks and ten defenses across ten models and seven tasks, which is useful for comparing defenses and not for predicting your stack. A figure such as 84% comes from a scenario whose trial counts and tool versions the abstract does not report. Run the same test on your own agent before you treat a published number as your number.
What do the vendors say about their own defenses?
They describe controls with limits rather than a fix. Perplexity says a single defense mechanism would not be enough, Anthropic documents deny rules and the command they miss, and OpenAI documents network blocking with setup scripts exempt. AWS frames the problem as identity and audit. None of them publishes an effectiveness figure beside the control. Read each as a statement of what the control covers, and treat the absence of a measured failure rate as the gap to press on.
Where should a team put controls while it waits?
At the layers the vendor pages describe, and at the point where a value becomes visible. Deny rules, network allowlists, scoped tokens and separate agent identities each reduce what a successful injection reaches, and each states its own gap. Add an approval for consequential actions and a record of what the model was shown. Those controls buy time and evidence, and they answer the review questions a model fix would leave open.
What changes if the model reads tokens instead of values?
The injection still succeeds and the task can still be redirected, but what leaves with the attacker is a placeholder such as ACCT_001 that resolves nowhere outside the environment. The real value appears only at the destination a named person approved. That does not make the model safer; it makes the failure survivable. A team that measures what its agent collects, rather than how often it is fooled, is measuring the thing a token layer changes.
How RedactSure Makes a Non-Zero Injection Rate Survivable
The record gives a benchmark and a caveat but no date, and the controls vendors document at the file, network and identity layers each miss a route.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: an agent on a repository settings page reads the deploy key in the field and the injected comment beside it, so a run that follows it can send the key out. Inside the governed environment: the page renders TOKEN_001, and an instruction that asks for the key receives a placeholder. The value appears only in the settings form a named person approves.
RedactSure is deploying now with enterprise and government customers. The coding-editor study reports success rates "as high as 84%" for malicious commands.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
If injection is never fully solved at the model, what matters is what a successful injection can take. Bring a repository task and see, with test values, what an injected instruction would receive. Book a demo





