Don’t Rank the Guardrails: Map Prompt-Injection Defenses to the Stack

TL;DR for operators

Prompt-injection defense should not be procured as a leaderboard winner. A systematic review of 88 studies finds defenses distributed across several parts of the LLM system, from training and prompt handling to document boundaries, tool execution, output filtering, and continuous testing.¹ Fifty-six of those 88 approaches, or 63.63%, are model-agnostic: they can operate around different models without changing model weights or architecture. That matters for teams building on proprietary APIs.

The harder finding is about evaluation. The commonly reported measure of how often attacks bypass a defense is meaningful inside one experimental setup, but it is often unsafe to compare mechanically across papers. Differences in model variants, datasets, attack implementations, decoding settings, baselines, and judging procedures can change the number materially. Security teams should therefore use the review’s expanded taxonomy as an architecture map, then benchmark candidate controls under the conditions of their own application.

For RAG, document-ingestion, and tool-integrated systems, generic filtering is not enough as a design assumption. The review separates defenses for indirect prompt injection because hostile instructions can arrive through external content rather than the user prompt. A layered stack is the paper’s operational direction; the performance, cost, and interaction effects of a complete combined stack have not yet been established.

The first decision is where a safeguard belongs

A team deploying an LLM application has several places to intervene. It can make the underlying model more resistant during training. It can inspect or transform prompts before generation. It can filter outputs. It can separate trusted instructions from retrieved documents. It can restrict what tools the model is allowed to invoke. It can also keep probing the deployed system for new failure modes.

Correia and colleagues organize 88 defense studies around this lifecycle and extend the NIST adversarial-machine-learning taxonomy where the literature no longer fits cleanly.¹ The review adds or refines categories for input and output filtering, self-reflection, perturbations at character, token, and sentence level, model-level decoding and pruning defenses, and prompt-stealing prevention as well as detection.

That changes the selection problem. A filter, a training intervention, an execution-isolation mechanism, and a security-testing framework are not interchangeable products competing for one slot. They act on different failure pathways.

The review’s frequency data reinforce this point. Safety training and input/output filtering are the most commonly studied families, but 56 of 88 defenses are model-agnostic. Another 54 studies, or 61.36%, provide source code to at least some degree. The literature therefore contains a substantial set of controls that can be deployed around models rather than inside them.

For an organization using a closed model API, that is a concrete design option rather than a consolation prize.

The taxonomy works better as an architecture map

The paper’s most useful operational contribution is not a ranking. It is a vocabulary for deciding where controls should sit.

This mapping matters because the threat surface changes with the application.

A chatbot receiving only direct user text has a different exposure from a RAG assistant ingesting arbitrary documents. An agent that can send messages, access private records, or execute transactions adds another boundary: compromised text can become an operational action. The review therefore treats defenses against indirect prompt injection as a distinct area. Untrusted instructions can arrive through retrieved material or integrated components without the attacker directly addressing the application.

Cognaptus inference: teams should map each channel by which instructions, data, and authority enter the system, then assign a control to the relevant boundary. For tool-enabled systems, that may mean separating trusted orchestration from untrusted content and retaining human authorization for actions with material privacy, financial, or operational consequences.

The paper supports that design logic. It does not establish which implementation is cheapest or strongest for a particular production workload.

A low bypass rate is not a cross-paper ranking

The review’s strongest corrective concerns benchmarking.

Many studies report the fraction of adversarial attempts that successfully bypass a defense. Within a fixed experiment, lower is better. The problem begins when one paper’s number is placed beside another paper’s number and treated as if the experiments were interchangeable.

Section 6.2 identifies differences in dataset splits, precise model variants, temperatures and other inference parameters, attack implementations, baselines, and evaluation procedures. Even nominally similar model-and-attack combinations can start from substantially different baseline vulnerability levels.

The review therefore does not pool effect sizes or claim a generally superior defense. Reported results are treated as study-level evidence.

That distinction affects purchasing and engineering decisions. Suppose Defense A reports a lower bypass rate than Defense B. Before treating A as stronger, an evaluator would need to know whether both were tested against comparable attacks, on equivalent model versions, with equivalent inference settings and success criteria. If one study used synthetic attacks and an automated judge while another used human-generated attacks and human assessment, the headline percentages answer different questions.

The authors accordingly recommend more complete disclosure of attack-data provenance, how successful attacks are judged, false positives, computational overhead, and degradation of legitimate task performance.

For operators, the replacement for cross-paper ranking is replication under deployment conditions.

Security gains need a utility ledger

A defense can reduce successful attacks and still be costly in production.

The review notes that many primary studies do not report normal-task degradation, which prevents a systematic comparison of this trade-off. False positives, latency, computational overhead, and legitimate-task performance are therefore not secondary metrics. They determine whether a safeguard can remain enabled in the product where it is supposed to provide protection.

A production evaluation should consequently track at least two sides of the decision: how much adversarial behavior is blocked, and what the defense does to ordinary users and workloads. A filter that blocks hostile prompts but frequently rejects legitimate requests changes the product. A reflection step that improves robustness but adds substantial inference cost changes the economics. An isolation layer that restricts tool access may reduce blast radius while also limiting automation.

The paper provides the reporting logic for these comparisons, but the 88-study corpus does not provide a normalized cost-benefit table from which those trade-offs can simply be read.

Layering is a design principle, not a measured final configuration

The review recommends a deployment foundation combining safety training where feasible, prompt instruction and formatting, and input/output filtering, then adding context-specific controls such as indirect-injection protection, monitoring, usage restrictions, and human authorization for sensitive actions.

There is a sound mechanism behind this recommendation: controls at different stages reduce dependence on a single safeguard. If hostile content passes an input filter, downstream authorization or execution isolation can still limit consequences. Continuous evaluation can then reveal failure modes that static defenses missed.

But the evidence boundary matters here. No reviewed study integrates every NIST defense together with every additional strategy identified by the review. The joint effectiveness, scalability, interference effects, latency, and utility cost of such a complete stack are unknown.

The review itself also has scope boundaries. It covers text-to-text systems and excludes multimodal and audio-language-model defenses. Non-English and non-freely-available work was excluded. Seventeen qualifying studies were added after the initial screening of 250 unique works—71 of which passed the original criteria—to cover defense strategies missing from the first set. The resulting synthesis is broad and structured, but it should not be read as an exhaustive census of every deployed defense.

Build the evaluation around the system you actually operate

The review makes prompt-injection defense easier to reason about by replacing a flat list of methods with a lifecycle-aware map.

For security teams, the immediate use is architectural. Identify where untrusted instructions can enter, where the model can influence consequential actions, and where detection or containment can still intervene. Closed-model products can lean heavily on model-agnostic controls. RAG and document pipelines need explicit treatment of untrusted retrieved content. Tool-enabled systems need restrictions on what model-generated instructions are authorized to do.

Then evaluate those layers together under the model versions, attack paths, workloads, and judging procedures that match the intended deployment.

The 88 studies do not tell operators which single defense wins. They provide a more defensible basis for deciding where protection belongs—and for recognizing when a benchmark number is answering someone else’s security question.

Cognaptus: Automate the Present, Incubate the Future.