Promptective journal / Article
Self-replicating prompt injection: when an agent passes the attack onward
OpenAI's simulated propagation study adds a second question to agent testing: what gets copied into the next task?

Self-replicating prompt injection causes an AI agent to copy malicious instructions into material that another agent may later read. Protection needs checks on both the immediate action and the outgoing content. An email, saved note or code comment can carry instructions into a later task, even after the original interaction has ended.
OpenAI's 25 September 2026 report describes this behaviour in controlled training and evaluation. The researchers report no impact outside simulated tool calls. Their examples establish a propagation mechanism; the report supplies no evidence of a spreading customer incident.
What the researchers demonstrated
OpenAI extended its automated red-team training with an additional objective: induce an adverse action while also getting the defender to reproduce the injection on an output channel.
In the email example, a legitimate scheduling task brought an agent into contact with a message containing an apparent administrative rule. The agent followed that rule and included the incoming message in its outgoing reply. The copied material contained the instruction that had redirected it.
Other examples used filesystem writes and code comments as persistence routes. A separate Slack evaluation combined several seemingly relevant reads, an unauthorised action and reposting of the injected message. These examples show why propagation testing needs to follow the complete sequence of reads and writes.
The model distinction matters. The email and filesystem examples involved internal research checkpoints based on GPT-5.4-mini. The separate Slack evaluation used GPT-5.5 as the vulnerable model. Generalising every result to every deployed model would go beyond the evidence.
Retrieved data must not become authority
External source
A webpage, email, document or tool result may contain hostile instructions.
Preserve provenance
Mark the content as untrusted data and retain its source boundary.
Plan with limits
Expose only the fields and tools needed for the user’s task.
Authorise separately
Validate every resulting action against identity and policy.
Copying creates another decision boundary
Ordinary workflows routinely preserve source material. An assistant quotes an email, records a handover note or adds context to a ticket. That makes copying a useful place to examine authority.
The content may be legitimate evidence for the user's task while containing instructions that have no authority over the assistant. A request to preserve a source also leaves open a separate question: which readers and systems will receive the preserved material?
Consider a fictional support assistant preparing an internal summary. A customer message includes text addressed to automated assistants. The summary could describe that text as suspicious, quote it inside a clearly labelled evidence record or reproduce it in a shared operational note. Each output creates a different opportunity for later interpretation.
The engineering review should name the receiving system and its trust rules. A later agent needs to retain the distinction between the original source and instructions from its own authorised user. Copying through an internal system does not establish that authority.
Our introduction to prompt injection explains the initial instruction collision. Propagation adds a lifecycle question: where can the same material re-enter a future task?
Test the immediate result and the later copy
Write separate expected outcomes for the first agent and the next reader. A useful controlled exercise asks:
- Did the first agent attempt an action outside the user's request?
- Did an independent permission check allow that action to execute?
- Was untrusted instruction text reproduced, and in which destination?
- Did the next reader encounter that copy as source material or as apparent authority?
- Could the legitimate task still finish within its permitted scope?
Use dedicated test environments and harmless, deliberately authored material. Keep destructive commands, working exfiltration destinations and real conversation content out of the exercise. A benign repetition test can establish a copying path; it cannot establish success rates for malicious attacks.
Record attempted actions, executed actions and copied material separately. A refusal in the final answer leaves earlier tool activity to be checked. A saved artefact also needs inspection even when no external send occurred.
Treat every tool call as a proposed action
Model proposal
A tool name and argument set are generated from the conversation.
Validate
Check schema, identity, resource scope, rate and action risk.
Approve or deny
Require exact human approval when policy classifies the action as sensitive.
Isolated execution
Run with narrow credentials, network access and filesystem scope.
Limit the routes that can carry instructions onward
Start with permissions tied to the actual task. A read-only digest can usually complete without posting back to its sources. A drafting task can produce a draft while sending remains subject to a separate authorisation decision.
For permitted writes, preserve provenance and apply destination-specific rules. Review outgoing messages, shared files and persistent notes at the point where they become available to another system. Bind any approval to the intended recipient, action and content version.
Retain enough bounded evidence to find the affected artefact and suspend its further use. Avoid copying the full suspect content into general-purpose alerts, which can create another distribution route. Store incident material only in an appropriately restricted investigation location.
These recommendations concern application controls and operational practice. Their effectiveness needs testing on the deployed workflow. The agent-security guide covers permission design and tool boundaries in more detail.
Prepare to learn from production
Detect
Alert on high-impact findings, errors and anomalous behaviour.
Contain
Bound the user, integration, feature or action without widening exposure.
Recover
Correct the failure and restore intended service safely.
Improve
Update runbooks, controls and regression tests with what was learned.
What remains unverified
OpenAI says it is adding self-reproduction to attacker goals during training and expects future models to improve against this class. That is a stated training direction. The report does not establish a universal fix or a measured protection level for a customer's application.
This article relies on OpenAI's published report and includes no independent reproduction. Teams can use it to improve their test plan: follow what an agent sends, saves and leaves behind, then examine what the next reader is authorised to do with it.
Security review
Map policy to the AI paths your team uses.
Discuss supported browser monitoring, submitted prompt history and the governance decisions your team needs to make.
Map your AI workflows