How the attack works
An attacker (or a malicious input embedded in content the agent processes) issues an explicit instruction such as 'remember this' or 'store this for future reference,' paired with a piece of information like a name, code word, or credential-like string. The agent writes this into its long-term memory store. In a later, unrelated session, the agent may retrieve and act on this planted fact, treating it as trusted prior context. This differs from memory-poisoning attacks that try to change the agent's behavior directly — here the goal is simply to get specific data persisted and later surfaced.
Why it matters
An organization could have sensitive data or misleading facts quietly seeded into an agent's memory, later resurfacing to enable social engineering, credential misuse, or corrupted decision-making in future conversations.
What you can do
- Review what triggers persistent memory writes and require explicit user confirmation before storing personal data or code-like strings.
- Periodically audit stored memory entries for secrets, codes, or unexpected personal data.
- Separate memory written by trusted users from memory derived from untrusted or external content the agent processes.
- Set expiration or review policies for persisted facts so old, unverified entries don't silently influence future sessions.
Known benign look-alikes
- Legitimate assistant memory features where users store personal preferences
- Note-taking agents designed to remember user-specified information
- Legitimate code storage/retrieval assistant features