Mitigating Indirect Prompt Injection in Multi-Tenant RAG Pipelines

A retrieval-augmented generation (RAG) system reads documents it did not write. If one of those documents contains instructions, the model may follow them. That is indirect prompt injection: the attacker never talks to your AI system, they leave text where it will be retrieved, and wait. In a multi-tenant product the text can come from another customer, a shared inbox or any web page your pipeline fetches.

This insight is part of my enterprise guide to defending against AI-enabled attacks. It covers the input boundary of the Deterministic AI Boundary Model: how to stop retrieved content from gaining the authority of an instruction, and what the research says about the defences teams usually reach for first.

What is indirect prompt injection in a RAG pipeline?

Indirect prompt injection is an attack in which instructions hidden in retrieved content (a document, email, web page or tool result) are treated by the model as if they came from the user or the developer. The model cannot reliably tell data from instructions, because both arrive as text in one context window.

The attack was first set out in detail by Greshake and colleagues in 2023, who planted instructions in content likely to be retrieved and showed them working against real LLM-integrated applications, including Bing's GPT-4-powered chat.^[1] Their key observation still frames the problem: LLM-integrated applications blur the line between data and instructions. Once retrieved text can steer the model, it can steer whatever the model is allowed to do, from changing an answer to deciding which APIs are called.

OWASP lists prompt injection first in its 2025 Top 10 for LLM Applications, and defines the indirect form as the model accepting input from external sources such as websites or files.^[2] It is not a hypothetical. A 2026 crawl of 1.2 billion URLs found 15,300 validated injection attempts on 11,700 pages, about 70% of them in HTML that a human visitor never sees, such as comments and metadata.^[3] Most were aimed at crawlers, search pipelines and support agents, not at people.

Why does multi-tenancy raise the stakes?

In a multi-tenant RAG system, one party's content is retrieved into another party's session. An injection planted by one customer, employee or email sender can therefore act with the privileges of whoever's query retrieves it, which turns a content problem into an authorisation problem.

The ConfusedPilot study showed this inside an enterprise copilot: malicious text in a document that the RAG system retrieved corrupted the answers other employees received, and the authors showed how that could spread misinformation into business operations.^[4] The model became a confused deputy, using its own access on behalf of someone who should not have had it.

Two further findings matter for anyone running shared knowledge bases. First, an attacker does not need luck to get retrieved. Chang and colleagues split the malicious text into a fragment optimised to be retrieved and a fragment carrying the attack, and achieved near-100% retrieval across 11 benchmarks and 8 embedding models, at as little as US$0.21 per targeted query. In their end-to-end test, one poisoned email led GPT-4o to exfiltrate SSH keys in over 80% of attempts in a multi-agent workflow.^[5] Second, shared state goes wrong even without an attacker: in agents serving several users from one knowledge layer, ordinary interactions produced cross-user contamination in 57% to 71% of cases.^[6]

The design lesson is the one Bhatt and colleagues argue, from an approach now deployed in Microsoft Copilot Tuning: content used in retrieval or generation must be authorised for every user involved in the interaction, and that check must be deterministic.^[7] Tenant separation in the index is covered in detail in tenant isolation in vector databases.

Do spotlighting and delimiters stop indirect prompt injection?

They reduce it, sometimes sharply, against attackers who do not know they are there. They do not stop an attacker who adapts, so treat them as a layer that lowers noise, not as a security boundary.

Spotlighting, proposed by Hines and colleagues, marks retrieved text so the model can tell where it came from.^[8] It comes in three forms, and the reported results differ a great deal.

These are useful results, and spotlighting is cheap to deploy. But note what was tested: models from 2023, and attacks that did not know the defence was there. The authors themselves say defenders must assume the system prompt has leaked, and that spotlighting is not perfectly secure.

The literature on adaptive attacks is less forgiving. Zhan and colleagues took eight published defences against indirect prompt injection and bypassed every one with attacks tuned to the defence, with success rates consistently above 50%.^[9] AutoDojo found the same pattern with a cheap black-box attacker: against a filter that blocked every static injection, adaptive injections succeeded 28% of the time overall and 64% of the time on tasks where the user delegates the choice of action to retrieved content.^[10] On those tasks the injection does not need to look like an instruction at all; it can pose as ordinary data. Defences that hunt for instruction-like text cannot see it.

Defences aimed at retrieval itself fare no better. Query paraphrasing, perplexity filtering and token masking each gave small early gains that disappeared once the attacker adapted; simply repeating the malicious text pushed its perplexity below that of clean documents.^[5] A 2026 paper by Abdelnabi and Bagdasarian goes further, arguing that an adversary can always build a context in which a blocked flow looks legitimate.^[11] That is an argument, not yet a proof, but it points the same way as the measurements.

My view: keep spotlighting, delimiting and detection, because they cut the volume of crude attacks and cost little. But design as if they will fail, because against a determined attacker the evidence says they will.

Where should the privilege boundary sit?

Outside the model, between what the model proposes and what actually happens. Retrieved content should be able to inform an answer but never confer authority to act; that rule is enforced in code the model cannot instruct.

In the Deterministic AI Boundary Model, indirect prompt injection is a failure of the input boundary: untrusted content gains the authority of an instruction. Spotlighting and classifiers sit at Level 1 (probabilistic). Level 2 means the authority to act comes only from the user's request and the application's own policy, and is checked by a deterministic component outside the model's context. Level 3 adds testing against adaptive attackers and logs that show why each action was allowed.

The clearest research example of Level 2 is CaMeL, from Debenedetti and colleagues.^[12] It derives the plan of actions from the trusted user query only, so untrusted data can never change which steps run, and it attaches capabilities to data so that policies are enforced when tools are called. In the AgentDojo benchmark^[13] it completed 77% of tasks with provable security, against 84% for an undefended system. That gap is the price of the boundary, and it is smaller than many teams expect.

CaMeL is also candid about its limits, which apply to any design of this kind. It does not stop attacks that only change text without changing actions or data flows, such as a summary distorted to mislead the reader or a phishing link inserted into an answer, and the authors found side channels that can leak information.^[12] A boundary contains what the model can do; it does not make what the model says trustworthy.

For a RAG product, the practical form of this is a provenance policy enforced by the gateway that sits in front of every tool. A sanitised example:

{
  "policy": "rag-provenance-v1",
  "sources": {
    "user_turn":        { "trust": "principal", "can_authorise": ["tools_in_task_scope"] },
    "tenant_documents": { "trust": "data",      "can_authorise": [] },
    "email_bodies":     { "trust": "untrusted", "can_authorise": [] },
    "web_results":      { "trust": "untrusted", "can_authorise": [] }
  },
  "tools": {
    "send_email": {
      "recipient_from": ["user_turn", "tenant_directory"],
      "external_recipient": "requires_human_approval",
      "body_may_include": "data the requesting user is authorised to read"
    },
    "fetch_url": {
      "url_from": ["user_turn"],
      "allowed_hosts": ["docs.example.com"]
    }
  },
  "on_violation": { "action": "block", "log": ["proposed_call", "source_ids", "policy_rule"] }
}

The model never holds the credentials for these tools; the gateway does. Least privilege for the agent itself is covered in securing AI agent tool calling.

How do you validate model output before it can act?

Treat every model output as untrusted input to the next system. Validate it against a strict schema, check where each argument came from, and block output channels that can carry data out on their own.

OWASP's mitigations for prompt injection include defining and validating expected output formats, least-privilege access, segregating external content and human approval for high-risk actions.^[2] In practice that means four checks, all deterministic:

1. Schema. Tool calls must match a strict JSON schema: known tool, typed arguments, no free-form fields where a constrained value will do.
2. Provenance. Arguments that could only have come from retrieved content (a recipient address, a URL, an account number) are rejected unless the policy allows that source. This is the check spotlighting cannot make.
3. Rendering. Any output that makes a network request on the reader's behalf, such as an automatically loaded image or a link preview, can carry data out. Render model output as text unless a host is on an allow-list.
4. Consequence. State-changing or external actions above a threshold go to a person, through an interface outside the model's context, so the model cannot pre-write the approval.

A position paper on system-level defences makes the same point from the other side: where a learned model must still make a security decision, the system should strictly limit what that model can see and decide.^[14]

How should you test these defences?

Test with an attacker who knows the defence and adapts to it, on tasks where the user delegates decisions to retrieved content. Measure what the attacker can make the system do, not just how often the detector fires.

Static test sets flatter defences. Liu and colleagues built a common benchmark (5 attacks, 10 defences, 10 models, 7 tasks) because earlier work was limited to case studies,^[15] and a later critical evaluation found that published defences were less successful than reported once tested against adaptive attacks and checked for lost utility.^[16] AutoDojo's results above show why: the same defence that scores 0% on a static benchmark can let through most adaptive attacks on open-ended tasks.^[10]

A credible test of a RAG system therefore covers: poisoned documents optimised to be retrieved, not just planted; an attacker who has read your system prompt; tasks where the user says "handle this" rather than naming the action; and, for each success, the exact action taken and the data exposed. The audit steps are set out in the AI red-teaming audit checklist for the OWASP LLM Top 10.

My view: the useful question for a board is not "do we detect prompt injection?" but "if an injection succeeds, what is the worst thing our AI system can do, and how would we know?" The answer should come from the gateway's policy and logs, not from the model.