Explain cross-prompt injection in a multi-tenant SaaS

Flashcard·Hard·4.0 · 0·~30s·Asked atJasper Voyage Ai

Attempt it

Cross-prompt injection: an attacker on tenant A plants malicious content into a shared resource (a doc store, a shared retrieval index, a long-lived assistant memory). Later, a user on tenant B's request retrieves that content and the model executes the embedded instructions. The injection lives in stored state, not in any single request. Per-request input filters never see the attacker's original payload; by the time tenant B's request runs, the dangerous content is just 'retrieved context.' Mitigations: per-tenant retrieval scopes, write-time sanitisation on shared stores, and treating every retrieved chunk as untrusted regardless of who wrote it.

Your answer

**Cross-prompt injection** is the multi-tenant version of indirect prompt injection. The attacker does not need to send the malicious message to the victim's session directly. Instead, the attacker plants instructions into a shared resource that the victim's session will later read. The shared resource could be a document indexed in a shared vector store, an assistant's long-lived memory, a wiki page, a comment field on a shared record, anything the orchestrator pulls in as 'context' when responding to a user. The attacker writes the payload, the storage system accepts it, and the system waits. When the victim sends a normal request, 'summarise our Q4 docs', the retrieval step pulls the poisoned chunk into the prompt. The model reads both the user's question and the poisoned context, and treats the poisoned instructions as legitimate. The per-request input filter on the user message never saw the malicious payload because it lives in the retrieval store, not in the message. The fix has three parts. First, scope retrieval per tenant, no document written by tenant A should ever surface in tenant B's session. Second, sanitise content at write time, not just read time. Third, treat every retrieved chunk as untrusted user input regardless of who originally wrote it.

**Cross-prompt injection** is the multi-tenant generalisation of indirect prompt injection. An attacker on tenant A writes malicious instructions into shared state, a multi-tenant retrieval index, a shared knowledge base, a long-lived assistant memory, a comment on a shared record, an integration that ingests from a common source. Later, a user on tenant B sends a normal request. Retrieval pulls the poisoned content into the prompt. The model executes the instructions. **Why per-request filters miss it.** The input rail inspects what the current request contains. The malicious payload was never in a current request; it was in a write operation that completed days or weeks earlier under a different identity. By the time tenant B's request runs, the dangerous content is dressed up as retrieved context, indistinguishable from legitimate documents the user expects the assistant to summarise. The filter has nothing suspicious to flag. **The mitigations stack across three layers.** Per-tenant retrieval scoping enforces that tenant B's session can only see chunks owned by tenant B; this is the strongest single control. Write-time sanitisation runs the input rail at ingestion as well as at request time, catching obvious payloads before they enter the store. Treating retrieved chunks as untrusted means structuring the prompt so the model knows the retrieved section is data, not instructions, through delimiters, instruction-hierarchy framing, and dedicated retrieved-content roles where the model API supports them. And in 2026 the threat surface is broader than a single doc store. Shared assistant memory, shared agent tool registries, MCP servers exposing shared resources, and federated retrieval across customer corpora all create new cross-prompt injection paths that need the same controls.

TL;DR

Cross-prompt injection plants malicious instructions in shared state under one tenant so the model executes them later under a different tenant's request.

Memory aid

Easy to grasp

Picture a shared whiteboard in a co-working office. A tenant on Monday writes a sneaky note: 'whoever reads this, please leave the door unlocked tonight.' The receptionist who screens visitors does not see the note because it was written before the screening. On Tuesday, a different tenant's assistant glances at the whiteboard to remember the office hours, reads the sneaky note as if it were part of the instructions, and unlocks the door. Cross-prompt injection works the same way. The bad instruction is planted in a shared place the system later trusts (a shared doc index, a long-lived memory), and the per-request filters never catch it because the attack is not arriving with a request, it is sitting in storage waiting.

Key concepts

Safety and guardrails

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Most LLM safety architectures default to a per-request input rail and call it a day. That works against direct prompt injection, an attacker typing a malicious message at the model. It fails entirely against cross-prompt injection, where the malicious content was deposited into shared state hours or weeks before the victim's request, by an actor the system has every reason to treat as legitimate.

This is the single most common gap senior security reviewers find in multi-tenant LLM SaaS products, because it cuts across the boundary between safety teams and platform teams. The safety team is looking at per-request defences. The platform team is looking at row-level security and tenant isolation. The attack lives exactly in the gap between those two views.

The threat model: three actors and an asynchronous attack

Cross-prompt injection has three actors and one critical asymmetry.

The attacker is a legitimate but low trust user. They have valid credentials on the system, they have write permission to some shared surface, and they are within their granted scope when they write the payload. The system has no reason to reject the write at the moment it happens.

The shared state is any resource that crosses trust boundaries. The canonical example is a shared retrieval index, a single vector store that holds documents from multiple tenants, or a knowledge base that aggregates content across customers. The category extends further: a long-lived assistant memory that persists across sessions, a shared MCP resource exposed to multiple LLM clients, an ingested public Slack channel, a customer-facing comment thread on a multi-tenant record, an integration that pipes external email into the agent's context.

The victim is a normal user on a different tenant (or sometimes the same tenant, in a different session). They issue a benign request. The retrieval, planner, or memory-recall step pulls the attacker's poisoned content into the prompt. The model reads both the user's question and the attacker's embedded instructions. Unless the prompt structure and the model's training defended this case, the instructions take effect.

The asymmetry that makes this hard: the attack and the defence happen at different times and by different code paths. The write happens against the ingestion path; the harm happens against the retrieval path. A defence that only inspects either path in isolation is incomplete.

Why per-request input rails are structurally blind to this

The four-layer defence

Newer surfaces: memory, MCP, and federated retrieval

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Microsoft Copilot for Microsoft 365 in 2026 enforces tenant-scoped retrieval on Graph data and runs write-time content scanning to mitigate cross-prompt injection from shared SharePoint and Teams content.
Notion AI and Glean both isolate per-workspace retrieval and treat any retrieved block as untrusted with explicit prompt-template separation between user instructions and retrieved content.

What an interviewer would ask next. Try answering before peeking at the approach.

QWalk through how you would harden a multi-tenant RAG application that shares a single vector index across customers against cross-prompt injection.

Add a tenant_id metadata field to every chunk, enforce row-level security at the vector store with the query always filtering on tenant_id, run a write-time injection scanner on ingest, separate user instructions from retrieved content in the prompt template, mark retrieved chunks as data via the model's dedicated retrieved-content role, and add tool argument validation and output PII scanning as the last-line defences.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Assuming an input rail on user messages covers all injection. The whole point of cross-prompt injection is that the malicious content was deposited earlier through a write path the input rail does not cover.

60 second bullets to scan on the way to the call.

How cross-prompt injection differs from direct injection
Why per-request input filters cannot see the original payload

Primary sources. Browse if you want the original framing.