ATLAS AML.T0080: AI Agent Context Poisoning

One injected instruction that lands in an agent's memory, a long-running thread or its own system prompt keeps working long after the attacker has gone. MITRE ATLAS tracks this as AML.T0080 AI Agent Context Poisoning, in the Persistence tactic (AML.TA0006): adversaries manipulate the context an agent's LLM uses so that its behaviour changes persistently. ATLAS splits it into two sub-techniques, Memory (AML.T0080.000) and Thread (AML.T0080.001). Memory poisoning has its own deep guide, the AI Agent Memory Poisoning Guide, so this page concentrates on what that guide does not: the Thread sub-technique, shared threads in team channels, context reached through stolen credentials, agents that rewrite their own instructions, and an ATLAS-mapped detection and response runbook. It is for teams running agents in chat platforms, coding tools and desktop assistants, and for SOC analysts who will investigate them.

Key takeaways

Persistence is the defining feature. AML.T0080 is not a single prompt injection; it is the state left behind, in memory, in a thread or in configuration, that keeps steering the agent.
Threads are shared state. ATLAS notes that if an agent is active in a channel with several participants, one malicious message from one user can influence its behaviour towards others.
Longer context means longer persistence. ATLAS observes that rising token limits let malicious instructions persist longer in a thread.
Stolen tokens give direct access. ATLAS case study AML.CS0036 describes extracting authentication tokens from LLM desktop applications, which would let an attacker inject into the victim's threads and poison context directly.
ATLAS names Memory Hardening. AML.M0031 is the mitigation ATLAS links to AML.T0080; restricting tool use on untrusted data (AML.M0030) and telemetry (AML.M0024) carry the rest.

How the technique works

ATLAS created AML.T0080 in September 2025 and rates it as demonstrated. Context poisoning is usually the persistence step after AML.T0051 LLM Prompt Injection, direct or indirect. What makes it a separate technique is where the instruction ends up.

Where the instruction persists	ATLAS mapping	How long it lasts	Who it affects
Saved memory or user profile store	AML.T0080.000 Memory	Until someone deletes the entry	The user, across all future sessions
Conversation thread history	AML.T0080.001 Thread	For the rest of the thread, which may span many sessions	Everyone who uses that thread
Agent configuration or system prompt written by the agent	Recorded in ATLAS case study AML.CS0051	Until the configuration is restored	Every future run of the agent

For Thread, ATLAS lists two entry routes. Indirect injection arrives through content the agent reads, such as a web page, document or message. Direct injection is possible when an adversary has acquired a user's LLM API keys and can add queries to any thread. The second route turns a credential theft into a behaviour change that the real user may never notice.

Where it shows up

Agents in team chat channels: ATLAS gives the example of an agent active in a Slack channel with many participants. One message can set a "rule" the agent then applies to everyone, such as sending summaries to an outside address or treating a named person's instructions as authoritative.
Personal assistant memory: ATLAS case study AML.CS0040 records Embrace the Red's 2024 research, where a prompt injection hidden in a shared document, read through a connected app, wrote false memories that persisted across sessions. The researcher also reported creating dozens of memories in one shot.
Desktop LLM applications: ATLAS case study AML.CS0036 (AIKatz) describes researchers extracting authentication tokens from the memory of LLM desktop applications, which would let an attacker read conversations, inject prompts, poison context and alter conversation history to cover tracks.
Self-modifying agents: ATLAS case study AML.CS0051 records research in which a web page's indirect injection caused an agent to run a script that planted persistent instructions into its future system prompts, turning it into a command and control implant.
Coding agents: project instruction files and long coding sessions are both persistent context, and an instruction planted in either is re-read on every turn; see the AI Coding Agents Security Guide.

Impact

Effect of poisoned context	Example outcome
Data leakage	Agent includes private conversation content in outputs or tool calls to an attacker destination
Manipulation of the user	Agent promotes a hidden agenda or false facts, as ATLAS describes for Memory
Unauthorised actions	Agent applies a planted rule when it later has tools available, such as approving, sending or deleting
Cover-up	Attacker with session access edits history so the poisoning is hard to see (AML.CS0036)
Command and control	Persistent instructions let the attacker issue new commands through content the agent reads (AML.CS0051)

Detection

ATLAS mitigation AML.M0024 AI Telemetry Logging asks for logs of model inputs and outputs and, for agents, intermediate steps, data access, tool use and the agent's identity. Context poisoning detection depends on that record existing.

Data source	What to look for
Memory write events	Writes that contain imperative instructions, URLs, email addresses or references to other users; bursts of writes in one turn; writes made in the same turn as reading external content
Thread history	Messages that set standing rules ("from now on", "always", "for all future requests") in shared threads, especially from external or guest participants
Agent configuration files and system prompts	Any change not made through the deployment pipeline; hash and compare on every start
Tool call logs	New destinations or recipients that first appear after a context change, tools invoked shortly after untrusted content entered context
Session and token logs for LLM services	Use of a user's session or API key from a new device or network, history edits or deletions

D3FEND maps these to D3-UBA User Behavior Analysis for session anomalies and D3-FA File Analysis for configuration integrity. A simple, high-value control is an integrity check on agent configuration: an agent should never be able to change its own system prompt without a reviewed deployment.

Measuring it

Write provenance: share of memory and configuration writes that record their source (user, tool, document, agent).
Gated writes: share of instruction-like memory writes that required user confirmation.
Configuration drift: number of agent configuration changes detected outside the deployment pipeline.
Thread hygiene: median age and length of shared agent threads in team channels.
Time to purge: time from detecting a poisoned entry to removing it from every store and thread.

Prevention and hardening

AML.M0031 Memory Hardening: ATLAS describes trust boundaries for how an agent stores and accesses memory and context, including requiring external authentication and validation for memory updates, semantic integrity checks on retrieved memories before the agent acts, and monitoring and remediation processes for poisoned memory. The memory guide covers implementation in depth; see also the AI Agent Memory Security Guide.
AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data: once untrusted content enters context, block automatic tool calls or require confirmation. This stops a memory write or configuration edit being made as a side effect of reading a page.
AML.M0033 Input and Output Validation for AI Agent Components: validate content passed between tools and agents, and strip or flag instruction-like content before it is stored.
Bound thread lifetime: cap how long and how large a shared agent thread can grow before context is summarised or reset (our recommendation: reset shared channel context on a schedule, and summarise without carrying forward instructions from non-owners).
Separate principals in shared channels: have the agent treat only its owner or administrators as able to set standing rules, and treat other participants' messages as data.
Make agent configuration read-only to the agent: store system prompts and instruction files where the agent's runtime identity cannot write them.
Protect the session: short session lifetimes and device binding for LLM application tokens reduce the value of the token theft in AML.CS0036.

Implementation

Map persistent context: for each agent, list every place context persists: memory, threads, project files, system prompts, retrieval indexes.
Turn on logging: record writes to each store with source and identity, and keep thread history long enough to investigate.
Lock configuration: move system prompts and instruction files out of the agent's write path and add hash checks at start-up.
Gate writes in audit mode: flag instruction-like memory writes and standing-rule messages in shared threads for two weeks without blocking, to tune the rules.
Enforce: require confirmation for flagged writes and block tool calls after untrusted content, starting with agents that have send, write or delete tools.
Roll back safely: keep memory versioned so a bad rule can be reverted without wiping the store.

Where identity fits

Two identity questions decide most of this technique. First, who is allowed to change the agent's standing behaviour? In a shared thread the honest answer is often anyone who can post, and that should be narrowed to named owners. Second, what can the agent's own identity write? An agent whose runtime credentials can edit its configuration, its memory store and other agents' stores gives a single injection a durable foothold. Give the agent a distinct non-human identity with read-only access to its own configuration, and treat LLM application tokens and API keys as credentials that, if stolen, allow direct context poisoning. See the OWASP Agentic Top 10 ASI06 Guide for the OWASP framing of memory and context poisoning.

Response

Freeze the agent's write paths: pause memory writes and configuration changes for the affected agent while you investigate, keeping read-only service if possible.
Find every copy of the instruction: search memory stores, shared threads, configuration and instruction files, and retrieval indexes for the planted content.
Trace the entry point: identify the document, page, message or session that introduced it. If a stolen token is possible, revoke the user's sessions and keys.
Purge and restore: remove poisoned entries, restore configuration from the pipeline, and reset affected shared threads.
Assess actions taken: review tool calls made while the context was poisoned, and treat data sent to new destinations as potentially exposed.
Record and retest: log the incident against AML.T0080 and the sub-technique, and add the payload pattern to regression tests. See the Prompt Injection Incident Response Playbook.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0080, AML.T0080.000, AML.T0080.001 (AML.TA0006); preceded by AML.T0051	Technique, sub-techniques and entry step
MITRE ATLAS mitigations	AML.M0031, AML.M0030, AML.M0033, AML.M0024	Memory hardening, tool restriction, validation, telemetry
OWASP	LLM01:2025 Prompt Injection; Agentic Top 10 ASI06	Entry technique and persistent context risk
NIST SP 800-53 Rev. 5	SI-10, SI-7, AC-6, AU-12, SI-4	Input validation, integrity, least privilege, logging, monitoring
NIST CSF 2.0	DE.CM-09, DE.AE-02, RS.MI-01	Runtime monitoring, analysis, containment
MITRE D3FEND	D3-UBA, D3-FA	Session analytics and configuration integrity

Common failure patterns

Everlasting shared threads: an agent in a busy channel carrying months of context in which any participant could have set a rule.
Writable instructions: agents able to edit their own system prompt or project instruction files, which turns one injection into permanent control.
No memory audit trail: memory entries without source or timestamp, so nobody can tell which entry came from a hostile document.
Purging one store only: deleting the poisoned memory but leaving the same instruction in the thread or configuration, so it returns.
Ignoring token theft: treating LLM application sessions as low value, when they allow direct injection and history editing.

Practitioner checklist

List every persistent context store for each agent, including shared threads and instruction files.
Log memory and configuration writes with source, identity and timestamp.
Make system prompts and instruction files read-only to the agent's runtime identity, with hash checks.
Require confirmation for instruction-like memory writes and block tool calls after untrusted content on high-impact agents.
Limit who can set standing rules in shared threads, and reset shared context on a schedule.
Protect LLM application sessions and API keys as credentials, with short lifetimes and revocation.
Version memory so poisoned entries can be reverted.
Rehearse the response: freeze, find, trace, purge, assess, record.

Standards and references

Related NHI Mgmt Group resources: AI Agent Memory Poisoning Guide · AI Security Architecture Reference Guide · Prompt Injection Guide · MITRE ATLAS Guide

MITRE ATLAS AML.T0080 AI Agent Context Poisoning: Detection, Mitigation and Response