Prompt injection targets the model directly through the user prompt. Indirect prompt injection hides malicious instructions inside data the model later reads from a trusted source, such as a form submission or knowledge base. Indirect attacks are more dangerous in agentic systems because the malicious content can travel through normal workflows before it is executed.
How prompt injection differs from indirect prompt injection
Both attacks try to steer a model into following malicious instructions, but they arrive through different paths and create different trust assumptions. Prompt injection is delivered directly in the user prompt. Indirect prompt injection is embedded in content the model later consumes, so the attack can ride through a trusted workflow before it reaches the model.
The distinction matters because direct attacks are usually visible at the point of input, while indirect attacks exploit the fact that models often read emails, tickets, documents, web pages, or database fields as if they were ordinary data. That makes indirect injection harder to spot, easier to distribute, and more likely to affect systems that automatically ingest outside content.
When people use the term loosely, they often miss the operational difference: direct prompt injection is a conversation-time problem, while indirect prompt injection is a data-pipeline and workflow problem as well as an AI problem. The second case is especially important once a model has tools, memory, or downstream actions, because the malicious instruction may not be executed until after it has passed several normal control points.
Why indirect prompt injection is usually more dangerous
Indirect prompt injection is more dangerous because the malicious text can inherit the credibility of the source channel. A form submission, knowledge base entry, support ticket, or retrieved document may look like routine business data, so the model and surrounding application may process it with less scrutiny than a user-typed prompt. In an agentic workflow, that hidden instruction can then influence retrieval, summarisation, tool use, or action selection.
It also changes the blast radius. One poisoned source can affect many sessions, many users, or many agent runs if it is reused by search, retrieval, or shared context. That is why indirect prompt injection belongs in the same family as prompt injection, but it demands stronger controls around ingestion, isolation, and action gating.
For a broader model of these attack paths and defences, the Prompt Injection Guide explains direct, indirect, and multimodal variants, along with layered mitigations.
What practitioners should check in real systems
Start by asking where untrusted text can enter the model's context. The risky paths are not limited to chat boxes; they include retrieved documents, support content, web pages, OCR output, email, tickets, and copied fields from upstream systems. If the model can read it, the attacker may be able to place instructions inside it.
Then separate reading from acting. A model can inspect untrusted content, but it should not be able to treat that content as instruction without passing policy checks, permission checks, and output validation. This matters most where the model can call tools, trigger workflows, or expose data from systems the original author of the content never had access to.
Several NHIMG case studies show the pattern in practice, including direct and indirect attacks against assistants and agents such as EchoLeak (Microsoft 365 Copilot) 2025, ForcedLeak (Salesforce Agentforce) 2025, and Sentry MCP Agentjacking 2026.
Risk and Threat Considerations
Indirect prompt injection is dangerous because it turns ordinary content into an attack carrier. The main failure mode is that the model or agent treats retrieved or submitted data as if it were instruction-safe, then executes the hidden directive through tools, memory, or workflow automation.
Failure mechanism: Malicious instructions are embedded in content that passes through trusted ingestion, retrieval, or context-building steps, then become actionable once the model reads them in a privileged workflow.
Impact: The result can be data disclosure, unauthorised actions, corrupted outputs, or delegated abuse of tool access, especially when the same poisoned content is reused across sessions or users.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | Indirect prompt injection can redirect agent goals through hidden instructions. |
| ASI02 — Tool Misuse | Injected instructions can steer tools or workflows into unsafe actions. | |
| ASI03 — Identity & Privilege Abuse | Prompt injection can abuse delegated authority and privileged tool access. | |
| Recommendation — Lock agent goals and gate high-impact actions against untrusted input. Restrict tool invocation to policy-approved actions and inputs. Scope agent privileges tightly and separate reading from acting. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Injected instructions can drive sensitive workflows through exposed APIs. |
| Recommendation — Protect sensitive flows with explicit authorisation and step-up checks. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Prompt injection is fundamentally unsafe instruction handling from untrusted input. |
| Recommendation — Validate and constrain untrusted inputs before they reach model context. | ||
Practitioner Guidance
What to verify: Verify whether any untrusted source can influence system prompts, retrieved context, tool arguments, or action selection. If the answer is yes, treat the path as an injection surface even when the source looks benign.
Decision rule: If the content can reach a privileged model context, do not rely on provenance alone. Require instruction isolation, explicit action approval for high-impact steps, and output controls that block the model from turning embedded text into unauthorised behaviour.
Practitioner takeaway: Direct prompt injection is a prompt-channel problem, but indirect prompt injection is a workflow-trust problem, so the real defence is to keep untrusted content from becoming executable instruction.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org