Skip to main content
Bureau of AI
Category: Adversarial Security

Cross-Domain Prompt Injection

Also known as: XPIA, Indirect Prompt Injection
Simply put

Cross-domain prompt injection is a security attack in which harmful instructions are hidden inside external content, such as a document or a website, that an AI system later reads and processes. Because the AI treats this outside content as part of its instructions, an attacker can cause the system to behave in unintended ways without ever interacting with it directly. It is a specific form of prompt injection that reaches the AI indirectly through the data it consumes rather than through a user's typed request.

Formal definition

Cross-Domain Prompt Injection (XPIA), also referred to as indirect prompt injection, is a security exploit targeting generative AI systems (typically large language models) in which malicious content or prompts are embedded in external data sources (for example, documents or websites) that are subsequently ingested and processed by the model. Unlike direct prompt injection, where an attacker supplies deceptive text as a user input, XPIA delivers the adversarial payload through a separate data domain, causing the model to execute unintended or attacker-controlled behavior when it processes that content. As described in the evidence, this vulnerability has been noted in contexts such as the Model Context Protocol (MCP), where AI systems process content drawn from external or third-party sources. Note: the scope, taxonomy, and mitigations for this threat are still evolving across the industry, and terminology (indirect versus cross-domain) is used with some variation across sources.

Why it matters

Cross-domain prompt injection matters because it breaks a boundary that many AI deployments implicitly rely on: the assumption that instructions come only from a trusted user and that external data is merely inert information to be summarized or processed. When a large language model treats content drawn from a document, website, or other third-party source as if it were part of its instructions, an attacker who can influence that content gains an indirect channel into the system's behavior without ever authenticating, submitting a request, or otherwise interacting with the deployment directly. This expands the effective attack surface to include any data domain the model consumes.

The risk grows as AI systems are wired to autonomously retrieve and act on external content, for example through architectures such as the Model Context Protocol (MCP), where models process content sourced from external or third-party locations. In such settings, a malicious payload embedded in ingested content can cause the model to execute unintended or attacker-controlled behavior. Microsoft's developer guidance published in April 2025 describes indirect prompt injection—also referred to as cross-domain prompt injection or XPIA—as a security exploit targeting generative AI systems, underscoring that this is a recognized concern among major platform providers rather than a purely theoretical one.

For governance and risk functions, the significance is that traditional input-validation controls focused on the user-facing prompt are insufficient on their own, because the adversarial instruction arrives through the data path rather than the user path. The scope, taxonomy, and mitigations for this threat are still evolving across the industry, and terminology is used with some variation across sources, so organizations should treat this as an area requiring ongoing monitoring rather than a settled control set. Governance measures can reduce and manage this risk but should not be presented as eliminating it.

Who it's relevant to

AI security and application engineers
Teams building or integrating generative AI applications—particularly those that retrieve and process external documents, web content, or third-party data through mechanisms such as MCP—need to account for the data path as an attack surface, not just the user-facing prompt. Understanding that ingested content can carry adversarial instructions is central to designing controls that reduce, though do not eliminate, this risk.
Model risk and second-line functions
Risk managers assessing generative AI systems should treat cross-domain prompt injection as a source of operational and security risk arising from how the model consumes external content. Because the threat's taxonomy and mitigations are still evolving, these functions should document residual exposure and avoid representing available controls as fully resolving the vulnerability.
AI governance and policy specialists
Those responsible for oversight policies and acceptable-use standards for AI systems have an interest in how external data ingestion is governed, since XPIA reaches the model indirectly through data rather than through a user request. Policy that addresses only user-input controls may leave the indirect channel unaddressed.
Auditors and assurance reviewers
Reviewers examining generative AI deployments benefit from understanding the distinction between direct and indirect prompt injection so they can evaluate whether controls cover content ingested from external or third-party sources, and can flag where terminology and mitigation practices remain unsettled across the industry.

Inside XPIA

Untrusted content channel
The pathway through which externally sourced data—such as documents, web pages, emails, or retrieved records—enters a model's context. In cross-domain prompt injection, adversarial instructions are embedded in this content rather than typed directly by the user, so the model may treat data as if it were a legitimate instruction.
Instruction-data confusion
The underlying failure mode in which a model does not reliably distinguish between content it should treat as inert data and content it should follow as a command. This blurring across trust boundaries is what makes cross-domain injection possible.
Trust boundary crossing
The 'cross-domain' element: the injected instruction originates in one domain or system (for example, a third-party website or a shared file) and takes effect in another (the model's execution context or connected tools). The crossing of these boundaries is central to the attack's characterization.
Downstream action surface
The tools, integrations, or agentic capabilities the model can invoke—such as sending messages, calling APIs, or reading and writing data. The severity of an injection typically scales with what actions the model is permitted to take on the attacker's behalf.
Payload and trigger
The embedded adversarial text (payload) and the conditions under which the model ingests and acts on it (trigger), which may involve retrieval, summarization, or automated processing of the untrusted content without a human reviewing it first.

Common questions

Answers to the questions practitioners most commonly ask about XPIA.

Is cross-domain prompt injection the same as a model performance problem that can be fixed by retraining or fine-tuning?
No. Cross-domain prompt injection is a security and input-integrity concern arising when adversarial instructions enter the model through content pulled from another domain or source, not a degradation in the model's predictive quality. Retraining or fine-tuning addresses how well a model performs on its intended task; it does not, on its own, reliably remove the model's susceptibility to following injected instructions embedded in untrusted content. Treating it purely as a performance issue typically misdirects controls away from input handling, source trust boundaries, and output monitoring, which is where the risk is commonly managed.
Does having AI governance policies in place mean cross-domain prompt injection is already controlled?
Not necessarily. Governance policies establish accountability, oversight, and expectations, but they are organizational measures rather than technical controls. Cross-domain prompt injection is typically managed at the level of specific technical and operational safeguards, and governance and these operational controls are related but distinct. Governance can require that such safeguards exist and be tested, yet policy documents alone do not intercept injected instructions. As with risk controls generally, these measures reduce or manage the risk rather than eliminate it, and residual risk commonly remains even under a mature governance program.
Where in a data or content pipeline is cross-domain prompt injection most commonly guarded against?
In many implementations, controls are placed at the points where content crosses a trust boundary, such as when the system ingests external documents, web pages, retrieved knowledge, or third-party data into the model's context. Practitioners often distinguish trusted from untrusted sources and apply handling, sanitization, or isolation to the latter. The specific placement varies by architecture, and there is no single required control point across all frameworks; the appropriate boundary depends on where untrusted content can influence model instructions in a given system.
How can teams test whether their safeguards against cross-domain prompt injection are effective?
Testing is commonly approached through adversarial evaluation, red-teaming, and scenario-based exercises that attempt to embed instructions in the kinds of external content the system consumes. Because such testing verifies whether controls behave as designed and validates whether they are appropriate for the intended use, teams often treat verification and validation as distinct activities. Results are typically monitored over time, since new injection techniques emerge and prior testing does not guarantee coverage of future methods. The scope and rigor appropriate to a given system depend on its risk profile and use context.
What roles across the lines of defense are typically involved in managing this risk?
Responsibilities are often distributed across the three lines of defense as commonly framed. The first line, which builds and operates the system, typically implements input handling, source controls, and monitoring. The second line commonly provides independent challenge, risk assessment, and policy oversight. The third line, internal audit, may provide assurance that the controls exist and function as intended. The precise allocation varies by organization, and these lines are conceptual roles rather than a universally mandated structure for every enterprise.
How should residual risk from cross-domain prompt injection be documented and monitored?
After controls are applied, some residual risk typically remains, and this should be distinguished from the inherent risk present before controls. Many organizations document the assumptions, the controls in place, known limitations, and what remains out of scope, then monitor for new attack patterns and control failures on an ongoing basis. Because injection techniques evolve, monitoring is generally treated as a continuing activity rather than a one-time assessment, with periodic reassessment of whether controls remain adequate for the current threat and use context.

Common misconceptions

Cross-domain prompt injection is the same as jailbreaking.
The two are commonly distinguished. Jailbreaking typically refers to a user deliberately crafting input to bypass a model's own guardrails, whereas cross-domain prompt injection generally involves adversarial instructions arriving through untrusted external content, often without the end user's awareness or intent. They can overlap but are not interchangeable.
Input filtering or a content moderation layer eliminates the risk.
Filtering can reduce exposure but should not be described as eliminating risk. Adversarial instructions can be obfuscated, encoded, or embedded in ways that evade pattern-based controls, and the core instruction-data confusion may persist. Controls here are risk-reducing measures, not guarantees.
It only matters for chatbots that talk directly to end users.
The exposure is often greatest in systems that automatically ingest external content—such as retrieval-augmented pipelines or agentic workflows with tool access—where no human reviews the untrusted content before the model acts on it. Direct user-facing chat is only one of several affected contexts.

Best practices

Treat all externally sourced or retrieved content as untrusted data by default, and design prompts and system architecture so that such content is not interpreted as authoritative instructions.
Constrain the model's downstream action surface by applying least-privilege principles to connected tools, integrations, and agentic capabilities, so that a successful injection has limited consequences.
Insert human review or explicit confirmation steps before the model performs high-impact or irreversible actions triggered by content it processed automatically.
Layer defenses—such as input handling controls, output validation, and monitoring—rather than relying on any single filter, recognizing that these measures manage rather than remove the risk.
Log and monitor model interactions with untrusted content sources so that anomalous instruction-following behavior can be detected and investigated.
Test systems against adversarial and obfuscated injected content across the specific channels and trust boundaries relevant to your deployment, since exposure is context- and integration-dependent.