Once malicious instructions are inside one AI-enabled system, the next risk is that agents and ordinary workflows carry them onward to inboxes, repositories, memory stores and other agents. MITRE ATLAS added AML.T0143 LLM Prompt Propagation in release 2026.10 (28 October 2026) under the Lateral Movement tactic (AML.TA0015), with maturity Demonstrated. ATLAS describes the transfer of instructions already introduced into an environment to further storage locations, agents, applications or resources, so the adversary reaches new targets without delivering the payload to each one. Getting the instructions in the first time is covered in the AML.T0051 LLM Prompt Injection page, and prompts that copy themselves in the MITRE ATLAS AML.T0061 LLM Prompt Self-Replication page. This page is about the spread, and how architecture and permissions contain it. It is for teams building agents, copilots and multi-agent systems that write to places other AI components read.
Key takeaways
- Propagation needs a write path. Every place an agent can send, publish, sync or store content that another AI reads is a propagation route.
- It does not require self-replication. ATLAS includes plain copying, forwarding, synchronisation and template reuse, not only prompts that reproduce themselves.
- Three ATLAS case studies show it. Morris II (AML.CS0024), Rules File Backdoor (AML.CS0041) and ZombieAgent (AML.CS0066).
- ATLAS maps six mitigations. AML.M0026, M0027, M0028, M0030, M0032 and M0033, all about limiting and checking what an agent can distribute.
- The key control is a taint rule. Once untrusted content enters an agent's context, outbound distribution actions should need extra checks, including for delayed and derived content.
How the technique works
ATLAS lists the channels by name: email and other communications, shared documents, source-code repositories, persistent agent memory, retrieval systems, databases, shared workspaces and direct agent-to-agent communication. Connected tools can also carry instructions between environments that are otherwise separate. The transfer may come from an action the agent was induced to take, or from normal copying and synchronisation that moves the affected content.
| Propagation route | How instructions move | Who reads them next |
|---|---|---|
| Email and messaging | Agent sends replies or new messages containing the instructions | Recipients' AI assistants |
| Shared documents and workspaces | Agent writes or edits a shared file | Any copilot that summarises or retrieves it |
| Source repositories and templates | Poisoned configuration or rules files are committed, forked or reused | AI coding assistants in downstream projects |
| Persistent agent memory | Instructions are saved as a memory entry | The same agent in every later session |
| Retrieval stores and databases | Content is indexed or inserted | Any RAG application querying that store |
| Agent-to-agent channels | One agent passes a task or message to another | Peer and sub-agents |
Related ATLAS techniques sit on either side. Entry is often AML.T0051.001 Indirect prompt injection or AML.T0093 Prompt Infiltration via Public-Facing Application. Self-replicating payloads (AML.T0061) make propagation easier. Memory and retrieval routes overlap AML.T0080 AI Agent Context Poisoning and AML.T0070 RAG Poisoning, and poisoned rules files overlap AML.T0081 Modify AI Agent Configuration.
Real cases
Morris II (AML.CS0024): researchers sent an email with a self-replicating prompt to a RAG-based email assistant. ATLAS step S10 maps to AML.T0143: the application sent its generated reply, containing the reproduced prompt, to the client whose email had triggered it, so the prompt moved on to other systems.
Rules File Backdoor (AML.CS0041): Pillar Security disclosed in March 2025 that instructions hidden with invisible Unicode characters in AI coding assistant rules files could steer code generation. ATLAS step S05 maps to AML.T0143: forking or template reuse transfers the poisoned rules file into further projects, where assistants load the inherited instructions. Pillar named developer forums, open-source pull requests and project templates as routes. GitHub added a warning for files containing hidden Unicode text on github.com on 1 May 2025, according to Pillar.
ZombieAgent (AML.CS0066): Radware reported to OpenAI on 26 September 2025 an attack in which a malicious email or document reached a ChatGPT agent through connected services; OpenAI fixed it on 16 December 2025. ATLAS step S12 maps to AML.T0143: the instructions caused the agent to reproduce the prompt in new emails or documents for collected contacts, so another agent that processed them could be affected. Radware also describes the agent collecting recent inbox addresses for an attacker server to mail, and memory entries that kept the behaviour across new chats.
Prevention: the ATLAS mitigations in practice
| ATLAS mitigation | What ATLAS asks for against AML.T0143 | Practical control |
|---|---|---|
| AML.M0026 Manage AI Agent Service Access | Limit messaging, publishing and shared-resource write permissions to approved workflows and destinations | Separate send and publish scopes from read scopes in the agent's service identity |
| AML.M0027 Manage User-Delegated AI Agent Access | Limit delegated distribution permissions to what the user's task needs | Request mail-send or repo-write consent per task, not at onboarding |
| AML.M0028 Enforce Access Controls for AI Agent Tools | Authorise messaging, publishing, repository writes, storage updates and agent communication against permitted destinations, through downstream services | Destination allowlists enforced in the tool server, not in the prompt |
| AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Restrict distribution actions once untrusted content is in context, including delayed actions and derived content | Taint tracking that requires human approval for outbound actions after untrusted input |
| AML.M0032 Segmentation of AI Agent Components | Isolate identities, storage, memory, messaging and tool access; restrict cross-agent, cross-user and cross-environment paths | Per-user memory and retrieval partitions; brokered agent-to-agent calls |
| AML.M0033 Input and Output Validation for AI Agent Components | Validate content before it is forwarded, published, synced or stored, outside the agent and at receiving boundaries, including hidden or encoded content | Scanners for invisible Unicode and instruction patterns on outbound mail, commits, rules files and memory writes |
The ATLAS text for M0030 is worth reading closely: restrictions should also apply to delayed actions and derived content. A summary written from a poisoned email still carries the poison. Identity is central to most of these controls; see the Multi-Agent and A2A Security Guide and the Agent-to-Agent Authentication Guide.
Detection
- Outbound content similarity: flag agent-written messages, documents or commits that contain long passages copied from inbound untrusted content.
- Fan-out anomalies: alert when an agent sends to many new recipients, writes to many repositories or posts to many channels in a short window.
- Hidden characters: scan rules files, agent instruction files, templates and memory entries for invisible or bidirectional Unicode, as Pillar recommends.
- Memory write review: log every memory creation with its source context, and alert on entries that contain instructions rather than facts. See the AI Agent Memory Security Guide.
- Cross-tenant and cross-user paths: any agent action that moves content from one user's scope into another's should be logged with both identities.
Containment when propagation is suspected
- Pause outbound tools: disable send, publish and write actions for the affected agent, keeping read-only operation if the business needs it.
- Find every copy: search mailboxes, repositories, templates, memory stores and retrieval indexes for the instruction text and its hidden-character variants.
- Purge and re-index: remove poisoned memory entries and documents, then rebuild affected retrieval indexes from clean sources.
- Notify downstream: warn owners of forks, recipients and partner agents that may have ingested the content.
- Preserve evidence: keep agent context logs, tool-call records and the first malicious input before purging.
- Re-enable gradually: restore outbound actions with tighter destination allowlists and approval gates, watching fan-out metrics.
The AI Agent Memory Poisoning Response Playbook covers the memory-specific steps in more depth.
Metrics
- Share of agents whose distribution permissions (send, publish, write) are separated from read access.
- Share of outbound agent actions after untrusted input that pass through an approval or validation gate.
- Number of rules, instruction and template files scanned for hidden characters per release.
- Time to locate and purge all copies of a malicious instruction in an exercise.
- Count of cross-user or cross-tenant content transfers by agents, reviewed monthly.
Common failure patterns
- One broad scope for mail or repositories: an agent that may read also may send to anyone, so every injection becomes a distribution event.
- Taint checks only on direct tool calls: delayed actions and summaries derived from poisoned content bypass the gate, the gap ATLAS calls out under M0030.
- Treating rules files as documentation: they are executable instructions for assistants and should get code review and hidden-character checks.
- Shared memory and retrieval across users: one poisoned entry reaches everyone.
- Cleaning the first inbox only: forks, templates and indexes keep the instructions alive. The same lesson appears in conventional worm outbreaks; see Self Propagating Supply Chain Worms.
Framework mapping
| Framework | Item | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0143, tactic AML.TA0015 Lateral Movement | The technique itself |
| MITRE ATLAS | AML.M0026, AML.M0027, AML.M0028, AML.M0030, AML.M0032, AML.M0033 | Mitigations ATLAS maps to this technique |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection, LLM06 Excessive Agency | Entry of the instructions and the permissions that let them spread |
| NIST SP 800-53 Rev. 5 | AC-4 Information Flow Enforcement, AC-6 Least Privilege, SI-10 Information Input Validation, SI-4 System Monitoring | Restricting where content flows, scoping agent permissions, validating content, monitoring fan-out |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09 | Least-privilege permissions and runtime monitoring |
Practitioner checklist
- Map every route by which each agent can send, publish, sync or store content another AI reads.
- Split distribution permissions from read permissions in agent and delegated identities.
- Enforce destination allowlists in tool servers.
- Gate outbound actions after untrusted input, including delayed and derived content.
- Partition memory and retrieval stores per user or tenant.
- Scan rules, instruction and template files for hidden Unicode before merge.
- Alert on agent fan-out and on copied passages from untrusted input.
- Rehearse a find-every-copy purge across mail, repos, memory and indexes.
Standards and references
- MITRE ATLAS: LLM Prompt Propagation (AML.T0143)
- MITRE ATLAS: Morris II Worm: RAG-Based Attack (AML.CS0024)
- MITRE ATLAS: Rules File Backdoor: Supply Chain Attack on AI Coding Assistants (AML.CS0041)
- MITRE ATLAS: ZombieAgent: Data Exfiltration Attack on ChatGPT (AML.CS0066)
- Pillar Security: Rules File Backdoor research
- Radware: ZombieAgent
- arXiv: Morris II adversarial self-replicating prompts (2403.02817)
- OWASP: Top 10 for LLM Applications 2025
Related NHI Mgmt Group resources: MITRE ATLAS AML.T0061 LLM Prompt Self-Replication, AML.T0051 LLM Prompt Injection, Multi-Agent and A2A Security Guide, AI Agent Memory Security Guide, MITRE ATLAS Guide.