Cross-Prompt Injection in Multi-Tenant AI Applications
How shared context, memory, and tool access create cross-tenant injection risk, and which runtime controls close the gap that session-level defenses leave open.
What Cross-Prompt Injection Is, and Is Not
Prompt injection describes attacker-controlled instructions that cause a large language model to act outside the intent of its legitimate user. OWASP's LLM risk guidance separates direct injection, where the attacker supplies the malicious input themselves, from indirect injection, where the model ingests untrusted content from a document, tool output, or other external source and follows instructions embedded in it. Academic research on indirect prompt injection has demonstrated that this channel, retrieved or processed content rather than direct user input, is sufficient to redirect an LLM-integrated application's behavior.
Cross-prompt injection applies this same mechanism across a tenant boundary in a multi-tenant application. Instead of one user's session being manipulated by content that user retrieved, one tenant's input, cached context, or ingested data influences the model's behavior in a different tenant's session. No source reviewed treats cross-prompt injection as a formally standardized term with its own taxonomy separate from indirect prompt injection. It is more accurate to describe it as indirect prompt injection realized through multi-tenant architecture, where the trust boundary that fails is between tenants rather than between a session and an external document.
Why Single-Session Defenses Do Not Address This
Standard prompt injection defenses, input filtering and output moderation, operate within the boundary of a single user or session. They are designed to catch malicious instructions as they enter or leave one conversation, but they do not enforce separation between concurrent tenants sharing a model instance, a context store, or a tool integration.
A filtering rule that correctly blocks a malicious instruction in one tenant's input says nothing about whether that tenant's cached context, retrieved documents, or tool-call history can leak into another tenant's processing window. This is the core reason cross-prompt injection is a distinct engineering problem rather than a variant that existing session-level controls already cover.
Governance frameworks reinforce this gap rather than close it directly. NIST's AI Risk Management Framework directs organizations to assess risk arising from shared components and third-party integrations, which applies to multi-tenant AI deployments in principle but was not written specifically for LLM tenancy. General data segregation expectations under broader compliance frameworks address tenant data isolation as a data-at-rest and access-control concern, not as a model context or tool-call leakage concern. Organizations currently have to adapt these general frameworks rather than apply a dedicated cross-tenant AI standard, because none currently exists in the guidance reviewed.
Where Cross-Tenant Exposure Originates
Cross-prompt injection is not a flaw in a specific model. It is a consequence of how multi-tenant systems share infrastructure without enforcing tenant separation at the points where context and actions are assembled.
Shared Model Instances
Concurrent tenant requests processed without strict context segmentation.
Shared Retrieval Indices
Pooled RAG stores where one tenant's ingested content can surface in another tenant's session.
Shared Tool Credentials
Common service accounts that extend a single injection's blast radius across tenants.
Context or Cache Reuse
Session state carried across requests without tenant scoping.
Architectural Conditions That Enable Cross-Tenant Injection
These conditions typically combine in production systems. Understanding them as a set helps teams map exposure points rather than treating injection as a single input-sanitization problem.
-
Unscoped context assembly
Model prompts are built from memory, history, or retrieved content without a hard tenant boundary at assembly time.
-
Shared retrieval surfaces
RAG indices and document stores mix tenant corpora, so one tenant's ingested instructions can be retrieved into another tenant's window.
-
Tool authorization after the fact
Tool calls inherit ambient credentials or upstream trust instead of re-checking tenant-scoped authorization immediately before execution.
-
Weak attribution and audit paths
When logs cannot attribute context sources and tool actions to a tenant, cross-tenant influence is difficult to detect or investigate.
Runtime Controls That Mitigate Cross-Tenant Injection
Because cross-prompt injection exploits shared infrastructure rather than a single model's input handling, mitigation has to be enforced at runtime, at the points where context is assembled and actions are authorized.
- Enforce tenant identity on every context assembly path, including memory stores, caches, and conversation history.
- Segment retrieval indices and permissions per tenant so RAG cannot surface another tenant's content.
- Authorize tool calls immediately before execution with tenant-scoped checks independent of upstream input filtering.
- Avoid shared service accounts for agentic tool integrations; bind credentials and capability grants to tenant scope.
- Log context sources, retrieval hits, and tool invocations in a way that supports attribution of suspected cross-tenant events.
Evaluation Questions for Multi-Tenant AI Architecture
Use these questions when reviewing an existing deployment or design review checklist. Affirmative, evidence-backed answers indicate stronger tenant separation at the model interaction layer.
- How is context, memory, or session state isolated between tenants at the model interaction layer?
- What authorization checks occur immediately before a tool call executes, and are they tenant-scoped independent of upstream input filtering?
- If retrieval-augmented generation is used, are retrieval indices and permissions segmented per tenant?
- What credentials or service accounts do agentic tool integrations use, and are they shared across tenants?
- What logging and audit capability exists to attribute and investigate a suspected cross-tenant injection event?
Common Questions
Is cross-prompt injection a formally recognized security category?
Not as a standalone taxonomy. Established frameworks such as OWASP's LLM Top 10 and MITRE ATLAS describe indirect prompt injection as the underlying mechanism. Cross-prompt injection is best understood as that mechanism applied specifically across a multi-tenant boundary.
Are there documented production incidents of cross-tenant prompt injection?
No named production incident of cross-tenant prompt injection was identified in the sources reviewed for this period. The risk is grounded in established indirect prompt injection research and multi-tenant architectural analysis rather than a confirmed public breach.
How is this different from a data leakage bug in a RAG system?
A RAG data leakage bug typically exposes retrieved content directly. Cross-prompt injection is broader: it describes injected instructions from one tenant altering another tenant's model behavior, permissions, or tool actions, not just exposing raw data.
Cross-prompt injection is a security risk specific to multi-tenant AI applications where shared model instances, context windows, memory stores, or tool integrations allow manipulated input from one tenant to influence outputs, permissions, or actions affecting another tenant. It is best understood as indirect prompt injection applied across a tenant boundary, and it requires tenant-scoped runtime controls that standard single-session prompt injection defenses do not provide.
Bring Runtime Governance to Multi-Tenant AI Deployments
Cross-prompt injection is an architectural risk that upstream input filtering cannot fully address. Runtime enforcement of tenant identity, tool-call authorization, and audit logging closes the gap that shared context and tool access leave open.
Talk to an Expert