Evaluating Vendor Detection Capabilities for RAG-Borne and Plugin-Introduced Prompt Injection in Production

Testing indirect prompt injection detection in enterprise RAG pipelines means testing the whole knowledge-access pipeline as well as scanning retrieved documents for malicious text. Plugin and connector security requires separate tests of tool results, execution boundaries, and post-installation changes. Buyers must test these attack surfaces separately, measure how well vendors do on buyer-controlled tests, and keep checking after deployment because benchmark scores and installation-time approval cannot show that protection will last.

Why RAG and plugin systems face structurally different injection threats

The Hong Kong Polytechnic University taxonomy places RAG security at the external knowledge-access pipeline. An attacker need not change the user’s question or the model’s parameters. Instead, the attacker manipulates external content, retrieval behavior, or disclosure behavior so that harmful evidence enters the model-visible context. The user’s request can remain entirely legitimate. The breach occurs where outside knowledge becomes evidence the model uses to answer it.

Plugin and tool-integrated systems cross a different boundary. Their integration layer can turn a model’s output into an action, so manipulated context can lead to unauthorized API calls, data exposure, or workflow abuse. The distinction is between influencing evidence and escalating execution. A defense positioned at retrieval does not, by that placement alone, observe what happens when the model invokes a tool. Conversely, a prompt-layer defense cannot see how a shared corpus was manipulated before retrieval.

Persistence also separates the two threat patterns. RAG poisoning can corrupt a shared knowledge substrate, so the same planted material can affect different queries and users. Its effects are not confined to one conversation. Plugin attacks do not persist through a shared corpus in this way, though integrations have their own problems after installation. Tests that use only direct prompts therefore leave both the full retrieval pipeline and the tool invocation layer untested, however good the headline score looks.

How RAG corpus poisoning actually works and why single-document detection is no longer sufficient

InceptionRAG (CCS’26) documents how traditional corpus poisoning places its payload within a single document. That concentration gives defenses something recognizable to detect, including anomalous attention variance, excessive keyword frequency density, and direct factual contradictions across retrieved passages. But what happens when no individual passage contains the attack? InceptionRAG fragments the payload across a chain of dormant passages that appear harmless when examined separately. The attack activates when several fragments are retrieved together and the model’s reasoning assembles the intended misinformation through multi-hop logic.

The model supplies the missing connections itself. InceptionRAG finds that stronger reasoning can make the model more vulnerable because it gets better at completing the attacker’s planted logical chain. It reports an attack success rate of more than eighty percent under strict adversarial constraints, even against defenses built for single-document injection.

UniC-RAG, from Penn State, expands the problem from distributed evidence to attacks that work across many queries. A small number of adversarial texts can target a large and diverse set of questions spanning different topics and domains. UniC-RAG reports over ninety percent attack success after injecting a small number of texts into a knowledge database containing millions of texts, with existing defenses proving insufficient. It has been shown to cause denial-of-service, malicious URL injection, and harmful command execution. The attack need not be tailored to one question.

University of Waterloo research adds another variable by showing that adversarial documents substantially degrade alignment in health-domain RAG, while robustness is preserved when helpful evidence is also present in the retrieval pool. The surrounding evidence changes the outcome.

The additional attack surfaces RAG introduces beyond the corpus itself

The taxonomy organizes RAG security around four surfaces, including pre-retrieval knowledge-substrate corruption, retrieval-time access manipulation, downstream retrieved-context exploitation, and knowledge exfiltration. Malicious content hidden in common document formats can slip in unseen during parsing and loading, before indexing. A scanner that begins with indexed content has already missed that ingestion window. Most vendor tools address at most one or two of the four surfaces, leaving a broader coverage question than corpus integrity alone.

IBM Research shows how membership inference can pose a separate threat to privacy. An attacker can infer whether a particular document is present in a retrieval database by observing system outputs without access to its internals. This is disclosure. The attack works in both black-box and gray-box settings, so a third-party system’s opacity does not itself protect proprietary or regulated content. Its connection to injection is structural, because both exploit the retrieval database’s influence on externally visible answers.

Even within retrieved-context exploitation, the user’s question changes the result. A question that is consistent, neutral, or inconsistent with a poisoned document can alter that document’s influence on the answer. The document alone is not the whole exposure. RAG evaluation therefore has to account for the pipeline that introduces content, the context that gives it influence, and the information that outputs reveal.

How plugin and tool-use injection differs mechanically from RAG poisoning

For plugins, the decisive event is the transition from model output to execution. If an integration trusts that output, adversarial context can become a tool call with attacker-supplied arguments. Hardened system prompts can block task hijacking well but offer little protection against attacks on tool-use capabilities. A model that resists an instruction to abandon its task may still be coerced into using a tool in an unauthorized way.

Research accepted to IEEE S&P 2026 found that plugins used by thousands of websites transmit message history from the user’s browser to the LLM without integrity checks. This allows adversaries to inject forged messages directly. The trust failure sits in the integration layer. The same research found that a meaningful fraction of randomly selected e-commerce sites had already exposed their chatbots to third-party content. The exposure is therefore present in production deployments.

Model Context Protocol (MCP) introduces a particularly sharp example through “rug pull” attacks, in which tools mutate their own definitions after installation. A tool approved as safe on day one may silently reroute API keys to an attacker by day seven. Initial approval cannot establish what happens afterward. Current text-scanning detectors cannot detect this post-installation mutation because the attack is a behavioral change in a previously approved component outside the text available for scanning. There is no widely deployed mechanism for detecting that mutation.

The timing of inspection also differs from RAG. Plugin invocations sit on synchronous execution paths, where extra detection latency directly worsens the user experience. RAG retrieval often has a pre-fetch window with more tolerance for inspection overhead. That difference constrains which detection architectures are viable in production. Coverage and response time must be assessed together, rather than treating latency as a secondary purchasing detail.

What the benchmark landscape measures and what it systematically leaves out

BIPIA, from Microsoft Research, measures indirect prompt injection attack success for LLMs integrated with external content across five application scenarios. It is document-grounded, but it does not cover the multi-fragment distributed poisoning demonstrated by InceptionRAG. AgentDojo measures attack success and utility under attack for tool-using agents, but cannot model post-installation tool mutation. Both address useful but bounded questions. TensorTrust (ICLR 2024) addresses direct chatbot injection, so its results do not establish protection against indirect attacks through retrieved evidence.

PIArena (ACL 2026) provides a unified and extensible platform for prompt injection evaluation. Yet a platform’s breadth does not remove the need to examine the scenarios used in a particular assessment. What, exactly, did the reported score test? A classifier can have high recall on its own benchmark and do far worse on another benchmark that tests indirect injection. A test of familiar examples shows how well a defense handles those examples, while a test that reflects production conditions can back a broader claim about how it works in production.

Some managed cloud controls check prompts and responses separately without keeping conversation history, so they cannot see attacks that span turns. Some also require tool results to be submitted explicitly for additional checks. Published adaptive attack research further shows that defenses performing well on standard benchmarks can be bypassed by adversaries who know the defense.

The lesson for buyers is to control the test conditions. Before working with the vendor, the buyer should set acceptance criteria using a benchmark corpus it controls. The protocol should include multi-fragment RAG attacks and post-tool-invocation inspection rather than accepting vendor-supplied scores as substitutes. This shifts the evaluation from advertised performance to evidence about the deployment being protected.

How should buyers evaluate detection for RAG pipelines and plugins?

For the RAG surface, the first question is where detection actually operates. Does coverage start with document loading and parsing, reach through retrieval-time ranking and downstream context use, and cover knowledge exfiltration? Stage names alone are not sufficient evidence. The assessment should check whether inspection happens before indexing or only afterward, and whether privacy testing covers membership inference or treats all leakage as the result of injection. Each stage presents a different opportunity for a control to miss the threat.

Can the detector identify a payload distributed across passages, or does it judge each document independently? Tests the buyer controls should include multi-fragment and cross-document poisoning, along with cross-query attacks like those UniC-RAG shows. Retrieval composition belongs in those tests too. Varying helpful and adversarial evidence, as well as the question’s relationship to poisoned content, tests whether detection accounts for the conditions that give an attack its influence.

For the plugin surface, the questions move to execution. Are tool results inspected automatically, or must the application explicitly submit them for checking? Does the vendor monitor post-installation changes to tool definitions and behavior? The enforcement point needs equal scrutiny. Text scanning, restructuring execution flow, and monitoring kernel or agent behavior are not equivalent approaches, so the buyer should ask which failure modes the offered control can actually observe.

Agentic deployments require a further trust-boundary question. When one agent calls another, does the control enforce boundaries between them or treat every agent output as trusted? The buyer should also establish that hardened system prompts are not the primary defense against tool-argument coercion. Speed belongs in the same assessment. Evidence of added latency must show whether inspection stays under the buyer’s acceptable threshold for synchronous execution paths.

Across both surfaces, recall and false-positive rates should be measured on the shared buyer-controlled corpus, with adaptive attacks included. Has the vendor tested against an adversary who knows the defense? Records of updates should show whether detection now covers newly disclosed multi-fragment and universal corpus attacks, and monitoring should continue after the pre-deployment assessment. Finally, can the vendor produce control-coverage evidence for the specific regulatory frameworks the buyer’s compliance program requires?

Why continuous vendor monitoring matters after the initial evaluation is complete

Procurement-time evidence describes a system and a threat set at a particular moment. Both can change after deployment, which makes continuous monitoring part of the security model. The MCP rug-pull pattern exposes that temporal gap. A tool’s behavior after approval cannot be established by repeating the fact that it passed an installation-time assessment. Continuous behavioral monitoring addresses a question that a point-in-time evaluation cannot answer.

New attack research changes the meaning of earlier results too. InceptionRAG and UniC-RAG were absent from earlier defense guides, and controls designed for preceding attack patterns do not cover them. Google’s AI Vulnerability Reward Program, launched in October 2025, pays bounties for rogue actions caused by indirect prompt injection in flagship products.

The organizational consequence extends across TPRM, InfoSec, Privacy, and Legal. These teams need vendor risk assessment connected to real-time AI threat detection across the vendor ecosystem, which is the role dedicated AI risk intelligence platforms are built to fill. Coordination is essential because most vendors currently cover at most one of the two layers, retrieval or tool invocation. A strong score for one layer cannot establish protection for the other.