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.