Can One Prompt Poison An AI Agent's Memory Across Future Sessions?
InjecMEM shows how one crafted interaction can steer later topic-related answers—but the strongest result needs backbone access and is not a reported consumer breach.
Yes—one deliberately engineered interaction can poison an AI agent's stored memory and influence later, topic-related answers in a new research attack called InjecMEM. But the result is narrower than the most alarming headlines suggest. The researchers did not report a breach of ChatGPT, Claude, Gemini, or another consumer assistant, and their strongest attack requires white-box access to the agent's underlying language model while it is being optimized.
The important finding is that prompt injection may outlive the conversation where it arrives. If an agent automatically saves untrusted interaction text, a crafted memory can be retrieved days or sessions later when the user discusses a related subject. At that point, a hidden command inside the stored record can try to steer the model again.
In the paper's strongest MemoryOS experiment, the poisoned record was retrieved for 46.5% of related test queries. When it was retrieved, the command achieved the attacker's target 76.6% of the time. End to end—requiring both retrieval and successful steering—the attack worked on 35.6% of test queries. Those are consequential laboratory results, not proof that 76.6% of real-world AI agents can be compromised by any random prompt.
The practical lesson is immediate: memory must be treated as a security boundary, not merely a convenience feature. An agent should not automatically convert every email, web page, tool result, or conversation turn into trusted long-term instructions.
What Is Confirmed
The primary source is the August 24, 2026 preprint “InjecMEM: Agent Memory Is The New Prompt Injection Attack Surface”. The authors, affiliated with Shanghai Jiao Tong University and Ant Group, say the paper was accepted at COLM 2026.
The researchers demonstrate a memory-poisoning attack against two agent-memory systems, MemoryOS and MemGPT. Their threat model has several important properties:
- The attacker gets one ordinary interaction with the agent.
- The attacker does not need direct read or write access to the memory database.
- The interaction is designed to look valuable enough for the agent to store.
- A topic-rich “retrieval anchor” makes the stored record likely to resurface during later related questions.
- An optimized adversarial command tries to steer the model once that memory enters the new prompt.
The attack is persistent in the specific sense tested by the paper: the malicious instruction is stored in memory during one interaction and can affect later interactions after being retrieved. It does not require the attacker to remain in the later conversation.
The authors evaluated three separate rates. Keeping them separate prevents a misleading interpretation of the headline numbers.
| Metric | What it measures | MemoryOS | MemGPT |
|---|---|---|---|
| Retrieval success rate, or RSR | How often a later related query retrieves the poisoned record | 46.5% | 37.2% |
| Conditional attack success, or ASR-c | How often the command succeeds after the poisoned record is retrieved | 76.6% | 48.6% |
| Joint attack success, or ASR-j | How often retrieval and steering both succeed end to end | 35.6% | 18.1% |
The 76.6% result is therefore conditional, not universal. The end-to-end figure for that MemoryOS setup is 35.6%. The distinction matters because a malicious memory that is never retrieved cannot influence the later answer through this path.
The paper also tests several defenses. Common prompt-injection classifiers and an LLM-as-judge filter reduce retrieval and joint success in the reported setup, but they do not eliminate the attack. A strict perplexity filter blocks the tested poisoned memories, yet also blocks 71.8% of benign memory pages at the chosen threshold. That false-positive rate would make the defense difficult to use as a general answer by itself.
Independent coverage from CSO Online, Salient Security, and the AI Governance Institute shows that the research is attracting security attention. That attention is evidence of relevance, not independent replication of the experimental results.
What Is Still Unclear
No reviewed source establishes that InjecMEM has been used against a deployed consumer AI product or that a named provider's production memory system is vulnerable to the attack as published.
Several limitations in the paper constrain what can be claimed:
- The strongest attack uses white-box optimization. The researchers optimize the adversarial command with access to the backbone model. An ordinary attacker targeting a closed commercial model may not have that access.
- Cross-family transfer is unreliable. A command optimized for one model family did not reliably transfer to an unseen family in a reported test. The paper shows that commands can be optimized for multiple known families, but that is different from a universal payload.
- The evaluated memory systems preserve interaction text. Agents that rewrite, summarize, normalize, or structurally validate content before persistence may behave differently. The paper does not prove those designs are immune; it says the demonstrated attack may require adaptation.
- The study is a controlled benchmark. Real agents vary in their memory-selection rules, retrieval algorithms, system prompts, models, tool permissions, and user-confirmation gates.
- Persistence does not automatically mean data theft or code execution. Steering an answer is one capability. Exfiltrating data, changing a record, or running a command also requires accessible data, tools, permissions, and an action path.
- COLM acceptance is not a production incident report. Peer review can improve research quality, but it does not substitute for independent reproduction across deployed systems.
The paper also does not justify the claim that “one random sentence can hack any AI forever.” The tested interaction is engineered to be stored, retrieved for a chosen topic, and effective against a target model. “One interaction” describes the attacker's opportunity, not the simplicity or universality of the payload.
How The InjecMEM Attack Works
InjecMEM combines three problems that are often reviewed separately: what an agent stores, what it later retrieves, and which instructions it obeys.
1. Store a useful-looking interaction
The attacker gives the agent content related to a target topic. The content is constructed to look informative enough that the memory system will preserve it. A compromised tool could potentially return similar content in an email, customer record, support ticket, web result, or document that an agent is allowed to remember.
The attacker is not directly inserting a row into the database. The agent's own normal memory pipeline performs the write.
2. Make the memory easy to retrieve
A long-term memory can only influence a later answer if the retrieval system selects it. InjecMEM uses a topic-rich anchor that is semantically close to future questions the attacker expects.
For example, a poisoned record about an internal travel policy would be more likely to resurface during later travel-policy questions than during an unrelated coding discussion. The retrieval anchor is what gives the attack persistence with a target rather than indiscriminate influence over every answer.
3. Steer the later model call
When the poisoned record is retrieved, its adversarial command enters the model's new context alongside the user's current request and other instructions. The command tries to make the model produce an attacker-chosen behavior.
This is prompt injection with a delayed delivery path. The untrusted instruction arrives in one session, is stored by a trusted subsystem, and is replayed later under the label of memory. If the application treats retrieved memory as trusted context, provenance can be lost precisely when it matters most.
4. Turn model influence into an action
The paper focuses on steering responses. A production risk becomes more serious when the agent can also search private repositories, send messages, call Model Context Protocol tools, update tickets, download files, execute code, or contact external sites.
That final step depends on permissions. Memory poisoning plus broad tool authority is more dangerous than memory poisoning in a read-only assistant with no sensitive context. This is why prompt-injection defense cannot be reduced to detecting suspicious words.
Why Ordinary Prompt-Injection Filters Are Not Enough
The reported defense results expose a recurring security tradeoff.
An LLM judge reduced MemoryOS joint success from 35.6% to 27.3%, while PromptGuard reduced it to 26.7% and ProtectAI's detector to 29.8%. Those changes are useful, but a defense that leaves roughly one-quarter of the benchmark queries successful is not a complete boundary.
The strict perplexity defense stopped the tested retrieval path, but it also rejected most benign pages at the selected threshold. A system that forgets nearly three-quarters of legitimate material may technically resist the benchmark while failing its product purpose.
Content screening also has a structural limitation: an attacker can phrase an instruction to resemble ordinary text, and a memory can become dangerous because of how it combines with a future context. A record that looks harmless in isolation may conflict with a later system instruction, tool result, or user request.
Microsoft's independent guidance on guarding AI memory recommends controls across the full lifecycle: preserve provenance before persistence, enforce deterministic boundaries outside the model, re-evaluate content at retrieval, expose memory to users, and support review and deletion. That layered approach fits the failure demonstrated by InjecMEM better than a single classifier does.
Use The TRACE Memory Audit
Developers and security teams can turn the research into a five-part TRACE audit.
T — Trust before persistence
Decide which sources are eligible for long-term memory. User-authored preferences may deserve a different trust level from web pages, emails, connector results, tool output, uploaded documents, or another agent's message. Do not let “the model found it useful” be the only write rule.
Require explicit user confirmation for high-impact memories, especially instructions that could affect future actions, permissions, identities, destinations, financial choices, or security decisions.
R — Record provenance
Store where each memory came from, when it was created, which tool or document supplied it, whether the user approved it, and whether it contains instructions or only facts. Preserve that metadata when memories are summarized or merged.
Retrieved content should be labeled as untrusted data, not silently promoted into system-level authority. A memory created from a third-party web page should never outrank the user's current instruction simply because it is old.
A — Audit retrieval
Log which memories were selected for a response and why. Give users and administrators a way to inspect the exact source record, not merely a polished summary.
Re-scan at retrieval time because the risk depends on the new context. Consider diversity limits so one dense attacker-authored record cannot dominate the entire memory bundle. Test whether topic stuffing can force unrelated or low-quality records into future prompts.
C — Constrain actions
Keep tool permissions outside the model's discretion. Use allowlists, narrow scopes, read-only defaults, destination restrictions, secret isolation, and human confirmation for consequential actions.
The model can propose an email, database update, purchase, deployment, or file transfer. A deterministic policy layer should decide whether that action is permitted. If a poisoned memory can both supply the instruction and approve the action, the architecture has collapsed two security roles into one.
E — Expire and review
Memory should have a lifecycle. Add expiration, confidence, source-health, and last-used fields. Let users delete individual records, suspend a source, rebuild derived summaries, and see where a memory was used.
When an incident is discovered, teams need to identify every derived or copied memory. Deleting only the visible summary may leave the underlying poisoned record or a rewritten descendant available for retrieval.
What Users Can Do Today
Most users cannot inspect an agent's memory database or change its retrieval algorithm. They can still reduce exposure:
- Turn memory off for untrusted-content tasks. Researching arbitrary web pages or unknown files is a poor time to create durable personalization.
- Review saved memories regularly. Remove entries you did not intentionally teach the assistant or whose source you cannot identify.
- Separate sensitive work from broad-connectivity agents. An assistant that can read private data and browse arbitrary sites presents a larger combined risk.
- Treat tool results as untrusted. Email, documents, support tickets, search results, and connector responses can all carry instructions intended for the model.
- Require confirmation before external actions. Inspect recipients, destinations, file names, query parameters, and proposed record changes.
- Start a clean session after suspicious behavior. This is not guaranteed remediation if long-term memory persists, but it helps distinguish current-context contamination from stored memory.
- Ask the provider how memory is sourced and deleted. A useful answer should cover saved records, derived summaries, chat-history references, connector data, retention, and propagation across devices.
For a broader consumer check, compare the visible memory summary with the limits in Does ChatGPT's Memory Summary Show Everything It Remembers?. A summary can be a useful control without being a complete forensic inventory.
Where OpenVeil Fits — And Where It Does Not
OpenVeil addresses a narrower data-history problem. Its normal private chat history and custom personas are stored in the user's browser rather than maintained as a normal server-side chat-history record. OpenVeil also does not use prompts, uploads, images, audio, selected browser-local history, or AI outputs to train foundation models.
That design can reduce the persistent cloud conversation archive associated with an ordinary hosted chat account. It may be a useful fit for adults who want a hosted AI workspace without broad server-side cross-chat memory. Read what browser-local chat history means for the storage tradeoffs.
OpenVeil does not claim to be fully offline, anonymous, zero-log, or a prompt-injection firewall. Active prompts, selected local context, uploads, web searches, voice, images, and outputs may still be processed by OpenVeil and the providers necessary to perform the requested feature. Browser-local history does not make malicious content safe, block hidden instructions, secure a separate autonomous agent, or protect data intentionally placed into an active request.
OpenVeil's normal chat-history model is also not the same architecture as the autonomous memory systems tested in InjecMEM. The research should not be presented as evidence that OpenVeil was compromised or that browser-local storage alone stops memory poisoning.
The genuine connection is user choice and data minimization: if you do not need a provider-managed cross-session memory system for a task, a narrower workspace can reduce one long-lived context source. Before trusting any product label, use the evidence checklist in What To Check Before Trusting Any AI Privacy Claim.
Frequently Asked Questions
Did InjecMEM hack ChatGPT, Claude, or Gemini?
No reviewed source reports a breach of those products. The paper evaluates MemoryOS and MemGPT in controlled experiments. It raises a broader design risk that commercial providers should test, but it does not establish that a named consumer product is vulnerable to the published attack.
Can one ordinary prompt poison every future AI answer?
No. The tested interaction is deliberately optimized, tied to target topics, and must first be stored and later retrieved. In the strongest MemoryOS result, the end-to-end attack succeeded on 35.6% of the benchmark's related queries—not every query.
What does the 76.6% number mean?
It is conditional attack success after the poisoned record has already been retrieved in the MemoryOS experiment. The record was retrieved on 46.5% of relevant test queries, producing a 35.6% joint end-to-end success rate.
Does deleting the original chat remove a poisoned memory?
Not necessarily. A product may store saved memories, derived summaries, chat history, and connector content separately. Follow the provider's documented deletion controls for every relevant store, then verify that the memory no longer appears in later sessions.
Does summarizing memories stop the attack?
The paper says rewrite- or summarization-heavy pipelines may require an adapted attack; it does not prove they are safe. Summarization can remove commands, preserve them, or create a new misleading instruction depending on the pipeline. Provenance and action controls are still needed.
Can an agent-memory attack steal data?
Potentially, but model steering alone is not the whole chain. The agent would also need access to valuable data and an allowed path to reveal or transmit it. Least-privilege tools, destination controls, confirmation gates, and secret isolation can break that chain.
Does browser-local history prevent prompt injection?
No. Browser-local history describes where the ongoing transcript is stored. A hosted model can still process malicious text in the current request or selected context. Storage location and prompt-injection resistance are different security questions.
Should organizations disable AI memory entirely?
Not automatically. Memory can be useful, but its sources and authority should match the risk of the workflow. Organizations should restrict untrusted persistence, preserve provenance, audit retrieval, constrain tools, and give users effective review and deletion controls.
Bottom Line
InjecMEM demonstrates a credible new persistence path for prompt injection: one engineered interaction can be saved as agent memory, retrieved during later topic-related questions, and steer the model again. Its strongest reported MemoryOS setup achieved 35.6% end-to-end success, with a 76.6% success rate only after the poisoned record was retrieved.
The research does not prove that one random prompt can compromise every AI assistant, that a named consumer service has been breached, or that the attack transfers cleanly to closed models and different memory designs. Its value is the architectural warning.
Treat long-term memory as untrusted, provenance-bearing input. Control what can be stored, label where it came from, inspect what is retrieved, keep permissions outside the model, and make memory review and deletion real. Persistent personalization without persistent security controls is an attack surface.