They fail because many defences evaluate each turn in isolation, while the attack often unfolds across several steps. An injected instruction can sit in retrieved content, survive summarisation, and only become dangerous when the agent later calls a tool. Multi-step workflows need context-aware verification, not only input screening.
Why This Matters for Security Teams
Prompt-injection defences often fail in multi-step AI workflows because the control point is too narrow. A single user prompt may look harmless, yet the workflow can later retrieve untrusted content, summarise it, and hand that content to a tool with real authority. That means the security boundary is not the prompt itself, but the entire chain of context, reasoning, and action. This is why the issue belongs in broader AI governance and NHI control design, not just content filtering. NIST’s NIST Cybersecurity Framework 2.0 remains useful here because it pushes teams to think in terms of risk treatment across the full system, not isolated inputs.
NHI Management Group research on the DeepSeek breach shows how exposed data and embedded secrets can amplify downstream abuse once an attacker gains a foothold in the workflow. The same pattern appears in agentic systems: one poisoned step can persist long enough to affect later reasoning, retrieval, or tool calls. Security teams usually miss this because prompt filters create a false sense of containment while the workflow still trusts inherited context. In practice, many security teams encounter injection only after an agent has already chained actions through a tool call, rather than through intentional testing of the full workflow.
How It Works in Practice
Multi-step workflows fail when each stage is treated as independent and trustworthy. A typical pipeline may ingest a document, chunk it into retrieval context, summarise selected passages, and then let an agent decide whether to search, email, query a database, or execute code. If malicious instructions survive any of those steps, the agent can later treat them as operational guidance instead of untrusted input. The right control is not just prompt sanitisation. It is runtime verification of intent, context, and allowed action.
Current guidance suggests layering controls across the workflow:
- Classify external content as untrusted at ingestion, not only at the final prompt.
- Use context-aware policy checks before tool execution, especially when the agent can write, send, or delete data.
- Prefer short-lived, task-scoped credentials over long-lived access so a poisoned step cannot reuse authority later.
- Log the full chain from retrieval to tool call so the decision path can be reconstructed after an incident.
For agentic systems, this lines up with GitHub Action tj-actions Supply Chain Attack research, which illustrates how trusted automation can be turned against the organisation when hidden inputs are allowed to influence execution. OWASP’s LLM Top 10 and the emerging CSA MAESTRO approach both reinforce the same operational point: the model must not be the only place where trust decisions happen. Policy needs to evaluate what the agent is trying to do, with what data, and under which permissions at the moment of action. These controls tend to break down in long-running, tool-rich workflows because state accumulates faster than reviewers can inspect it.
Common Variations and Edge Cases
Tighter prompt controls often increase operational overhead, requiring organisations to balance blocked attacks against slower workflows and more false positives. That tradeoff becomes sharper in retrieval-heavy systems, customer support copilots, and code-assist pipelines where untrusted text is a normal part of the job. Best practice is evolving, but there is no universal standard for treating every retrieved passage as equally risky. Some teams score content by source reputation, while others treat all external input as hostile until validated.
Edge cases matter. A workflow that looks safe in a single-turn demo may become unsafe once summaries are re-ingested, tool outputs are fed back into the model, or multiple agents share intermediate state. For that reason, prompt-injection defence should be paired with workload identity, least privilege, and runtime policy checks, not just content moderation. NIST’s AI governance guidance and the NIST Cybersecurity Framework 2.0 both support this broader view of control placement, while OWASP and CSA guidance help teams define what “safe enough” means for each tool boundary. The practical lesson is simple: if the workflow can remember, summarise, and act, then a single input filter is not a containment strategy.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM07 | Prompt injection across chained steps is a core agentic attack path. |
| CSA MAESTRO | AI-02 | Covers agent workflow trust boundaries and execution governance. |
| NIST AI RMF | AI RMF governs risk across the full system lifecycle, not one prompt. | |
| OWASP Non-Human Identity Top 10 | NHI-05 | Tool use in multi-step workflows depends on protecting credentials and authority. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits damage when an injected step reaches a tool. |
Treat prompt injection as a system-level risk and test retrieval-to-action paths end to end.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
