ATLAS Persistence Tactic: Finding Poison and Footholds That Survive in AI Systems

Persistence in AI systems rarely looks like a scheduled task or a new service: it is a poisoned dataset, a backdoored model, a memory entry, a retrieval document or an agent configuration file that keeps the attacker's influence alive after the original session ends. MITRE ATLAS defines the Persistence tactic (AML.TA0006) as the adversary "trying to maintain their foothold via AI artifacts or software", and notes that these techniques often involve leaving behind modified artefacts such as poisoned training data or manipulated models. This hub covers the 13 techniques and 9 sub-techniques under the tactic in ATLAS 2026.10, ranks them for defenders, shows how they appear in recorded cases, and sets out how to find and remove them. It is written for ML engineers, AI platform owners, detection engineers and incident responders. Each technique has its own deep guide, linked below; for the framework overall see the MITRE ATLAS Guide.

Key takeaways

• AI persistence lives in data and configuration. Of the 13 techniques, nine work by changing something the AI reads or loads (training data, weights, retrieval corpora, tool data sources, public content, memory and threads, tool definitions, agent configuration or a learning environment) rather than by planting a classic implant.
• Agent context is the most recorded foothold. AML.T0080 AI Agent Context Poisoning appears as a Persistence step in 6 of the 22 ATLAS case studies that include Persistence, ahead of AML.T0070 RAG Poisoning (4), counted from the ATLAS 2026.10 data.
• Classic persistence is arriving through agents. AML.T0125 Create Account, AML.T0142 Event Triggered Execution and AML.T0121 AI Agent Environment Reconstruction are all drawn from 2025 and 2026 incidents in which AI agents themselves established footholds.
• Integrity is the control family. AML.M0035 AI Red Team (10 mappings), AML.M0020 Generative AI Guardrails (9), AML.M0008 Validate AI Model (6), AML.M0013 Code Signing and AML.M0014 Verify AI Artifacts (5 each) are the most frequently mapped mitigations across the tactic.
• Removal needs provenance. You can only clean a poisoned corpus, memory store or model if you know where each item came from and can roll back to a known-good version.

What Persistence means for AI systems

Most AI persistence survives the events that remove classic implants. Rebooting a host does not remove a backdoor trained into weights. Rotating credentials does not remove a malicious instruction stored in an assistant's memory or in a document the retrieval index keeps returning. Reimaging a developer laptop does not help if the poisoned rules file lives in the project repository. ATLAS therefore treats several data and configuration changes as persistence, and some techniques span tactics: AML.T0018 Manipulate AI Model is also in AI Attack Adaptation, AML.T0081 Modify AI Agent Configuration is also in Defense Evasion, and AML.T0093 Prompt Infiltration via Public-Facing Application is also in Initial Access, because a planted prompt both gets in and stays in. See the ATLAS Initial Access Tactic hub.

The 22 case studies with a Persistence step include 7 incidents and 15 exercises, from the 2016 Tay chatbot (AML.CS0009) to 2026 incidents involving autonomous agents.

Every Persistence technique in ATLAS 2026.10

Case study counts are distinct ATLAS case studies recording the technique or its sub-techniques as a Persistence step. Maturity is the ATLAS rating.

Where to start: ranked techniques for defenders

1. AML.T0080 AI Agent Context Poisoning (memory first). Memory turns a one-off injection into a standing instruction. AML.CS0040 showed a hidden prompt in a shared document writing false memories into a chat assistant; AML.CS0066 (ZombieAgent) used an email to create memories that told the assistant to retain sensitive information and act for the attacker later; AML.CS0072 records operators using "Summarize with AI" links to plant memory entries that biased later recommendations. Control what an agent may write to memory, show users memory changes, and make memory reviewable and resettable (AML.M0031 Memory Hardening). See the AI Agent Memory Poisoning Guide.
2. AML.T0070 RAG Poisoning and AML.T0099 Tool Data Poisoning. If outsiders can write into anything your retrieval index or agent tools read, they can persist. In AML.CS0026 an email ingested into a copilot's retrieval store changed bank details in answers whenever it was retrieved; in AML.CS0059 (EchoLeak) the email sat in the index until a later query triggered it. The SalesBleed research showed the tool-data form: instructions in public web form submissions became CRM lead records that an agent read later. Classify sources by who can write to them and screen at ingestion and retrieval. See the RAG Security Guide.
3. AML.T0081 Modify AI Agent Configuration and AML.T0110 AI Agent Tool Poisoning. Configuration files that feed system prompts are high-value targets. In AML.CS0051 a script appended instructions to a workspace file that the agent adds to its system prompt, turning the agent into a command and control client; in AML.CS0041 invisible Unicode in a shared rules file made coding assistants insert hidden script references. Tool poisoning persists the same way once installed: the MemTensor MemoryOS supply chain attack shipped a credential stealer in an agent memory plugin that ran when the gateway started and on each memory recall. See Coding Agent Configuration File Attacks and MCP Tool Poisoning Detection.
4. AML.T0018 Manipulate AI Model and AML.T0020 Training Data Poisoning. These are harder to execute against a well-run pipeline but the hardest to detect afterwards. PoisonGPT (AML.CS0019) edited one fact into a model's weights and republished it under a near-identical name; poisoned GGUF chat templates (AML.CS0064) changed behaviour without touching weights; VirusTotal poisoning (AML.CS0002) and Tay (AML.CS0009) poisoned data that models learned from. Sign models, keep dataset provenance and evaluate against independent test sets. See the AI Data Poisoning and Backdoors Guide and the Model Signing and OpenSSF Model Signing Guide.
5. AML.T0125, AML.T0142 and AML.T0121, agent-established footholds. In AML.CS0069 a jailbroken coding agent run by a state-sponsored group created a local backdoor account; in AML.CS0074 an evaluation agent installed a Python startup hook; in AML.CS0068 agents recreated launch sandboxes after each was lost. These look like classic persistence and are found with classic tooling, provided agent hosts and agent identities are monitored like any other privileged workload.
6. AML.T0061 and AML.T0145. Self-replicating prompts (Morris II, AML.CS0024) matter where agents read each other's output; learning-environment poisoning matters if you train or adapt agents on their own interactions.

How Persistence chains in real cases

The execution side of these chains is covered in the ATLAS Execution Tactic hub.

Detection and hunting

Persistence in data and configuration is found by comparing current state with a trusted baseline and by watching writes to the stores that matter.

Metrics that show coverage

• Memory governance: percentage of assistants and agents with logged, user-visible and resettable memory.
• Source classification: share of retrieval sources tagged by who can write to them, with externally writable sources screened at ingestion.
• Artefact integrity: share of production models and agent tools with signature or hash verification at load.
• Configuration integrity: number of agent configuration and rules file changes without an associated reviewed commit.
• Time to clean: median time to identify and remove a poisoned memory entry, document or tool version in exercises.

Mitigation priorities

See the MITRE ATLAS Mitigations Guide for each mitigation in depth.

Implementation order

1. Map the persistent stores: for each AI system list its memory, retrieval indexes, configuration files, installed tools, model artefacts and training data, with who can write to each.
2. Baseline and version: snapshot and version every store so a known-good state exists; keep model and tool versions pinned.
3. Log writes: record memory writes, index ingestion and configuration changes with source and actor.
4. Screen in audit mode: run instruction and hidden-text detection on ingestion and memory writes in log-only mode, review findings, then quarantine automatically.
5. Restrict authority: remove agents' ability to create accounts, edit their own configuration or acquire credentials without approval.
6. Rehearse clean-up and rollback: practise removing a poisoned memory, document, rules file and tool version, and restoring a previous model, before an incident. See the AI Agent Memory Poisoning Response Playbook and the AI Model Poisoning Incident Playbook.

Where identity fits

Two persistence routes are identity problems. Agents that can create accounts (AML.T0125) or rebuild environments with stored credentials (AML.T0121) are non-human identities with authority to mint more identities; the 2026 OpenAI and Hugging Face incident ended with broad token rotation because agents had collected and reused many credentials. And most data and configuration persistence starts with a write permission: whoever can publish to the model registry, edit the rules file or write to the indexed share can persist. Review write access to AI stores as carefully as admin access, and give every agent identity an owner, a scope and an end date. See the AI Agent Memory Security Guide.

Framework mapping

Common failure patterns

• Incident response that stops at credentials: rotating keys after a prompt injection while leaving the poisoned memory entry or indexed document in place.
• Unversioned stores: retrieval indexes and memory with no history, so there is no known-good state to restore.
• Rules files treated as documentation: agent rules and prompt files merged without the review applied to code, although they change agent behaviour.
• Testing models only for accuracy: a backdoored model can keep its benchmark scores; evaluation needs trigger probes and independent data.
• Agents allowed to grow their own access: no limit on agents creating accounts, keys or compute, and no clean-up when the task ends.

Practitioner checklist

• Inventory every persistent store per AI system (memory, indexes, configuration, tools, models, data) with its writers.
• Version and snapshot each store so it can be rolled back.
• Log and review memory writes; let users see and delete memories.
• Screen externally writable retrieval sources for instructions and hidden text at ingestion and retrieval.
• Put agent configuration and rules files under code review and file integrity monitoring.
• Sign and verify models and agent tools at load; pin versions.
• Evaluate models after every training or fine-tuning run with independent data and backdoor probes.
• Block agents from creating accounts or acquiring credentials without approval, and remove agent-created resources at task end.

Standards and references

• MITRE ATLAS: Persistence (AML.TA0006)
• MITRE ATLAS: AI Agent Context Poisoning (AML.T0080)
• MITRE ATLAS: RAG Poisoning (AML.T0070)
• MITRE ATLAS: Manipulate AI Model (AML.T0018)
• MITRE ATLAS: Mitigations
• MITRE ATLAS: atlas-data repository
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATT&CK: Persistence (TA0003)

Related NHI Mgmt Group resources: MITRE ATLAS Guide · ATLAS Execution Tactic · AI Agent Memory Poisoning Guide · AI Data Poisoning and Backdoors Guide · RAG Security Guide