Prompt Injection Research Review: Defenses That Generalize

What research can—and cannot—show about prompt-injection defenses

Evidence cutoff: 2026-09-17. Prompt injection is a system-boundary problem: untrusted text or retrieved content is interpreted by a model that may also hold instructions, credentials, tools, or a path to a consequential action. This review asks a narrower question than Prompt Injection Attacks: which defenses have evidence that extends beyond the exact attacks and configuration used in testing?

The answer is deliberately qualified. A detector can reduce observed attack acceptance without preventing a bad tool call. A prompt wrapper can transfer across held-out strings while failing after a model, language, tool, or attacker change. Stronger evidence comes from external enforcement—authorization, constrained execution, and least privilege—because those controls limit damage even if the model misclassifies content. It is not evidence that prompt injection has been solved.

Evidence record and how to read it

Three useful, but different, evidence sources frame this edition. Liu et al.’s Formalizing and Benchmarking Prompt Injection Attacks and Defenses (arXiv preprint, October 2023) created a common benchmark for comparing attacks and defenses. Its value is a shared measurement frame; its limitation is that benchmark success remains tied to its corpus and model/system choices. Google DeepMind’s CaMeL: Defending Against Prompt Injection Attacks with Capability-Based Security (technical report, 2025) moves enforcement outside natural-language compliance by using capabilities and information-flow constraints. Its reported task environments demonstrate a system approach, but do not establish universal production transfer. The 2026 preprints Evaluation of Prompt Injection Defenses in Large Language Models (April 26) and Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection in LLM Agents (June) explicitly test defense-aware attackers; both are preprints and therefore need independent replication.

The studied populations vary: direct user text, indirect instructions in retrieved content, and tool-using agents. Metrics vary too: attack success, model compliance, blocked actions, task completion, and false positives. Treat those as different endpoints. A low attack-success rate in a static string corpus is useful evidence about that corpus; it does not measure whether a deployed agent can still transmit data, use a credential, or take an unauthorized action.

PROMPT-INJECTION DEFENSE EVIDENCE MATRIX

Defense	Security boundary	Threat model	Models/tasks	Adaptive?	Utility cost	Generalization evidence	Main limitation
Input/content detection	Input before model	Known direct or indirect malicious content	Benchmark prompts and agent inputs	Often static; 2026 studies add adaptive attackers	False positives can reject benign discussion	Held-out prompt sets can show Level 1 transfer	Detection is not damage prevention; semantic evasion and distribution shift remain.
Instruction/data separation	Context assembly	Retrieved content attempting to act as instruction	RAG and web-agent tasks	Usually limited attacker adaptation	May reduce useful contextual interpretation	Some cross-prompt evidence	The model still consumes both channels; labels are not authorization.
Capability/reference monitor	Tool/action boundary	Compromised or confused model with untrusted context	CaMeL-style tool tasks; agent evaluations	More meaningful when attacker sees policy	Legitimate actions need explicit delegation	System-level transfer within tested tasks	Policy completeness and correct labels are assumptions.
Least privilege and scoped credentials	Identity and resource boundary	Any successful injection	Tool-using application	Not dependent on attack text	Can add approval and integration friction	Architectural rather than corpus-specific	Does not stop misleading output or unauthorized reads already permitted.
Output validation	Downstream parser/action	Unsafe generated output	Structured tool calls and application workflows	Depends on adversarial test set	Schema and validation failures may block valid edge cases	Transfers where deterministic constraints remain identical	Validation cannot infer business authorization by itself.
Monitoring and anomaly response	Runtime trajectory	Novel or multi-step influence	Agent traces	May observe adaptive behavior	Review and alert burden	Can improve detection after deployment-like trials	It is often retrospective and depends on escalation.

The matrix reports evidence classes, not product endorsements. The June 2026 out-of-band evaluation is especially useful because it distinguishes defenses that mediate actions from defenses that merely ask a model to resist. Its reported adaptive test is stronger than a static benchmark, but only for its selected agent environment, policies, and runs. The April 2026 evaluation similarly reports broad adaptive testing across nine configurations; its result should be treated as preprint evidence until methods and data receive independent scrutiny.

Attack detection is not damage prevention

A detector asks whether an input resembles an attack. Damage prevention asks whether the system can perform an impermissible effect after any input is accepted. These controls overlap but have different error costs. False positives can prevent legitimate work; false negatives become consequential only where the model can cross a boundary.

That distinction changes engineering priorities. If a retrieved document causes a model to produce a suspicious string but the execution layer requires a signed, scoped authorization for each effect, the event may be detectable without becoming damaging. Conversely, a high-recall classifier in front of an agent with broad credentials still leaves an unmeasured failure path. Indirect Prompt Injection maps that retrieve-to-action path; AI Agent Permissions explains why an instruction is not a delegation.

Prompt-level defenses are therefore useful friction and telemetry, not a replacement for system-level authorization. The same is true of delimiters, role labels, and “treat this as data” instructions: they can alter behavior in a measured setup, but do not create a hardware, identity, or policy boundary. A claim that a prompt is “secure” needs an action-level test to be meaningful.

DEFENSE GENERALIZATION LADDER

This is a PermsAI synthesis, not an official standard.

Level	What the result means	What it does not mean
Level 0 — attack-specific result	The defense changed outcome on named attacks.	It works on unseen attacks.
Level 1 — unseen attacks, same setup	It transferred to held-out prompts under the same model, task, and environment.	It transfers across systems or adaptive attackers.
Level 2 — cross-model/task evidence	The result appears across declared models or task populations.	It covers every tool, language, retriever, or deployment.
Level 3 — adaptive/system-level evaluation	A defense-aware attacker and real action boundary were tested.	The policy, harness, or exposure matches production.
Level 4 — independent/production-like replication	A separate evaluator reproduced the result with documented realistic constraints.	Risk is zero or every future variant is covered.

Most public results belong at Levels 0–2. That is not a criticism; it is an accurate description of their claim scope. Level 3 requires publishing the attacker budget, retries, tool permissions, and success predicate. Level 4 requires enough protocol detail for an independent party to challenge the result without reproducing unsafe attack instructions.

AI Security Benchmarks: What Attack Success Rates Mean is the companion methodology page. Its central rule applies here: report the numerator, eligible denominator, attacker knowledge, budget, defender version, judge, and utility outcome. Static attack success does not demonstrate adaptive resistance. Transfer across prompts does not necessarily transfer across models, tools, domains, languages, or attackers.

DEFENSE-IN-DEPTH CONTROL STACK

Untrusted content → trust classification → instruction/data separation → least privilege → authorization → execution constraints → monitoring → output validation.

Trust classification records where a document came from and why it is allowed into context. Separation preserves that label through retrieval and assembly rather than converting source prose into policy. Least privilege limits what the agent identity can reach. Authorization checks whether the requested effect is allowed for this task, resource, and actor. Execution constraints enforce schemas, destinations, budgets, and sandboxing outside the model. Monitoring detects unusual trajectories, while output validation prevents generated text from silently becoming an unsafe command or transaction.

Each arrow needs test evidence. Build a small evaluation suite with benign tasks, known attacks, held-out attacks, and policy-denied variants. Test direct and indirect content separately. Record model/version, system prompt, retriever, tools, permissions, retry budget, detector threshold, and action outcome. Measure both task utility and false positives. Then repeat when the model, connector, tool schema, or authority model changes.

What builders should change now

Start by inventorying consequential effects: sending, publishing, file access, credential use, code execution, and external requests. For each, define a resource allowlist, a principal, a time bound, and a verifiable decision record. Make the safe path easy: structured tool parameters, explicit approval for high-impact effects, and a narrow default identity. Keep raw retrieved content visible to reviewers with provenance rather than flattening it into trusted instructions.

Use detectors to triage and learn, but evaluate them on realistic benign traffic. A detector that blocks security documentation, support cases, or multilingual content has an operational cost that a pure attack-set score hides. Use an independent action monitor or reference policy where possible. Ensure a stop operation prevents queued retries and follow-on actions, not only the final text response.

Finally, publish the limitation alongside the result. “Reduced attack success in a static benchmark” is a defensible claim. “General prompt-injection robustness” is not, unless the evidence ladder, system scope, and independent replication support it. As of 2026-09-17, no selected source establishes a universal single-family defense.

Evaluation protocol: make conclusions falsifiable

A useful defense report contains a control version and a failure record. Split the corpus by source rather than randomizing near-duplicates; reserve unseen tools or domains when the intended claim involves transfer. Document attacker adaptation: did the attacker know the detector threshold, policy language, model family, or previous failures? Declare whether an evaluator may retry, use multiple agents, or choose which tool result reaches the model. Those choices can change a result as much as a new prompt guard.

For every blocked event, inspect whether the underlying task could complete through a legitimate alternative. For every allowed event, log the requested effect, resource, provenance label, policy result, execution result, and reviewer decision. This turns “the model appeared safe” into an auditable claim about a configured system. A team cannot infer a future model release will preserve that property; it must rerun the protocol after change.

Generalization test protocol

Use a staged protocol rather than one aggregate attack score. First tune or select a defense only on a declared attack family. Next test a held-out family in the same model and environment; then repeat across a different model version and task family. Continue with a cross-tool, RAG, or agent environment where untrusted content can influence a policy decision. Only then introduce a defense-aware attacker, measure benign-task utility and false positives, and test whether an allowed injection can still cause a denied side effect.

Passing the first two stages establishes at most an in-setup result: the same pipeline may share vocabulary, formatting, and attacker assumptions with its holdout. Cross-model or cross-tool tests challenge different failure modes, while an adaptive attacker tests whether the defense survives observation. The final containment test answers a separate question: whether a miss can become damage. Keep these stages separate in reporting so a team does not turn a prompt-level gain into an authorization claim.

Defense failure composition

A failure record should identify where the chain broke. A detection miss means content was not flagged; a false positive means benign work was impeded; an instruction-following failure means the model treated data as policy. An authorization failure means a request was incorrectly permitted, while a tool-policy failure means execution was allowed beyond the intended resource, scope, or budget. Post-model containment success means an independent control stopped the effect despite one of the earlier failures.

This composition is operationally useful because model-level failure does not necessarily equal system compromise, and detector success does not necessarily equal damage prevention. It also makes retesting specific: improve a classifier for misses, a policy for authorization errors, or an execution constraint for containment gaps rather than claiming a generic prompt-injection fix.

Sources

• Liu et al., Formalizing and Benchmarking Prompt Injection Attacks and Defenses, October 2023, arXiv preprint. Source. Benchmark and defined comparison frame; not universal deployment evidence.
• Google DeepMind, CaMeL: Defending Against Prompt Injection Attacks with Capability-Based Security, 2025, technical report. Source. Capability-based enforcement approach; evaluated-environment limits apply.
• Evaluation of Prompt Injection Defenses in Large Language Models, April 26, 2026, arXiv preprint. Source. Adaptive attacker across nine configurations; preprint status and method-specific population limit transfer.
• Adaptive Evaluation of Out-of-Band Defenses Against Prompt Injection in LLM Agents, June 2026, arXiv preprint. Source. Action mediation and adaptive evaluation; selected harness/policies limit generalization.
• OWASP AISVS, Prompt Injection Defense research chapter, accessed 2026-09-17, official project guidance. Source. Control taxonomy, not a claim that any listed control is sufficient alone.