How do indirect prompt injections reach agent workflows?

How indirect prompt injections enter an agent workflow

Indirect prompt injection works because the attack rides inside ordinary content the agent is already meant to process. The malicious instructions are embedded in emails, documents, web pages, tickets, or tool output, then later reinterpreted by the model as something worth following. Once that happens, the agent can carry attacker instructions into planning, retrieval, or tool use without a clear boundary between trusted directives and untrusted text.

That makes the entry point less about the prompt itself and more about the workflow design. If the agent reads external or user-controlled content and can act on it, the content can become an instruction source unless the system explicitly marks it as data only. The practical security problem is not just reading the wrong text, but letting that text influence decisions that should have been reserved for system policy or operator intent.

In agentic environments, this is especially dangerous when the workflow blends summarisation, reasoning, and execution. An attacker does not need direct prompt access if they can place instructions into a source the agent trusts enough to inspect. The point of entry is often the same path the agent uses for useful work, which is why indirect prompt injection is so effective in browsing, email triage, document analysis, and tool-assisted automation. NHIMG’s Prompt Injection Guide covers the core patterns behind direct, indirect, and multimodal prompt attacks.

Why agent workflows are exposed at the trust boundary

The weakness appears when the workflow treats all model-visible text as equally eligible for reasoning. Emails, web pages, and retrieved documents often contain mixed content, some of it benign, some of it attacker-controlled, and the agent may not reliably distinguish between them. If the orchestration layer passes that content into planning context, the model can absorb instructions that were never meant for the operator or for downstream tools.

That becomes worse when the agent has tool permissions, write access, or the ability to chain actions. A malicious instruction hidden in content can nudge the model toward actions that look normal in isolation but are unsafe in sequence, such as copying sensitive material, opening a link, or altering a record. This is why indirect prompt injection is not just a model-quality issue, it is a workflow integrity issue that can turn content ingestion into action execution. NHIMG’s OWASP LLM Top 10 LLM01 Prompt Injection Guide explains how to assess and contain this class of attack.

A useful way to think about the boundary is that retrieval, browsing, and tool output are untrusted inputs even when they are operationally necessary. If the agent cannot preserve that distinction, then hidden instructions can survive long enough to influence summarisation, planning, or function calls. That is why prompt injection defenses have to be built into the workflow, not added only at the final prompt template.

What reduces the attack path in practice

Defence starts by separating untrusted content from system instructions and by making the model’s role explicit. Content filtering helps, but it is only one layer, because the most important control is preventing untrusted text from being treated as authority. Tool permissions should also be scoped tightly, so a successful instruction slip does not automatically become a high-impact action.

Operationally, the strongest controls are the ones that reduce blast radius when the model misreads content. That usually means limiting what the agent can do by default, requiring confirmation for sensitive actions, and avoiding workflows where the model can freely mix external content with privileged context. For browsers and computer-use agents, this is particularly important because the same session that reads a page may also be able to act inside authenticated environments. NHIMG’s Browser and Computer-Use Agent Security Guide focuses on those session and scope controls.

When the workflow must process potentially hostile content, the safer pattern is to constrain what the model may consume, what it may decide, and what it may execute. That is more effective than trying to detect every malicious instruction after the fact, because indirect prompt injection is designed to look like ordinary text until the agent acts on it.

Practitioner Guidance

What to verify: Confirm which inputs the agent can read before it plans or calls tools, and treat any external, retrieved, or user-supplied content as untrusted by default. If the workflow cannot preserve that separation, the attack surface is still open even if the prompt template looks clean.

Implementation sequence: First isolate system instructions from retrieved content, then narrow tool scope, then add filtering and human confirmation for sensitive actions. Do not reverse that order, because filtering alone will not stop a model from reasoning over hostile instructions that are already in context.

Common mistake: Teams often assume the problem is solved once they block obvious jailbreak phrases. Indirect prompt injection usually succeeds because the payload is embedded in legitimate-looking prose, so the real control is policy separation and permission containment, not keyword blocking.

Practitioner takeaway: If an agent can read it and later act on it, then the content path is part of the control plane. The safest design is to make untrusted content visible to the model for analysis, but never authoritative for action without an explicit security boundary.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Security Guide
• Reach
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?