Vendor Capability Breakdown for Pre-Model Indirect Prompt Injection Interception in Enterprise RAG

Enterprise RAG needs indirect prompt injection detection between retrieval and prompt assembly, where third-party content comes into the model’s context. Effective protection depends on where a vendor’s check runs, which payloads it detects, whether it covers agent actions, who enforces the result, and whether it can keep pace with production traffic.

Why indirect prompt injection is structurally different from direct injection in RAG systems

Direct prompt injection comes through the user’s input, which a defense can scan before it reaches the model. Indirect injection takes a different route. An attacker plants instructions in a document, database record, email, or webpage that the RAG pipeline later retrieves for an entirely benign query. At prompt assembly, retrieved chunks join the query and system prompt in one natural-language context, with no architectural boundary that reliably keeps text written in a document separate from instructions authorized by the developer.

Document-Authored Control-Signal Impersonation research identifies an even less obvious form of this failure, known as DACSI. The document need not issue a hostile command. Instead, attacker-authored text can impersonate metadata, provenance, or authority signals that the model mistakes for policy. A detector looking for imperative overrides may therefore miss a command-free payload. The SQL injection analogy helps explain how this breaks down, but here instructions and data are natural-language tokens that pass through the same attention mechanism. The exposure comes from how the pipeline combines sources.

Where should a RAG pipeline scan retrieved documents before they reach the model?

The decisive boundary is prompt assembly, where retrieved material is serialized into the context the model will process. A simple pipeline sketch runs from the corpus through retrieval and prompt assembly to generation, followed by tool execution in an agentic system. Each location offers a different control opportunity. Corpus screening can remove documents before retrieval, while retrieval filtering can reject chunks before assembly. Scanning the assembled context checks the combined text before model invocation, while output scanning checks a response that the payload may already have shaped.

Location therefore limits what a defense can prevent. An input scanner never sees an attack that comes only through retrieval, and an output scanner cannot undo the effect it has had on generation. Corpus screening offers an earlier intervention, but systematic corpus-level defense remains largely unexplored, and isolated document analysis can miss authority impersonation. Parallax research identifies a related limitation in prompt-level safety instructions. Because those instructions share the model’s attention mechanism with adversarial content, they do not create an independent trust boundary. Pre-model interception instead checks retrieved material before the model can treat it as authority.

The expanded blast radius when RAG pipelines include tool-calling and agent execution

What changes when the model can act? A successful injection can direct an agent to call a tool or generate and execute code, with the action running under the agent’s delegated permissions. Those permissions may extend to the user’s full system access. The failure is no longer confined to an answer, because retrieved text can become an execution chain. Parallax argues that prompt-level guardrails cannot protect a reasoning system once it is compromised, so the system must keep reasoning and execution separate.

The execution loop also creates more places to hide intent. Stateful trust inference research on multimodal agentic RAG finds that adversarial strategies can distribute malicious semantics across retrieval, planning, and generation, evading stateless checks. A single classifier may see no complete attack. In multi-agent systems, shared memory, orchestrator decisions, and downstream instructions provide further propagation paths. A clean prompt scan therefore cannot show that a later tool call is safe. The control boundary must extend to the action-bearing middle of the workflow, rather than stop when the initial model request begins.

The five technical dimensions that determine whether a vendor's pre-model interception approach can actually stop the attack

The first dimension is placement. Can the product inspect retrieved content before assembly, and can its check run independently of a model invocation? The second is payload coverage, including both imperative commands and non-imperative authority impersonation. These are distinct tests of capability. DACSI research shows that command-free payloads cause failures in a different way and need different mitigations, so a broad claim of prompt injection detection does not show that it covers both.

The third dimension is agent loop coverage, which asks whether checks reach the initial prompt and tool inputs and outputs. The fourth is action ownership after detection. Does the product block an attack, or return a classification that the application must turn into an allow, block, review, or containment decision? Source separation and retrieval-time redaction may also remain application responsibilities, even when a vendor supplies the detector.

The fifth dimension is latency and throughput at production scale. A synchronous check must fit the workload, particularly when each query retrieves many chunks. Per-request latency alone is not enough to judge viability. Throughput sets how fast checks can keep up, while parallelization or sampling changes how they run.

How Azure Prompt Shields positions its document-specific scanning within the evaluation framework

Azure Prompt Shields explicitly separates document-sourced injection from user-input injection as classification targets, distinguishing it among the major cloud-native products in this comparison. Its document check can run on retrieved content before the model receives it. That gives placement a concrete implementation point. The distinction also directly addresses the retrieval attack channel, though naming that channel does not by itself demonstrate coverage of every command-free payload. Each document scan adds synchronous latency that depends on the Azure region and Content Safety SKU.

The service returns classifications. The application team owns what happens next. Leaving the application team to turn a positive result into blocking, review, or containment is a choice about who does what and does not in itself make the product flawed. Azure’s Spotlighting technique complements classification by transforming retrieved content through base64 encoding in its Azure implementation, providing a continuous provenance signal within the assembled prompt. It remains a prompt-rendering mitigation, however, and the service does not natively extend its checks into tool-call execution. Agentic deployments must add controls at that boundary.

How Amazon Bedrock Guardrails addresses pipeline-stage placement — and where its documented gap lies in agentic deployments

Amazon Bedrock Guardrails offers the most flexible placement architecture in this comparison through its independent ApplyGuardrail API. The API assesses text without invoking a foundation model, allowing checks before retrieval, after retrieval, or after generation. Placement is therefore an application design choice. The same configured guardrail can protect application data at multiple stages, reducing configuration drift between retrieval and output policies. For indirect injection, the useful property is the ability to insert that check between retrieval and prompt assembly.

That flexibility does not mean complete agent coverage by default. AWS documents that guardrails attached to an agent inspect user input and the final answer, but not tool inputs and outputs. Application teams must explicitly add ApplyGuardrail calls within each action group Lambda function to reach it, and they own the configured policy response. A content pass at assembly therefore cannot serve as permission to execute a subsequent tool call.

How Google Cloud Model Armor and NVIDIA NeMo Guardrails cover different parts of the evaluation framework

Google Cloud Model Armor combines document screening with detection for prompt injection, jailbreaks, sensitive data, malicious URLs, and harmful content across Google Cloud or external models. Its managed approach provides broad screening scope. Detection remains probabilistic, however, and the application still owns action policy, authorization, approvals, and recovery. As with Azure, its coverage does not natively extend into tool-call execution.

NVIDIA NeMo Guardrails offers a broader programmable rail surface, including retrieval rails and execution rails around tool calls. Among the options compared, its execution rails offer the most complete programmable coverage of the tool boundary, but only when correctly configured and operated. The adopter must choose models and checks, secure dependencies, host the service, test policies, monitor failures, and validate that custom flows cannot bypass controls. NeMo is fully self-hostable and air-gap compatible, but each rail adds roughly 50–150ms, so using several rails in a synchronous design adds both latency and work to run them.

How Lakera Guard and Meta Llama Prompt Guard 2 approach classifier latency and coverage for high-throughput RAG

For pipelines that retrieve many chunks, the practical question becomes whether a detector can inspect each one without delaying the response excessively. Lakera Guard, now Check Point AI Guardrails, is the runtime layer of Check Point’s AI Agent Security platform. Its SaaS API can scan retrieved content before assembly. It offers sub-50ms classifier latency at hundreds of prompts per second, placing it squarely in the synchronous, per-chunk scanning category. Those figures address production feasibility, but speed alone does not establish coverage of every injection pattern.

Meta Llama Prompt Guard 2 takes the compact-model route, with a model in the tens-of-millions-of-parameters range. Its role is a first-layer detector within a layered architecture. No single tool reliably detects all injection attempts. The nokast-secureRAG research result from October 2026 found that a purpose-built, roughly 0.5B-parameter semantic firewall could outperform general-purpose detectors on detection recall and false-positive rate. That finding supports testing classifiers in retrieval context rather than assuming they work as well there as they do in general detection. Additional layers still impose latency that parallelization can only partly offset.

Why research-level model-layer defenses — fine-tuning and architectural separation — do not substitute for pre-model interception in enterprise RAG

Could a better-trained model remove the need for interception? StruQ, presented at USENIX Security 25, uses structured query isolation, while SecAlign uses preference optimization to reduce attack success at the model layer. Both require the ability to fine-tune the model itself. That excludes enterprise deployments relying on black-box LLMs without fine-tuning access. Even where teams can apply these methods, adversarial tool-hijacking attacks sustain high success rates against both defenses, so their value does not establish sufficiency.

Architectural separation addresses a different part of the problem. Parallax proposes a boundary between reasoning and execution so that protection does not rest solely on natural-language safety instructions within the reasoning model. That approach addresses the danger of compromised reasoning becoming action. It does not make retrieved content trustworthy or replace the need to inspect what enters the context. Enterprises using black-box hosted models can still use retrieval-to-assembly interception to check the pipeline, while execution separation deals with the harm that content detection may fail to prevent.

How continuous vendor AI monitoring closes the gap that point-in-time pre-model interception leaves open

Every runtime check above evaluates content at a particular moment. None alone establishes whether the surrounding vendor AI asset has been modified, misconfigured, or compromised in a way that defeats the check. The asset extends beyond the model itself. For enterprise TPRM, InfoSec, and Legal teams, it includes the retrieval connector, knowledge base ingestion pipeline, embedding model, and prompt assembly logic. DACSI research shows that how well detection works depends on source separation and retrieval-time redaction, so configuration drift affects security as well as administration.

Continuous monitoring complements runtime detection by addressing those changing conditions. It can surface configuration changes, new connector versions, and emerging injection patterns before they reach production. Stateful trust inference research also shows why observations over time are needed when malicious intent is distributed across stages. Dedicated AI risk intelligence platforms help teams see these AI-specific attack surfaces in ways that traditional security and governance tools cannot. Where traditional TPRM assesses vendor risk at onboarding, ongoing assessment follows the model updates, connector changes, and new techniques that can invalidate an earlier judgment. The enterprise control is therefore both a runtime interception boundary and a continuing watch over the pipeline that makes that boundary effective.