Morris II Worm: RAG-Based Attack matters because malicious content inside retrieved data can cause an agent or retrieval system to repeat the payload and spread it across connected workflows. Security teams should sanitise ingested content, constrain tool actions, isolate tenants and monitor for recursive prompt or output propagation.
Why a RAG-based worm changes the security model
Morris II matters because the dangerous part is not just the original prompt, but the way retrieved content can be reused, reinterpreted and propagated by downstream systems. Once malicious text is accepted into the retrieval layer, an agent may treat it as trusted context and amplify it across workflows, which makes the blast radius larger than a single compromised chat or document.
That shifts the security problem from isolated prompt filtering to end-to-end control of the RAG pipeline. Security teams need to think about how content is ingested, indexed, retrieved, summarised and forwarded, because each step can turn a poisoned document into a repeatable payload.
For teams building or governing retrieval systems, the practical lesson is that trust has to be explicit at the data-source and retrieval boundary, not assumed because the content came from an internal index or a familiar tenant.
Where propagation risk shows up in real deployments
The most relevant failure mode is recursive reuse: the system retrieves untrusted text, embeds it into an agentic or automated workflow, then re-emits it in a way that triggers the next action or next retrieval. That can create self-reinforcing contamination across users, sessions or connected tools, especially where output is automatically consumed by another component.
This is why controls such as tenant isolation, document-level scoping and action constraints matter. Without them, one polluted record can influence multiple conversations, tasks or downstream systems, even when the original source was only meant to be read, not executed.
Security teams should also pay attention to over-sharing in retrieval results. If the system returns more context than the requester is entitled to see, a worm-like payload can spread and disclose data at the same time, which turns a propagation problem into a confidentiality problem.
What defenders should change in RAG operations
Defence has to start before retrieval. Sanitize and validate ingested content, segment tenants and sources, and make sure the system distinguishes between content that can be displayed and content that can influence tool use or follow-on actions.
Teams should also constrain what the agent can do with retrieved material. If retrieved text can trigger external calls, updates, routing decisions or message creation, that action path needs tighter approval, policy checks and logging than a standard search workflow.
A useful operational test is to ask whether a malicious snippet can survive ingestion, survive retrieval, and still affect a later step without any human noticing the chain. If the answer is yes, the RAG design still has a worm propagation path.
Risk and Threat Considerations
RAG systems can turn untrusted content into a repeatable delivery channel for malicious instructions, data leakage or workflow manipulation. The risk is highest where retrieval results are consumed automatically, shared across tenants, or allowed to drive agent actions with little separation between read and act.
Failure mechanism: A poisoned document or retrieved passage is treated as trusted context, then reinserted into prompts, summaries or tool calls that propagate the payload to other workflows or users.
Impact: The attack can spread laterally through connected retrieval and agent systems, causing repeated malicious outputs, possible data exposure, and broader operational disruption than a single compromised prompt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI 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 Non-Human Identity Top 10 | NHI-02 — Secret Leakage | RAG worms can reuse poisoned content to expose data through retrieval and output channels. |
| NHI-05 — Overprivileged NHI | Agents and retrieval workflows can amplify impact when they can act beyond needed scope. | |
| Recommendation — Prevent poisoned retrieval from disclosing secrets or sensitive context. Reduce agent and retrieval privileges to the minimum required. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | A RAG worm matters when retrieved text drives unsafe tool actions in agent workflows. |
| ASI07 — Insecure Inter-Agent Communication | Propagation across connected workflows depends on weak trust boundaries between components. | |
| Recommendation — Restrict tool execution paths that can be triggered by retrieved content. Authenticate and validate inter-agent messages before reuse or forwarding. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Tenant isolation and document-level scoping depend on enforced access rules in retrieval. |
| Recommendation — Enforce retrieval and data-access decisions at the point of use. | ||
Practitioner Guidance
What to verify: Confirm that retrieval permissions, tenant boundaries and tool permissions are enforced at the same layer, not separately. If an index can surface content that an agent can then act on, you need proof that both stages are scoped correctly.
What to prioritise: Focus first on the pipeline points where untrusted text becomes operationally significant, especially ingestion, ranking, summarisation and any handoff into automation. Those are the places where a benign-looking document becomes a security event.
Common mistake: Treating prompt filtering as sufficient. A RAG worm often succeeds because the malicious instruction is not injected at the front door, it is reintroduced from inside the trusted knowledge flow.
Practitioner takeaway: The security objective is to make retrieved content observable, bounded and non-authoritative unless it has been explicitly cleared for the exact tenant, user and action path.