Why does Morris II Worm: RAG-Based Attack matter for security teams?

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.

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.

Related resources from NHI Mgmt Group

• Guide: MITRE ATLAS Guide
• What is an example of Morris II Worm: RAG-Based Attack in practice?
• Morris II Worm: RAG-Based Attack
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?