All insights
Industry newsAug 25, 2026Source: arXiv / COLM 2026

COLM study shows one interaction can poison later AI agent memory responses

AI security team tracing a poisoned memory record from one interaction into later agent responses and tool controls

Researchers have shown that a single interaction can plant a persistent instruction in an AI agent's memory and influence later answers on the same topic. The InjecMEM study, submitted on 24 August 2026 and accepted at COLM 2026, treats memory as a security boundary rather than a neutral convenience feature.

The result does not show that every memory-enabled agent is vulnerable. The experiments focus mainly on MemoryOS and also test MemGPT, using several open-weight model families and a controlled, non-operational target output. The strongest attack also assumes access to the model backbone for optimization. Within those limits, the paper provides a concrete warning: an attacker may not need direct database access to poison long-lived agent state.

How the InjecMEM attack works

Many agents save past interactions, retrieve relevant records, and place them into a later prompt. InjecMEM targets both parts of that loop.

First, the attacker sends one crafted interaction containing a topic anchor. The anchor uses broad cues so that the memory system associates the record with a target topic such as health or finance. Second, the interaction contains an adversarial command optimized to remain effective when the record appears at different positions inside a long, changing prompt.

When a later user asks a benign question about the target topic, the memory system may retrieve the poisoned record. If retrieval succeeds, the command can steer the model toward a preselected output. The attacker does not need to read or edit the memory store directly.

The paper also describes an indirect route. A compromised tool could return malicious text that the agent logs as memory. Repairing the tool would not automatically remove the stored record, so the influence could remain after the original entry point is closed.

What the experiments found

The authors separate retrieval success from generation success. Retrieval success asks whether the poisoned record appears for a later topic-related query. Conditional attack success asks whether the model produces the target output after that record is retrieved.

Experimental resultMemoryOSMemGPT
Average poisoned-record retrieval success46.5%37.2%
Conditional targeted-generation success76.6%48.6%
Joint end-to-end success reported by the paper35.6%18.1%

These are research results from the authors' setup, not production incident rates. The target output was deliberately non-operational. The study says the attack remained effective as benign memories accumulated and transferred within some model families. Cross-family transfer was less reliable. A command optimized on Qwen and Mistral did not transfer to an unseen Llama model in one test, although concatenating commands designed for separate backbones produced measurable success across all three evaluated families.

The study also tested retrieve-time prompt-injection filters. At the selected thresholds, an LLM judge, ProtectAI, and PromptGuard reduced retrieval in some cases but left conditional attack success near the undefended level. A perplexity filter suppressed the evaluated attack, but blocked 71.8% of benign pages in the same setup. That trade-off matters: filtering alone can create an unusable memory system without reliably solving the underlying trust problem.

Why persistent memory changes the security model

A normal prompt injection may affect one response. A poisoned memory can reappear later, after the original interaction has been forgotten by the operator. It can also reach another workflow if memory is shared across tasks, users, or agents.

OWASP independently identifies memory and context poisoning as an agentic security risk. Its guidance treats stored context, summaries, hooks, and local configuration as security-relevant state because they can shape later planning and tool use. That broader threat model supports the paper's concern, but it does not independently reproduce the InjecMEM percentages.

For teams operating tool-using agents, the consequence is larger than a bad answer. A retrieved instruction may influence which API is called, what data is disclosed, or whether a later action remains aligned with the user's task. Maetra's guide to prompt injection controls for AI agents explains why content inspection should be paired with narrow authority over external effects.

Six controls to review now

  1. Treat memory writes as untrusted input. Scan and classify candidate records before they become persistent state. Do not assume an agent-generated summary is safe.
  2. Record provenance. Keep the source, user or tool identity, timestamp, task, and transformation history for every memory item.
  3. Separate tenants and tasks. Prevent a record from crossing user, workspace, or purpose boundaries unless an explicit policy allows it.
  4. Apply retention and revocation. Give sensitive memories an expiry, support targeted deletion, and invalidate records linked to a compromised source.
  5. Check at write time and read time. A detector at retrieval may miss an attack or block too much benign content. Use validation, anomaly detection, and policy at both stages.
  6. Limit the effect of retrieved text. Retrieved memory may inform reasoning, but it should not grant credentials or authority. Consequential tool calls still need an independent control point and useful AI audit evidence.

Testing should include single-interaction poisoning, indirect tool output, memory drift, shared-memory boundaries, deletion, incident recovery, and model changes. Teams should also verify that a poisoned record cannot silently regain influence after an index rebuild or backup restore.

What remains uncertain

The paper is an accepted conference study, but it is still a bounded evaluation. Its strongest optimization uses model access that an attacker may not have. Systems that heavily rewrite or summarize interactions before storage may behave differently. The authors also do not show reliable zero-shot transfer to every unseen model family.

No team should turn the reported percentages into a universal risk estimate. A practical assessment must use the actual memory implementation, retrieval logic, model, prompt format, tools, permissions, and data boundaries in production.

Maetra analysis: memory needs its own control lifecycle

Agent memory should be inventoried like any other consequential capability. Teams need to know what is stored, who or what wrote it, where it can be retrieved, which actions it can influence, and how it is revoked.

Start with one agent that retains cross-session context. Trace one memory item from ingestion to retrieval and then to any tool call or external effect. If the record can affect an action without provenance, policy, or evidence, the memory layer is already part of the control plane even if the product describes it only as personalization.

Sources

AI agent memory poisoningInjecMEMpersistent prompt injectionagent memory security
COLM study shows one interaction can poison later AI agent memory responses | Maetra Insights