An indirect attack is a technique that influences a model through content it consumes rather than through a direct prompt from the attacker. In operational terms, this matters whenever the model reads documents, web pages, tickets, or other external data that can contain hidden instructions.
How Indirect Attacks Work
An indirect attack succeeds by placing malicious or misleading content into a model’s input stream so the model absorbs it as part of the task context. The attacker is not always trying to talk to the model directly; instead, they influence the model through the documents, pages, tickets, or messages it already trusts enough to read.
This makes the attack path fundamentally different from a normal prompt injection attempt. The model may be following instructions from retrieved content, summarising user-supplied text, or processing operational data, which means the hostile instruction can arrive wrapped inside something that looks routine, relevant, or even authoritative.
Why Indirect Attacks Matter in Real Systems
Indirect attacks become important whenever an AI system consumes external or semi-trusted content as part of its workflow. That includes retrieval-augmented generation, helpdesk automation, browser-based agents, workflow assistants, document analysis, and any pipeline where untrusted text can influence the model’s next action or answer.
The security problem is not limited to bad wording. Hidden instructions can redirect the model toward data exposure, unsafe actions, deceptive summaries, or tool misuse. In practice, the attacker is exploiting the boundary between content and control, which is why a system can be compromised without a direct conversational prompt ever being issued.
That boundary becomes especially important in agentic workflows where the model can act on what it reads. The wider the model’s execution authority, the more a hostile document or webpage can shape downstream behaviour if the application does not separate instructions from content.
Common Entry Paths and Abuse Patterns
Indirect attacks often enter through sources that feel operationally safe: email attachments, knowledge bases, issue trackers, shared docs, scraped web pages, chat exports, or customer-submitted text. The attacker benefits when the system treats all retrieved material as equally trustworthy, or when it fails to distinguish between user-facing content and embedded instructions.
One common pattern is instruction smuggling, where hidden text tells the model to ignore higher-priority directions, reveal context, or alter its response policy. Another is data-dependent abuse, where the content is crafted to trigger unwanted tool calls, quote sensitive material, or steer the model into making a false conclusion.
Because these attacks exploit ordinary ingestion paths, detection is difficult. The content can look benign to humans, especially if the harmful part is brief, stylized, encoded, or buried inside a larger legitimate document.
Defensive Boundaries and Control Expectations
Defending against indirect attacks depends on treating consumed content as untrusted input, even when it comes from business systems or user-owned sources. The model should not inherit authority from the content it reads, and the application should keep instructions, retrieved context, and execution privileges visibly separated.
Strong controls usually combine content sanitisation, retrieval filtering, instruction hierarchy enforcement, and tightly scoped tool permissions. When the model can call tools or access data, those actions should be constrained by explicit policy rather than by whatever the last document happened to say.
Teams should also assume that prompt-level protections alone are not enough. If the surrounding workflow allows external text to shape reasoning, then the security boundary must live in the application design, the retrieval layer, and the privilege model around the model itself.
Risk and Threat Considerations
Indirect attacks are risky because they let an adversary influence model behaviour through a path that often looks like normal business content. That can lead to disclosure, policy bypass, false outputs, or unwanted actions, especially when the model has access to tools, files, or downstream systems.
Failure mechanism: The model treats hostile content as trusted context, then follows or incorporates hidden instructions instead of isolating them from the task objective.
Impact: The attacker can manipulate outputs, trigger unsafe actions, or steer the model toward exposing data and abusing connected systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Indirect attacks exploit poisoned context that alters an agent's behavior. |
| ASI02 — Tool Misuse | Indirect attacks can steer an agent into unsafe tool actions through consumed content. | |
| Recommendation — Separate trusted instructions from retrieved content and filter context before agent reasoning. Restrict tool invocation with policy checks that do not rely on model-generated instructions. | ||
| MITRE ATLAS | Adversarial Machine Learning Techniques | ATLAS catalogs AI attack patterns including prompt injection and context poisoning. |
| Recommendation — Map observed abuse paths to ATLAS techniques and harden the retrieval and agent pipeline. | ||
| NIST AI RMF | Govern map measure manage | AI RMF applies to managing risks from AI systems that consume untrusted context. |
| Recommendation — Assess indirect attack exposure in the AI risk inventory and track mitigations through governance. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Indirect attacks rely on hostile content entering the system through trusted inputs. |
| Recommendation — Validate and sanitize model inputs, retrieved text, and uploaded content before use. | ||
Practitioner Guidance
What to watch for: Pay close attention when a workflow lets the model read untrusted or externally sourced text and also grants it execution authority. That combination is where indirect attacks become materially dangerous, because the content layer can start influencing control decisions.
Governance implication: Teams should define which sources may influence model behaviour, which content must be treated as inert data, and which tool actions require explicit policy checks rather than model inference.
Practitioner takeaway: The safest mental model is simple: content can inform the model, but it should never be allowed to command the model.