MITRE ATLAS AML.T0092 Manipulate User LLM Chat History: Detection, Mitigation and Response

When an attacker can talk to an AI assistant as a user, the chat history that the user and the investigator rely on can be edited, pruned or padded to hide what happened. MITRE ATLAS tracks this as AML.T0092 Manipulate User LLM Chat History, in the Defense Evasion tactic (AML.TA0007). Adversaries delete or edit messages, or open new threads, to hide persistent changes they made to the model's behaviour or their attempts to discover private information about the user. The AI Agent Memory Poisoning Guide covers the persistent changes themselves; this page covers the cover-up: how attackers get the access, why the history is a weak record, where trustworthy evidence lives instead, and how to investigate. It is for owners of enterprise AI assistants, endpoint teams and incident responders.

Key takeaways

• The chat transcript is user-editable data, not an audit log. Anyone holding the user's session can change it, so it cannot be the only record of what the assistant did.
• Token theft is the usual entry point. ATLAS ties the technique to an adversary holding the victim's authentication tokens for the back-end service or direct access to the chat interface.
• The user may never see the change. ATLAS notes that desktop chat clients often load history once, when a chat is opened, so injected prompts in an ongoing chat can go unnoticed.
• Evidence must live outside the user's reach. Server-side or gateway logs that the user session cannot alter are what make an investigation possible.
• Suspect history tampering means a full session compromise. Revoke tokens, review memory and custom instructions, and treat everything the account could read as exposed.

How the technique works

ATLAS added AML.T0092 on 27 October 2025 and rates it as demonstrated. It is a follow-on technique: the attacker first gains the ability to act as the user, then uses that access for something else, and finally edits the history so the user does not notice. ATLAS links it to two case studies.

The ATT&CK equivalents for the access step are T1528 Steal Application Access Token and T1539 Steal Web Session Cookie. Infostealer malware routinely collects both; see the Infostealer Logs and Session Token Abuse Guide.

What the attacker is hiding

• Behaviour changes: prompts that set custom instructions, saved memories or thread context (ATLAS AML.T0080.000 Memory and AML.T0080.001 Thread) so the assistant keeps acting for the attacker.
• Discovery: questions that pull the user's private files, contacts or earlier conversations into the chat.
• Misuse of the user's identity: requests that make connected tools send messages or fetch data as the user.

Why chat history is a weak record

NIST SP 800-53 AU-9 Protection of Audit Information and the OWASP Logging Cheat Sheet make the same point for any system: build in tamper detection, copy logs to read-only storage quickly, restrict who can read and change them, and monitor access to them. Applied to AI assistants, that means the record of prompts, responses, tool calls and memory changes has to be written somewhere the user session cannot reach.

Prevention: protect the session and the record

Protect the tokens

1. Bind sessions to devices where the service supports it, so a token replayed from another machine fails or triggers re-authentication (NIST SP 800-53 SC-23 Session Authenticity).
2. Use short session lifetimes and re-authentication for sensitive actions such as changing memory, custom instructions or connected apps (AC-12 Session Termination, IA-11 Re-authentication).
3. Harden endpoints that run AI desktop clients. Process memory reading needs code on the host, so endpoint protection, least privilege and blocking unsigned code are the main defences. See the Electron and Desktop App Security Guide.
4. Keep agent control interfaces off the internet and behind authentication, as AML.CS0048 shows.

Protect the record

1. Route enterprise assistant traffic through a logging point you control, such as an AI gateway or the vendor's enterprise audit or compliance export, and store it in your log platform. ATLAS mitigation AML.M0024 AI Telemetry Logging recommends logging inputs, outputs, intermediate agent steps, tool use and the agent's identity.
2. Log memory and instruction changes as discrete events, with the session and client that made them. ATLAS AML.M0031 Memory Hardening describes requiring validation for memory updates and monitoring memory.
3. Keep the copy write-once and set retention to cover your investigation window (AU-9, AU-11 Audit Record Retention).
4. Record session metadata for each message: source IP, client type, token or session ID. Without it, a message from the attacker looks the same as one from the user.

Confirm what audit and export features your assistant offers in its vendor's current documentation; enterprise plans and consumer plans often differ. Our recommendation is to approve an assistant for sensitive work only once you can obtain a record of conversations and memory changes that users cannot edit.

Detection and measurement

D3FEND D3-UBA User Behavior Analysis supports the session anomaly signals; see the AI Agent Behaviour Baselining and Anomaly Detection Guide for baselines.

Metrics

• Tamper-resistant coverage: share of approved assistants whose prompts, responses and memory changes are captured in a log users cannot edit.
• Session binding: share of assistant sessions bound to a managed device.
• Token lifetime: median session lifetime for assistant clients.
• Reconciliation tests: number of quarterly tests where a planted edit was correctly detected by comparing logs.

Investigating suspected chat history manipulation

1. Preserve first. Export the server-side or gateway record for the account before anyone changes the account. Capture the user's visible history as a separate artefact for comparison.
2. Revoke sessions and tokens. Sign the user out everywhere, revoke refresh tokens and reset credentials. If a desktop client token was stolen, treat the endpoint as compromised and follow the Session Token Theft Response Playbook.
3. Reconcile the two records. Messages present in the audit log but absent from the visible history, or edited after the fact, show what the attacker hid.
4. Review persistent state. Check saved memories, custom instructions, connected apps and scheduled tasks. Remove anything the user did not create; see the AI Agent Memory Security Guide.
5. Scope exposure. List every file, connector and earlier conversation the account could reach during the compromise window and assess it as disclosed.
6. Build the timeline from tool calls and identity logs, not the transcript. The Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs guide describes the method.

Framework mapping

Common failure patterns

• Investigating from the transcript: the analyst reads the user's chat history and concludes nothing happened.
• Consumer accounts for work: staff use personal assistant accounts, so the organisation has no audit record at all.
• Revoking the password but not the tokens: the stolen session keeps working.
• Cleaning history but not memory: the visible chat is restored while saved memories or custom instructions still carry the attacker's changes.
• Logs without session metadata: prompts are logged, but nothing shows which device or network sent them.

Practitioner checklist

• Inventory approved AI assistants and the audit records each can produce.
• Capture prompts, responses, tool calls and memory changes in a log users cannot edit.
• Record source IP, client and session ID for each message.
• Bind assistant sessions to managed devices and shorten token lifetimes.
• Require re-authentication for memory, instruction and connector changes.
• Alert on deletions or edits that follow memory changes, and on token reuse from new networks.
• Keep agent control interfaces authenticated and off the internet.
• On suspicion: preserve logs, revoke all sessions, reconcile records, and review memory and connectors.

Standards and references

• MITRE ATLAS: Manipulate User LLM Chat History
• MITRE ATLAS: AIKatz: Attacking LLM Desktop Applications
• MITRE ATLAS: Exposed ClawdBot Control Interfaces Leads to Credential Access and Execution
• MITRE ATLAS: AI Telemetry Logging
• MITRE ATT&CK: Steal Application Access Token (T1528)
• NIST: SP 800-53 Rev. 5
• OWASP: Logging Cheat Sheet

Related NHI Mgmt Group resources: AI Agent Memory Poisoning Guide · AI Agent Observability and Incident Response Guide · AI Agent Audit Trails for Regulators Guide · MITRE ATLAS Guide