Agent Plan Poisoning: When Injected Content Rewrites an Agent's Own Task List

Agent plan poisoning is SSA descriptive wording for a security-relevant change to a narrower object than an agent's goals or memory: the live task list, step sequence, or plan object an agent builds during a session and re-reads on every subsequent turn to decide what to do next. The defining cause is untrusted content, usually a tool result or a retrieved page, that the agent's planning step treats as a legitimate reason to add, reorder, or mark complete an entry in that list. The defining consequence is that a step the user never reviewed executes with whatever tool authority the session already holds, because the plan itself is the thing telling the agent what counts as its current, approved work.

What it is

The defining object is the plan or task-list artifact itself: a structured, usually tool-visible list of steps an agent maintains across a multi-turn task, distinct from the system prompt or configuration file that set the agent's original goal and distinct from the durable memory store that persists across sessions. Modern coding and browsing agents make this object explicit rather than implicit. Anthropic's Claude Agent SDK, which powers Claude Code, documents an agent loop built around planning its own steps and calling tools in sequence, with a checklist-style task-tracking tool that moves entries through pending, in-progress, and completed states, visible on every turn, and a newer disk-persisted task system extending the same object across sessions (Claude Docs, Agent SDK overview). Earlier autonomous-agent frameworks such as Auto-GPT made the same object explicit as a `next_action` and goal-stack loop the model re-reads on every cycle.

The defining cause is a party who cannot talk to the model directly but can place content somewhere the agent will read it mid-task: a web page it summarizes, a file it opens, a tool result it receives. The defining consequence is a plan mutation that looks, to the agent's own reasoning, like ordinary task management rather than an external command, because the plan object is designed to be rewritten by the agent itself throughout a session.

This differs from the entry paths already documented on this site by which state changes and when. Instruction file poisoning changes what the agent believes going into a session, before any task begins. Persistent memory injection changes what the agent recalls across sessions through an explicit memory-write call. Agent plan poisoning changes what the agent has decided to do next, mid-task, through the ordinary step-tracking mechanism the agent uses to manage its own work.

What it is not

A user explicitly asking the agent to add, remove, or reorder a step, including a request the user later regrets.
Goal hijacking through the system prompt or a configuration file, covered by instruction file poisoning, where the untrusted write targets what loads before a session starts rather than the plan an agent builds during one.
A memory-write tool call that persists a belief across sessions, covered by persistent memory injection.
General prompt injection with no distinguishable plan or task-list object involved, covered by agent state attack's broader definition.
Reproducible exploit payloads or step-by-step instructions for manipulating a specific product's planning tool.

In scope

Tool results, retrieved pages, or file contents that an agent's planning step reads as a reason to add a new step to its own task list.
Injected content that reorders remaining steps so a step the user would have questioned runs earlier, before scrutiny catches up.
Injected content that marks a safety-relevant step complete without it having actually run, so a later step proceeds on a false premise.
The specific risk multiplier when a plan object persists to disk across sessions rather than staying scoped to one context window.
Detection and containment for the plan surface specifically, distinct from the general prompt-injection literature this pattern draws on.

Target state and trust boundaries

The target state is the plan or task-list object and, transitively, every tool call the agent issues because that object told it to. The trust boundary that fails is the one between "the user approved this task" and "the agent's own bookkeeping says this step is next." Most agent architectures extend the authority granted for the original task to every step the planning mechanism later adds, because re-approving each generated step individually would defeat the purpose of an autonomous loop. That design choice is also the vulnerability: once untrusted content can write to the plan, it inherits whatever authority the plan already carries.

The risk compounds where the plan persists past the session that created it. A task-list object scoped to one context window limits a poisoned entry's lifetime to that window. A plan object written to disk and reloaded in a later session, such as a cross-session task system layered on top of in-context checklist tracking, gives an injected step a longer runway: it can survive a compaction event, a session restart, or a handoff to a different agent that trusts the persisted plan without re-deriving it from the original request.

What the research establishes

The clearest documented case predates the current wave of coding agents but demonstrates the exact mechanism. Security researchers at Positive Security disclosed an indirect prompt injection vulnerability in Auto-GPT in mid-2023: content planted on a web page the agent was asked to summarize was interpreted by the model as an instruction rather than data, and low-effort phrasing was sufficient, the researchers noted that "it was completely sufficient to give the model straight up instructions with no backstory or warm-up." The injected content drove the agent to write and then execute a Python file, and in a further escalation, to rewrite its own Docker Compose configuration to grant itself privileged, host-level access before restarting the container. Three CVEs were assigned to the disclosure: CVE-2023-37273 for the Docker escape, CVE-2023-37274 for a path-traversal sandbox escape, and CVE-2023-37275 for an ANSI-escape-sequence injection into the terminal (Positive Security, Hacking Auto-GPT and escaping its docker container, 2023-06-29). What made the chain work was not a flaw in Auto-GPT's sandbox alone; it was that the agent's own next-action loop treated the injected text as a legitimate addition to its task list, no different from a step the user had actually requested.

More recent benchmark research shows the same class of attack generalizes across today's tool-calling agents rather than being specific to one now-superseded framework. AgentDojo, an evaluation environment built by researchers including Edoardo Debenedetti and Florian Tramèr, tests 97 realistic agent tasks, such as managing an email client or an e-banking workflow, against 629 security test cases where "data returned by external tools hijacks the agent to execute malicious tasks." The paper's central finding is that more capable models were not more resistant to this class of attack and were, in several configurations, easier to redirect (AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents, arXiv 2406.13352). AgentDojo's own task-and-tool-result framing matches the plan-poisoning mechanism directly: the injected content does not need to reach the system prompt to redirect the agent, it only needs to reach the tool result the agent's planning step reads next.

Persistence

A poisoned entry in a session-scoped plan persists only as long as that context window does, which limits its blast radius to the current task but still leaves enough runway to reach a destructive tool call before the session ends. A poisoned entry in a disk-persisted, cross-session plan object persists until a human or an automated check removes it, and it re-enters the agent's working context on every session that reloads that plan, including a session run by a different agent instance that has no reason to distrust a plan it did not itself generate.

Detection: observable signs

A new step appears in the task list with no corresponding user message requesting it, immediately following a tool call that returned external content.
A step is marked complete with no corresponding tool call or output evidencing that it actually ran.
The plan's step order changes such that a higher-risk step, one touching credentials, payments, or destructive file operations, moves earlier relative to steps that would ordinarily precede and gate it.
A cross-session or disk-persisted plan object differs from the last version a human reviewed, with no explicit user edit recorded.
The same injected step phrasing recurs across unrelated sessions that processed the same external content, such as the same web page or shared document.

Useful telemetry includes a diff between the plan object at the start and end of each turn, tagged by whether the turn's triggering input was direct user text or a tool result, and a persisted, append-only history of every plan mutation with the tool call that produced it.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Provenance tagging on plan mutations | A tool-result-triggered plan write being treated the same as a user-triggered one | Any agent whose planning tool can be called as a side effect of processing external content | Tagging only helps if a downstream gate actually reads the tag before executing a newly added step; verify the gate exists, not just the tag. | | Re-approval for steps added outside direct user turns | A step the user never saw reaching execution with the original task's authority | Autonomous or semi-autonomous agents that add plan steps without a human in the loop | Approval fatigue can turn re-approval into a rubber stamp; measure whether reviewers actually reject anything, not only whether a prompt appears. | | Step-completion verification independent of the agent's own claim | A step marked complete with no evidence it ran, letting a later step proceed on a false premise | Multi-step tasks with a safety-relevant gating step, such as a confirmation or a scope check | Verification logic itself can be spoofed if it trusts the same tool-result channel the injection used; anchor verification to a separate, harder-to-forge signal. | | Session-scoped plans by default, cross-session persistence opt-in | An injected step surviving past the context window that first admitted it | Agents where disk-persisted task tracking is optional rather than mandatory | Opt-in persistence still needs the same diff and review controls once enabled; scoping down the default does not secure the persisted case. | | Plan diffing against the originating task description | Gradual step accumulation drifting the plan away from what the user actually asked for | Long-running or multi-session agent tasks | A diff against the original request catches drift but not a first step that was poisoned before any legitimate steps existed to diff against. |

Containment should freeze the plan object and halt further step execution on the first confirmed unauthorized mutation, rather than letting the agent continue while a review happens in parallel. Recovery should rebuild the plan from the original user request rather than trusting the most recent pre-incident version, since the poisoned entry may have been present for longer than the point at which it was first noticed.

Boundaries with similar concepts

Agent plan poisoning is a specific instance of what MITRE ATLAS classifies at the technique level as indirect prompt injection reaching an agentic decision loop, and of what OWASP's Agentic Top 10 names as goal redirection, but it is narrower than either. `ASI01 Agent Goal Hijack` covers redirection of an agent's governing objective broadly, which can happen through a system prompt, a configuration file, or a single turn's instruction; agent plan poisoning specifically targets the intermediate task-list artifact the agent itself maintains and re-reads, which is a narrower and more mechanically distinct object than the governing objective itself.

This differs from slopsquatting in what gets fabricated: slopsquatting covers an agent hallucinating a dependency name with no adversary required, while agent plan poisoning requires an adversarial party placing content the agent reads. A single incident can involve both: a poisoned plan step could instruct the agent to install a package, and a slopsquatted or typosquatted name could be what actually gets installed once that step executes.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | OWASP Top 10 for Agentic Applications 2026 | `ASI01 Agent Goal Hijack` | Broader risk category; this article covers the narrower case where the redirected object is the agent's own live task-list artifact rather than its governing objective as a whole. | | MITRE ATLAS v2026.06 | `AML.T0051 LLM Prompt Injection`, sub-technique `.001 Indirect`; `AML.T0080 AI Agent Context Poisoning` | Attacker-behavior classification for the delivery mechanism and the resulting state effect. | | Positive Security (2023-06-29) | Auto-GPT indirect prompt injection; CVE-2023-37273, CVE-2023-37274, CVE-2023-37275 | Direct, CVE-documented evidence that injected content reaching an agent's action loop can escalate to sandbox escape. | | AgentDojo, arXiv 2406.13352 | Tool-result-triggered agent hijacking benchmark | Research evidence the pattern generalizes across modern tool-calling agents and does not diminish with model capability. | | Claude Docs | Agent SDK task-tracking tooling | Vendor documentation describing a persistent, tool-visible task-list object of the kind this article's target state generalizes from; cited descriptively, not as a reported vulnerability. | | Agent State Attack | Agent plan poisoning | SSA descriptive phrase, not attributed to the sources above. |

Related terms

Agent state attack: the umbrella definition, including goals and plans among the listed target states.
Instruction file poisoning: the adjacent surface targeting what loads before a session starts, rather than a plan built during one.
Persistent memory injection: the adjacent surface targeting an explicit memory-write call rather than the ordinary step-tracking mechanism.
Slopsquatting: a boundary case where a poisoned plan step and a hallucinated package name compound in the same incident.
Detecting agent state attacks: a cross-surface telemetry and signal model: the signal families this article's detection section draws from.

FAQ

Is this just prompt injection with an extra step?

The delivery mechanism is ordinary indirect prompt injection. What distinguishes agent plan poisoning is the target: a structured, tool-visible object the agent itself maintains and re-reads to decide what to do next, rather than the model's immediate response to one turn. That distinction matters defensively, because a plan object can be diffed, versioned, and gated in ways a single generated response cannot.

Does this only affect autonomous agents with no human in the loop?

No, though the risk is largest there. Even a human-supervised agent that shows its task list to a user before executing each step is vulnerable if the injected step is worded plausibly enough to pass a quick visual review, or if the agent batches several steps before the next checkpoint. Supervision reduces the window of unreviewed execution; it does not remove the entry path.

How is this different from the Auto-GPT Docker escape case specifically?

The Docker escape was one consequence reached through this mechanism, not the mechanism itself. The underlying pattern, an agent's own action loop treating injected web content as a legitimate next step, is the same pattern that can add a lower-severity step, such as an unwanted email send or file write, with no sandbox escape involved at all. Treat the CVE as evidence the mechanism is real and severe, not as the only outcome worth defending against.

Does disabling persistent, cross-session task tracking eliminate the risk?

It removes the cross-session persistence multiplier specifically, at the cost of losing plan continuity across a restart or handoff. The session-scoped version of the same mechanism remains: a poisoned step can still execute within the current context window before the session ends, which is why provenance tagging and re-approval controls are needed regardless of whether cross-session persistence is enabled.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); CVE-2023-37273, CVE-2023-37274, CVE-2023-37275.

Last verified: 2026-09-11. The Positive Security disclosure details, the AgentDojo abstract and task counts, and the Claude Agent SDK overview description were read from the sources' own pages on this date. The OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entries.

Change history: 2026-09-11, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** CVE-2023-37273, CVE-2023-37274, and CVE-2023-37275 are Standard-identified vulnerabilities. `ASI01` and `AML.T0051` / `AML.T0080` are Standard Terms owned by OWASP and MITRE. "AgentDojo" is a research-project term owned by its authors. "Agent plan poisoning" is SSA descriptive wording, not a standard or industry term.