Reduce the risk by sanitising retrieved content, separating data from instructions and restricting what the model can pass into downstream tools. Filter or strip hidden instructions from documents, limit cross-turn memory, and monitor for self-propagating prompts, repeated tool chaining and unexpected outbound messages. Human review is appropriate for high-impact actions triggered by retrieved content.
How Morris II spreads inside RAG pipelines
Morris II is dangerous because it turns retrieved text into an attack carrier. In a RAG flow, the model may ingest document content, convert it into prompts or tool calls, and then reuse that output in later turns. If the system treats retrieved text as trustworthy by default, a hidden instruction can survive the retrieval step and influence downstream behaviour.
The core failure is boundary collapse: content, instruction and action are not kept separate. A robust RAG design should assume that retrieved material can be hostile, incomplete or deliberately crafted to trigger unsafe model behaviour. That is why retrieval hardening is not just a relevance problem, it is an instruction-safety problem.
For a broader view of retrieval poisoning and prompt-injection controls, see the RAG Security Guide. When the issue is permissioning and over-sharing at retrieval time, the Permission-Aware RAG Guide shows why access control has to follow the data into the retriever, not stop at the application edge.
Controls that blunt Morris II style propagation
Sanitisation is the first control, but it has to be specific. Strip or neutralise hidden instructions, prompt-like markup, and text patterns that ask the model to override policy, call tools, or forward content elsewhere. If the system uses chunking, summarisation or citation generation, those stages also need filtering, because attackers can plant payloads in places the final answer never explicitly quotes.
Just as important is instruction hierarchy. Retrieved text should be treated as data unless it has been explicitly curated as trusted guidance. Keep system instructions, retrieval content, user prompts and tool payloads in separate channels, and apply a strict allow list to what the model may pass to downstream tools. The more the model can execute actions from raw retrieval output, the more worm behaviour becomes possible.
Monitor the pipeline for repeated tool chaining, self-referential prompt loops, unusual outbound messages and content that appears to be copying itself across turns. Those are the operational signs that a retrieved payload has stopped being passive text and started behaving like an active propagating instruction.
For threat-pattern context, the MITRE ATLAS Guide is useful when you want to map prompt injection, tool misuse and agent hijacking to an adversarial technique set. The related MITRE ATLAS adversarial AI threat matrix gives a public matrix for those behaviours.
What to do when patching is not the whole answer
Morris II style risk is rarely eliminated by one control. Even well-tuned retrieval filters can miss crafted payloads, and even good content separation can fail if a tool blindly trusts model output. That makes blast-radius control essential: limit cross-turn memory, scope tool authority tightly, and make sure the model cannot escalate from text retrieval into unrestricted external action.
High-impact actions need human review when they are triggered by retrieved content, especially if the action can send messages, modify records, trigger workflows or expose data outside the RAG boundary. In practice, the safest pattern is to force a deliberate approval step whenever retrieved text is about to become a side effect rather than an answer.
For teams building a stronger operating model around AI risk, the AI Risk Assessment Guide helps structure treatment decisions, while the AI Agent Observability, Audit and Incident Response Guide is a useful companion when you need logging, attribution and a tested kill switch for abnormal behaviour.
Risk and Threat Considerations
RAG systems expand the attack surface because they allow untrusted content to influence reasoning, memory and tool use. If retrieval output can shape later prompts or actions without a strong trust boundary, an attacker only needs to poison one document or one source path to seed repeated malicious behaviour across many sessions.
Failure mechanism: The model or orchestration layer reuses retrieved text as if it were trusted instruction, then propagates that instruction into memory, summaries or tool calls. That creates a self-reinforcing loop in which malicious text can survive several pipeline stages and trigger secondary actions.
Impact: The result can be prompt hijacking, data leakage, unwanted outbound communication, tool misuse, or repeated propagation of attacker-controlled content through the RAG environment. At scale, the same pattern can contaminate multiple tenants, workflows or connected assistants if the retrieval layer is shared.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Architecture | RAG instruction separation and trust boundaries are an architecture concern. |
| Recommendation — Separate untrusted retrieval content from system instructions and action paths. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Model-driven tool use can become unsafe if actions are not tightly authorised. |
| Recommendation — Restrict model-triggered tool actions to explicitly authorised functions. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Sanitising retrieved content is input validation for untrusted AI pipeline text. |
| AC-6 — Least Privilege | Limiting tool and memory authority reduces blast radius if retrieval is poisoned. | |
| Recommendation — Validate and sanitise retrieved text before it can influence processing or actions. Scope model and tool permissions to the minimum needed for each task. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | RAG systems need tight control over who can reach sources, outputs and downstream actions. |
| Recommendation — Restrict access to retrieval sources, prompts and connected tools by role. | ||
Practitioner Guidance
What to verify: Check that your RAG stack can prove where instruction boundaries exist, which text is treated as untrusted, and which outputs are allowed to reach tools. If you cannot point to those boundaries in code and logs, the system is relying on model behaviour rather than enforced control.
Decision rule: If retrieved content can trigger an external side effect, require a human approval gate or a narrowly scoped policy check before execution. If the action is informational only, you can keep it automated, but the model should still be prevented from carrying hidden instructions forward.
Practitioner takeaway: Treat retrieved text as potentially hostile input all the way through the pipeline, because Morris II is defeated by containment and verification more reliably than by prompt engineering alone.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of exposed AI credentials being abused?
- What is the main risk when automation systems store ServiceNow credentials?
- How should teams reduce risk from malicious npm package installs?
- How should travel companies reduce the risk of AI-powered bot attacks against booking and loyalty systems?