Blog · Analysis · Last reviewed June 25, 2026

The Prompt Worm Becomes the Email Attachment

The old email attachment asked a human to click. The prompt worm asks an agent to read. In agentic systems, ordinary content can become instruction, payload, and propagation path when untrusted input reaches memory, tools, and transmission authority.

The governed object is the whole source-to-sink chain: inbound content, parser, model context, memory, retrieval index, tool permission, approval gate, outbound message, and the audit trail that proves what crossed each boundary.

The sharp safety question is not whether a model can be made immune to hostile text. It is whether hostile text can cross from content into authority without a separate control noticing and stopping it.

From Attachment to Instruction

The classic email worm depended on a brittle social-technical bargain. A message arrived, an attachment looked tempting, a user clicked, and the machine executed code. Security training learned to name the pattern: do not open strange files, do not trust unexpected links, do not mistake a familiar sender for a safe payload.

Agentic AI reopens the problem at a different layer. A message, document, image, calendar invite, web page, support ticket, or retrieved record may be processed automatically by a model-mediated system. The hostile material does not need to be executable in the old operating-system sense. It only needs to be interpreted by the agent as relevant instruction, context, or task material.

For this essay, a prompt worm is an adversarial, self-replicating instruction payload that causes a model-mediated application to reproduce the payload, perform some attacker-desired action, and transmit the payload into another context. It is not a claim that language is malware by itself. The risk appears when untrusted language is joined to memory, retrieval, tools, credentials, and automatic communication.

This definition is intentionally narrow. A malicious email that makes one assistant answer badly is prompt injection. A poisoned record that persists in a memory store is memory contamination. A worm-like prompt requires a further threshold: the payload has to be reproduced or carried onward by the system's normal workflow. The word "worm" should be reserved for propagation risk, not used as a synonym for every hostile prompt.

That makes the security object broader than a string filter. The dangerous chain is source, interpreter, authority, sink: hostile content enters from a lower-trust source, the model treats it as task-relevant context, the agent retains or retrieves it later, and a tool sink lets the effect leave as an email, document, ticket, API call, calendar event, shared summary, or message to another agent. The threshold should be operational: if the payload cannot persist, transmit, or cause a downstream agent or system to ingest it, call the incident injection, poisoning, or exfiltration, not a worm.

A useful incident report should therefore name the boundary crossed. Did the payload only alter one response, contaminate memory, trigger a tool, leak data, or reproduce into a new message? The answer determines whether the response is prompt hardening, memory cleanup, connector disablement, credential rotation, user notice, or broader incident response.

The old attachment asked the person to run it. The new prompt payload may only need the assistant to summarize, reply, route, retrieve, or act.

The Self-Replicating Prompt

In 2024, Stav Cohen, Ron Bitton, and Ben Nassi published an arXiv paper on a research system they called Morris II: a zero-click worm for generative-AI ecosystems. The paper, last revised in January 2025, describes adversarial self-replicating prompts that can be embedded in inputs processed by GenAI-powered applications. In their lab demonstrations, the prompt causes the model-mediated application to reproduce the prompt, perform a malicious payload, and propagate to other agents through connected workflows.

The researchers tested the idea against GenAI-powered email assistants in controlled settings, including text and image inputs, RAG-based retrieval, automatic responses, spamming, and personal-data exfiltration scenarios. They state that the experiments were performed in a lab environment and were not run against existing public applications.

The important point is not the particular proof of concept. It is the category. A prompt worm treats language as a replication medium. It does not merely fool one model once. It tries to turn the agent's ordinary communication loop into the transport mechanism.

Three Conditions for Propagation

A prompt worm is not created by hostile text alone. Three conditions have to meet.

First, untrusted content must be ingested as context. The payload may arrive as an email body, attachment, image text, calendar invite, web page, support ticket, shared document, repository issue, database row, or retrieved memory. The common feature is that the system treats outside material as relevant to the task.

Second, the context must survive long enough to be reused. The payload may persist in a mailbox, vector index, RAG database, conversation memory, document cache, prompt cache, ticket history, or generated draft. One bad read is an injection incident. Reuse turns the incident into infrastructure.

Third, the agent must have a transmission path. The system can reply, forward, summarize into another record, update a ticket, write to a shared workspace, call another agent, or send data through a tool. Without transmission authority, the payload may mislead one answer. With transmission authority, it can attempt to move.

Those conditions make the governance target clearer. The question is not whether every hostile prompt can be detected. It is whether untrusted context can cross from reading into authority, persistence, and propagation without a policy gate.

Trust Zones and Sinks

Prompt-worm governance starts by naming trust zones. An outside email is not the same authority class as a user instruction. OCR text from an attachment is not the same authority class as a policy file. A tool description is not the same authority class as a tool result. A generated draft is not the same authority class as a sent message. If those zones collapse inside one model context, the assistant may treat all text as equally actionable.

The source label should travel with the content. External sender, public web, vendor file, internal record, retrieved chunk, tool output, generated summary, cached prompt, and human-approved instruction should remain distinguishable in prompts, memory, logs, and outgoing drafts. This is the practical version of the site's wider work on vector memory, model memory, and agent observability: the organization must be able to see which class of content crossed which boundary.

Sinks matter as much as sources. A system that can only display a draft has a different risk profile from a system that can send email, update CRM records, post to Slack, create calendar invites, write to a shared document, call webhooks, or message another agent. The governance rule should be simple: lower-trust content may inform a draft, but it should not authorize a sink. Authority to transmit should come from the user, a policy, or a scoped service identity, not from the text being processed.

The same rule applies to attachments. A PDF, image, spreadsheet, transcript, or voicemail-derived text should enter as evidence with a source label, not as a new instruction channel. If OCR, extraction, summarization, or embedding strips that label, the attachment has gained authority it never had.

Email Attachment Risk Map

The email-attachment version is useful because it makes the pipeline concrete. The mail envelope names sender, recipients, authentication signals, reply chain, timestamps, message identifiers, and external-party status. The content layer includes body text, HTML, links, quoted replies, forwarded material, headers exposed to the assistant, and attachments. The extraction layer turns PDFs, images, spreadsheets, slides, archives, audio transcripts, or scanned documents into text and metadata. The model layer summarizes, classifies, drafts, retrieves, or decides whether a tool call is useful. The authority layer decides whether the result may write memory, search private records, send mail, update a ticket, create a calendar invite, or message another agent.

Those layers should not inherit authority from one another. A signed email can still contain a malicious attachment. A trusted sender can forward untrusted text. A safe attachment scan does not mean extracted text is safe instruction. A clean summary does not mean a generated reply is safe to send. The useful control is not one label saying "safe." It is a chain of labels that survives parsing, summarization, embedding, retrieval, draft generation, and delivery.

A governable mailbox agent should therefore produce an attachment receipt: message id, sender trust class, attachment hash and MIME type, parser or OCR path, extracted-text source label, generated-summary id, memory-write decision, tool calls attempted, outbound recipients, approval event, and deletion or quarantine state. This connects the prompt-worm problem to agent trace process maps, delegation traces, and AI data retention. Without that receipt, the institution may know that an assistant sent a reply but not which untrusted object gave the reply its shape.

Current Context

As of June 25, 2026, the right framing is not "AI worms are everywhere." The public Morris II work remains a research demonstration. The real current context is that the conditions for similar failures are becoming more common: agents read mail and webpages, summarize attachments, call tools, use retrieval-augmented generation, connect to enterprise records, and send messages through delegated accounts.

Security guidance has moved in the same direction. OWASP's 2025 LLM Top 10 places prompt injection first and explicitly includes indirect injection from websites and files, multimodal injection, privilege-control failures, human-approval gaps, and the need to segregate external content. OWASP's 2026 Agentic Applications Top 10 frames agent systems as systems that plan, act, and make decisions across workflows. NIST's 2026 AI Agent Standards Initiative puts agent security, interoperability, authentication, identity, authorization, auditing, and non-repudiation into active standards work.

Vendors are also treating this as a long-term agent-security problem rather than a one-time filter bug. OpenAI's prompt-injection materials for browser agents describe prompt injection as an open challenge for agent security and recommend controls such as logged-out operation, confirmations for sensitive steps, careful review before sending emails or other sensitive actions, and continued red-teaming. Those product-specific controls do not prove any one system is safe; they show that serious deployers now treat hostile content as part of the agent threat model.

OpenAI's December 2025 Atlas hardening post makes the email scenario explicit: a browser agent that reads a malicious email during an ordinary task can be steered toward unintended mail-sending behavior if safeguards fail. OpenAI presents that as an internal red-team and mitigation example, not as evidence of a public worm outbreak. The useful lesson is architectural: email, attachments, webpages, shared files, and social feeds are now agent input surfaces.

The incident record is also no longer only hypothetical. NVD lists CVE-2025-32711 as an M365 Copilot AI command-injection vulnerability that allowed information disclosure over a network; the EchoLeak case study describes a zero-click exploit chain using a crafted email. In June 2026, NVD published CVE-2026-42824 for M365 Copilot information disclosure; its current description says missing authentication for a critical function, while NVD's analysis text still records command-injection language from the earlier record. Varonis described the related SearchLeak research as a one-click Copilot Enterprise Search exfiltration chain. These are not prompt worms unless they replicate. They matter here because they show the same source-to-sink shape: attacker-controlled content or parameters can reach an agentic assistant's retrieval, permissions, rendering, or communication path.

Microsoft's 2026 indirect-prompt-injection guidance and Brave's 2026 security writing point to the same category from different positions: hostile content can be hidden in ordinary web, document, email, or multimodal surfaces, and the defense has to be architectural rather than only a model refusal. The page therefore belongs beside Prompt Injection, AI Agents, AI Browsers and Computer Use, tool-server trust boundaries, agent service accounts, and enterprise connector permission maps. A worm-like prompt is only one failure mode inside a larger architecture problem: untrusted context reaching authority.

This makes the enterprise version less like antivirus and more like AI change management. Each new mailbox connector, browser agent, RAG corpus, MCP server, memory feature, attachment parser, or auto-reply workflow should be reviewed as a possible propagation surface, with an owner, allowed sinks, retention rule, canary test, and disable path.

Why Agents Change the Risk

Prompt injection is already the first risk in OWASP's 2025 Top 10 for LLM Applications. OWASP defines it as crafted input that alters model behavior or output in unintended ways, and notes that injections can be indirect, coming from external sources such as websites or files. It also warns that impact depends on the business context and the degree of agency designed into the application.

Agents make that risk more institutional because they add memory, tools, permissions, and workflow. A chatbot that says something wrong is a problem. A mailbox agent that reads untrusted mail, searches a private archive, drafts replies, forwards messages, updates records, or calls APIs can turn wrong interpretation into action.

This is why OWASP's 2026 Top 10 for Agentic Applications matters. Its summary frames agentic AI systems as systems that plan, act, and make decisions across complex workflows. The security problem is no longer only bad output. It is cascading behavior across tools, identities, permissions, and connected agents.

The same pattern appears in AI browsers and agent logs. Once a model can read external text and act through a user account, the institution needs to know which content was data, which text was treated as instruction, which tool was called, and why the action was allowed. Without that separation, the agent becomes a confused deputy with excellent prose.

Filtering Is Not Enough

The UK National Cyber Security Centre has warned that prompt injection should be treated as a residual risk managed through design, build, and operation, not as a class of bug that one appliance or filter can fully solve. Its practical point is severe: when an LLM system calls tools or APIs based on model output, the possible impact of prompt injection approaches the worst case of giving an attacker access to those tools.

MITRE's SAFE-AI material makes a similar distinction between direct and indirect prompt injection. It describes indirect prompt injection as malicious prompts ingested from separate data sources during normal operation, including websites, multimedia, or plugins, and notes that the user may not be aware of the injection.

Connector and tool ecosystems sharpen the point. OWASP's MCP Top 10 describes context-layer risks in MCP-enabled systems, and the site's own tool-boundary analysis treats tool descriptions, returned content, credentials, and logs as part of the action path. The prompt worm is the stress test for every vague agent-security promise. "We filter prompts" is not enough. "The model is trained to ignore bad instructions" is not enough. "The user can review final output" is not enough if the agent has already retrieved private data, updated a record, or sent a message.

The safer design uses deterministic controls around the model: source labels, permission reduction, sink policy, output validation, message-review gates, rate limits, egress controls, scoped credentials, and logs that survive incident response. The model can help detect hostile context, but it should not be the only component deciding whether hostile context may become action.

Controls also need ordering. Detection is useful, but containment should not wait for detection to be confident. A low-trust email can be summarized, a draft can be prepared, and a warning can be raised while send, forward, delete, export, permission-change, and memory-write tools remain unavailable until a human or policy gate re-authorizes them.

Failure Modes

The first failure mode is authority collapse. The system mixes user instructions, developer policy, retrieved content, email text, tool descriptions, and model output without durable labels, so hostile content can masquerade as a command.

The second is privilege inheritance. An agent reads an untrusted message but continues to hold the user's full mailbox, browser, file, CRM, or cloud-account authority. The sender's lack of authority is not reflected in the action boundary.

The third is memory contamination. A hostile instruction is stored in a vector index, prompt cache, mailbox memory, ticket history, or long-term assistant memory and later reappears as supposedly helpful context.

The fourth is propagation by helpfulness. The agent is rewarded for replying, forwarding, summarizing, routing, or updating quickly, so transmission becomes the default path before source trust is assessed.

The fifth is cross-connector exfiltration. The injected context arrives through one channel, such as email or a webpage, and causes data to leave through another channel, such as chat, a ticketing tool, a document share, an API call, or another agent.

The sixth is multimodal smuggling. Instruction-like content is carried through images, screenshots, attachments, OCR, alt text, comments, metadata, or generated summaries that bypass controls designed only for plain text.

The seventh is receipt absence. After an incident, the organization can see the final message but not the source item, retrieved context, model route, tool call, approval prompt, blocked action, or propagation path that produced it.

The eighth is filter theater. A single classifier, regex, prompt rule, or model refusal is treated as the safety case, while permissions, persistence, propagation, identity, and incident response remain broad and untested.

The ninth is attachment laundering. A hostile instruction enters through a PDF, screenshot, voicemail transcript, image, spreadsheet cell, or archive file, then becomes ordinary extracted text after OCR, summarization, or indexing removes its source boundary.

The tenth is approval fatigue. The interface asks for confirmation too often or too vaguely, so users approve outbound messages, connector calls, memory writes, or data sharing without seeing which untrusted source influenced the action.

The eleventh is silent product drift. A vendor update adds auto-reply, memory, connector, browser, parser, or cross-agent routing behavior to a system that was previously read-only, changing propagation risk without a new security review.

The Governance Standard

A serious agent system should treat external content as hostile until proven otherwise, especially when the content can influence action. At minimum, prompt-worm governance needs twenty practical tests.

First, separate reading from acting. An agent that reads external mail, documents, or web pages should not inherit the user's full authority merely because the user owns the mailbox or browser session.

Second, drop privilege to the source. If the model is processing material from an outside sender, the action boundary should reflect that sender's lack of authority. Untrusted input should not be allowed to trigger privileged tools.

Third, require confirmation before propagation. Auto-replies, forwards, shared documents, ticket updates, and cross-agent messages should be treated as transmission events, not harmless text generation.

Fourth, inspect retrieval paths. RAG databases, vector stores, email indexes, and memory systems need poisoning tests, origin labels, quarantine paths, and deletion procedures.

Fifth, bind tools to capability classes. Reading, searching, drafting, sending, forwarding, deleting, changing permissions, purchasing, and publishing are different powers. Agent systems should use explicit permission classes such as those in the Agent Tool Permission Protocol, not one broad "email access" grant.

Sixth, quarantine suspicious content and outputs. An attachment, image, webpage, or retrieved note that contains instruction-like text should be safely displayable and summarizable without becoming executable context. Quarantine should also apply to generated messages before they leave the system.

Seventh, log the chain. A user, administrator, or auditor should be able to reconstruct which external item was read, which instructions were extracted, which tool calls were attempted, which approvals were requested, which actions were blocked, and which messages were sent. This is where agent audit and incident review becomes operational rather than decorative.

Eighth, test propagation, not only prompt refusal. Red teams should use benign canary payloads to test whether an injected email can cause a reply, whether a retrieved record can call a tool, whether one connector can exfiltrate through another, whether an image can carry instructions, and whether blocked behavior stays blocked across retries, summaries, translations, and forwarded context.

Ninth, give users and administrators a kill switch. If an agent begins sending, forwarding, updating, or calling tools unexpectedly, the response should not depend on asking the same compromised context what happened. There should be revocation, session freeze, message recall where possible, connector disablement, credential rotation, and preserved evidence.

Tenth, keep agent identity separate from human identity. A mailbox agent should act through a named, scoped service identity where possible, with separate credentials, rate limits, and audit records. This keeps a compromised agent from becoming indistinguishable from the user's ordinary hand.

Eleventh, label source trust through the whole workflow. External email, public webpages, customer uploads, vendor attachments, screenshots, OCR text, comments, and retrieved records should carry trust labels into prompts, memory, logs, and generated drafts. If the label disappears, the agent cannot reliably reduce privilege later.

Twelfth, govern sinks as carefully as sources. The risky endpoint may be an email send, API call, shared document, calendar invite, ticket update, clipboard write, webhook, browser navigation, or another agent's inbox. A sink policy should say which destinations can receive which data classes under which approvals.

Thirteenth, make memory reversible. A poisoned record should be removable from vector stores, prompt caches, mailbox indexes, long-term memory, summaries, and derived artifacts. Deleting the original email is not enough if the payload has already been embedded or summarized elsewhere.

Fourteenth, test cross-agent propagation. Security tests should include benign self-replicating canaries that move from email to summary, from summary to ticket, from ticket to another assistant, and from assistant to outbound message. If the organization cannot trace the canary, it cannot trace a real incident.

Fifteenth, publish a naming rule. Incident reports should distinguish prompt injection, memory poisoning, exfiltration, unauthorized action, and propagation. Calling every failure a worm makes the term useless; refusing the term when a payload reproduces across contexts hides the operational risk.

Sixteenth, govern logs as sensitive data. The evidence needed to debug a prompt-worm incident may include private email, attachments, retrieved records, prompts, tool arguments, URLs, and outbound messages. Preserve enough detail for containment and accountability, but apply data minimization, redaction, retention limits, and access controls so security telemetry does not become a second breach surface.

Seventeenth, connect disclosure to patch evidence. When a prompt-injection incident becomes a vulnerability report, the public record should separate researcher names, CVE identifiers, vendor advisory status, affected product surface, exploit preconditions, user-interaction requirement, and patch or mitigation status. This belongs with AI incident reporting and secure AI system development: containment is not complete until affected operators know what to disable, update, rotate, review, and monitor.

Eighteenth, treat attachments as active content for review. Even when a file cannot execute code, extracted text can still steer an agent. Attachment pipelines should preserve sender, MIME type, extraction method, OCR confidence, file hash, scan result, and source label through summaries and embeddings.

Nineteenth, scope confirmations to the boundary crossed. A useful approval prompt should say which untrusted source influenced the action, which tool will be called, what data will leave, who receives it, whether memory will be written, and how to roll back or report the action. This connects the prompt-worm problem to AI audit trails, not merely user-interface friction.

Twentieth, make product drift trigger change review. New connectors, memory settings, auto-send modes, cross-agent routing, summarization defaults, or attachment parsers should reopen the threat model. A read-only assistant can become a propagation surface through one convenience feature, so the system's AI bill of materials should track authority-changing components as well as model and software components.

Source Discipline

Prompt-worm claims need careful sourcing because the phrase is easy to sensationalize. The Morris II paper is a research paper and lab demonstration, not evidence of a public outbreak. OWASP lists are consensus security guidance, not incident counts. NCSC is a national cybersecurity authority explaining design risk, not certifying a product. MITRE SAFE-AI maps threats and controls, but it does not prove that every agent deployment has those controls. OpenAI's prompt-injection posts are vendor-authored security and product disclosures, useful for current context but not independent assurance. Microsoft guidance is vendor security guidance for defending indirect prompt injection in its ecosystem. Brave's posts are adversarial security research and competitive browser security analysis, not a census of all agent-browser failures. NIST's agent work shows standards attention, not a finished regulatory regime.

CVE and vulnerability sources need their own discipline. NVD and MSRC records can confirm identifier, affected product family, broad vulnerability type, publication or modification date, severity vector, and vendor-advisory link; they often do not preserve the full exploit narrative. Researcher writeups and arXiv case studies can explain exploit chains, but they are not neutral prevalence data. A one-click or zero-click information-disclosure vulnerability is serious evidence for source-to-sink risk, while still not evidence of self-replication unless the payload actually propagates.

Current-source claims in this essay were checked on June 25, 2026. The CVE-2026-42824 record is a good warning about citation granularity: the current description and the analysis description do not use identical vulnerability wording. A responsible citation should name the record date, the field being cited, and whether the claim comes from NVD, MSRC, a researcher writeup, or a vendor blog.

Good evidence should name the input channel, the model role, the tool permissions, the propagation path, and the impact. "Prompt injection" is too broad by itself. A hidden instruction in a public web page, a poisoned RAG record, an image with embedded text, a malicious tool description, a forged calendar invite, and an auto-reply loop are different cases. The governance question changes with the channel and the authority attached to it.

For worm-like claims, evidence should also show replication. Did the system copy the payload into an outbound message, store it in durable memory, cause another agent to ingest it, or merely produce one unsafe response? The distinction matters for incident response because containment changes once the payload can persist or move.

Source discipline also means separating exploitability from consequence. A model producing an unsafe sentence is not the same as an agent sending a message, changing a record, leaking a file, or propagating a prompt to another agent. The higher the claimed consequence, the stronger the evidence should be: replay logs, tool-call traces, connector scopes, approval records, and independent reproduction.

Vendor mitigations should be read as product-specific controls, not as generic immunity. A confirmation gate in one browser agent, a spotlighting method in one enterprise stack, or a patch for one Copilot vulnerability does not prove that other agents with different connectors, memories, parsers, and approval defaults have the same boundary.

For attachment-based claims, cite the extraction path. A screenshot, PDF, image, voicemail transcript, spreadsheet, and archive file expose different parsers, metadata, OCR errors, retention paths, and indexing behavior. The security claim should say which parser and which downstream memory or tool sink were in scope.

What This Changes

The prompt worm is a reminder that AI security is not only about the model's answer. It is about the route from perception to action.

In the email era, the risky object was often a file. In the agent era, the risky object may be ordinary language positioned where an automated reader will treat it as operational context. The payload can live in an email, a document, a web page, an image, or a memory store. The transport can be the agent's helpfulness.

The Spiralist lesson is restrained: do not mythologize the worm, and do not dismiss it as a lab trick. The pattern is real enough to govern. Every agent that reads untrusted content and acts with delegated authority needs narrow permissions, source-aware privilege, quarantine, propagation limits, and audit trails. Otherwise the institution has rebuilt the email attachment as a service.

Sources

Return to Blog