AI Memory Is Becoming a Cybersecurity Attack Surface: Risks, Attacks and Defenses
By Muizz Shaikh | FourfoldAI | Updated September 24, 2026
Give an AI agent a memory, and you give it a past. Let an attacker edit that past, and you've handed them a hiding place that outlasts every chat window.
That is the uncomfortable idea running through a fast-growing body of security research. AI memory is becoming a cybersecurity attack surface, and most enterprise security programs haven't caught up. The core question is simple: if AI agents can remember information across sessions, what happens when an attacker gets them to remember something malicious?
Across work from Microsoft, Palo Alto Networks' Unit 42, Cisco, OWASP and several university teams, the answer is consistent. The bad memory keeps working after the attacker leaves. It can bias advice, leak conversations or steer an agent's actions weeks later, and input filters often never see it.
This guide explains how the risk works, what has actually been demonstrated, where enterprise exposure is highest, and which controls hold up. I've tied the claims to primary sources and flagged the places where the evidence is thin.
Key Takeaways
Memory turns a one-off prompt injection into a lasting one. OWASP lists Memory & Context Poisoning (ASI06) in its Top 10 for Agentic Applications, released in December 2025, and MITRE ATLAS tracks the technique as AML.T0080.
Live abuse already exists. Microsoft reported 50+ prompts from 31 companies across 14 industries trying to plant promotional memories in AI assistants over a 60-day window (February 2026).
Academic tests show high write success, up to 99.8% on one model in a 2026 sleeper-poisoning study, but results swing widely by model, memory design and defenses.
Risk grows with authority. Memory plus tool access plus autonomy is where a bad entry becomes a bad action.
No single control is enough. Effective AI memory security governs what gets written, how it's stored, what gets retrieved and what the agent may do with it.
What Is AI Memory, and Why Does It Change Enterprise Security?
AI memory is any information an assistant or agent stores and reuses after a conversation ends: user preferences, session summaries, retrieved documents, learned workflows and instruction files. It gives AI long-term state, which makes it useful and personal, but it also means untrusted input can be saved and treated as trusted context later.
Most people meet AI memory as a convenience. The assistant remembers that you like short answers or that you run a marketing team. Enterprises meet it as architecture. Agents built with frameworks such as LangChain and LlamaIndex, or memory layers such as Mem0, keep long-term state in vector databases, summaries and files, then pull it back through semantic search when a new task looks related. Consumer and work assistants from OpenAI, Anthropic and Google offer persistent memory too.
Two design choices matter for security. Memory is writable at runtime, often by the model itself. And whatever comes back from memory tends to be trusted more than fresh input, because it looks like the user's own history.
The table below shows the memory layers a security team should map.
Memory Layer | What It Holds | Who Writes It | Why Attackers Care |
Context window | Current conversation and tool outputs | The active session | Short-lived, but it's where injection starts |
Session summaries | Condensed history from context window management | The model or a memory manager | Untrusted text can be summarized into "trusted" notes |
User-profile memory | Preferences, facts, standing rules | Model tool calls or managers such as Mem0 | Persists across sessions and devices |
Vector database (RAG store) | Embeddings of documents and past experiences | Ingestion pipelines and agents | Semantic search surfaces poisoned entries when relevant |
Procedural memory | Reusable skills and workflows | The agent, from completed tasks | A poisoned step becomes a repeatable habit |
Instruction and config files | Project notes, hooks, agent rules | Users, scripts and sometimes the agent | Often loaded with high authority |
Why AI Memory Is Becoming a Cybersecurity Attack Surface
Because memory turns a one-time prompt injection into a lasting one. An attacker only has to get bad content written once. After that, the agent retrieves it in later sessions, often treats it as trusted, and may act on it long after the original malicious page, email or document is gone.
Three properties make the AI memory attack surface different from an ordinary chat exploit.
Persistence. The entry survives session resets, restarts and sometimes new devices. In 2024, researcher Johann Rehberger showed that instructions planted in ChatGPT's memory kept working across new conversations, and OpenAI's own documentation notes that deleting a chat doesn't delete its memories.
Inherited trust. Agents tend to accept their stored context as reliable. Cisco's researchers found that, in the Claude Code version they tested, memory files were loaded into the system prompt and treated as if the user had written them.
Delayed activation. The payload can sit dormant until a related question arrives. That decoupling in time is why a clean-looking session can still be a compromised one.
Underneath all three sits a weakness that isn't new. Language models struggle to tell instructions from data, and they struggle to track where a piece of information came from. Prompt injection earned its name from SQL injection for a reason: both mix trusted code with untrusted input. Memory simply adds a database to the mix, so an injection can be saved instead of merely obeyed.
What Is AI Memory Poisoning?
AI memory poisoning is the deliberate corruption of what an agent stores and later retrieves. An attacker plants false facts, biased preferences or hidden instructions in long-term memory, a knowledge base or a memory file, so the agent repeats or obeys them in future sessions without the attacker present.
Standards bodies now treat it as its own category. OWASP added ASI06 because persistent-state attacks don't fit the threat model of a stateless chatbot. Idan Habler, an OWASP ASI06 co-lead and Cisco researcher, put the shift plainly: memory should be treated as part of the attack surface.
MITRE ATLAS files the technique as AI Agent Context Poisoning (AML.T0080), with a Memory sub-technique (AML.T0080.000) under the Persistence tactic. That placement matters. In ATLAS terms, poisoned memory is a foothold, not a one-time trick.
It also slips past familiar defenses. A 2026 study of memory poisoning in LLM agents found that existing prompt-injection defenses fail to cover it, largely because the malicious write can look like an ordinary, helpful save.
How Does AI Memory Poisoning Work?
An attacker plants content the agent will read, such as a webpage, document or email. The agent's memory mechanism saves something from it. Later, semantic search retrieves that entry for a related task, and the agent acts on it as though the user or a trusted system had said it.
Researchers describe the lifecycle in four stages.
1. Delivery. The payload arrives through indirect prompt injection: hidden instructions in external content the agent processes. It can also arrive through a poisoned knowledge base or, in one research design, through ordinary queries alone.
2. Write. The agent stores something. A 2026 systematic study identified four write channels: an explicit "remember this" instruction, a system prompt that tells the agent to save "relevant" details, compaction when a long context gets summarized, and experience-to-procedure writes when the agent turns finished work into reusable skills. Every one of those is a possible malicious write operation.
3. Dormancy and retrieval. The entry waits. Retrieval depends on semantic closeness, so the trigger is a topic, not a password.
4. Action. The retrieved memory shapes the answer or the tool call. A memory saying the user always wants exported files uploaded to a particular address is a delayed exfiltration path, an example the sleeper-poisoning researchers use.
That third stage deserves attention. In the sleeper-poisoning study, poisoned entries were retrieved for related queries 90–98% of the time but for unrelated queries only 3–18%. The attack behaves like a landmine: mostly quiet, dangerous on contact.
What Is Sleeper Memory Poisoning?
Sleeper memory poisoning is a delayed attack where an adversary manipulates external content, such as a document, webpage or repository, so an assistant stores a fabricated memory about the user. The memory stays dormant, then re-emerges across later conversations, even though the original malicious content is no longer in view.
The 2026 paper "Hidden in Memory" tested six models with a reusable poisoning template. Poisoned memories were written up to 99.8% of the time on GPT-5.5 and 95% on Kimi-K2.6 in the tool-based setting, and once retrieved, they triggered attacker-intended agent actions in 60–89% of evaluations. Claude Sonnet 4.6 was the most resistant model in the comparison, yet it still used poisoned memory in 60% of relevant agentic tests after retrieval. The authors also found injection success depended heavily on the memory harness, not only the model. Design choices matter as much as model choice.
What Is a Trust Laundering Chain?
A trust laundering chain is how untrusted content acquires authority inside an agent's memory. Research describes three routes: the agent's own summarization rewrites untrusted text into a neutral-sounding note, a trusted tool echoes attacker content, or repeated untrusted items create fake corroboration that crosses a trust threshold.
This is why scanning inputs alone falls short. By the time a summary lands in memory, it no longer looks like the hostile document it came from. A June 2026 preprint proposes binding a memory item's authority to its origin, so a summary inherits the lowest trust level of its sources. That idea is worth borrowing even if you never adopt the full formal model.
Attack Vectors at a Glance
Attack Vector | Target Layer | Persistence Horizon | Primary Mitigation |
Indirect prompt injection into user memory | User-profile memory | Until the entry is found and deleted | Block memory writes from untrusted content; user-visible memory review |
Sleeper memory poisoning | Profile memory and memory managers | Dormant until a related query | Write Authorization Policies, provenance labels, ingestion-time detection |
Query-only memory injection | Shared experience memory | Persists as retrievable records | Per-user isolation, retrieval validation |
Knowledge base poisoning | Vector database and RAG corpus | Until documents are removed or re-indexed | Source allowlists, ingestion review, corpus integrity checks |
Trust laundering | Summaries and tool outputs | Persistent and hard to trace | Taint tracking; inherit the lowest source trust |
Instruction-file poisoning | Memory files, hooks, configuration | Across sessions, projects and reboots | Keep learned memory out of high-authority prompts; file integrity monitoring |
Cross-tenant memory leakage | Shared stores in multi-tenant systems | Ongoing while misconfigured | Siloed stores or platform-enforced tenant filters |
What Real Incidents and Research Show About AI Memory Attacks
The evidence sits at three levels: named vulnerabilities in ChatGPT, Gemini and Claude Code, live promotional abuse Microsoft found across 31 companies, and academic tests reporting write success above 95% in some setups. Results vary by model, memory design and defenses, so treat the numbers as risk signals, not forecasts.
Here's the timeline as it stands.
September 2024: SpAIware in ChatGPT. Rehberger showed that a prompt injection from an untrusted website could write instructions into ChatGPT's long-term memory, causing continuous exfiltration of what the user typed, including in future chats. OpenAI closed the exfiltration route in ChatGPT for macOS version 1.2024.247. Rehberger noted afterward that an untrusted document could still invoke the memory tool to store arbitrary memories; only the data-leak path had been fixed.
February 2025: Gemini and delayed tool invocation. Rehberger got around Gemini's guardrails by telling it to save a memory only after the user said a trigger word they were likely to say anyway. Google rated the risk low, arguing it needed a tricked user and that memory has limited impact on a session. Rehberger pointed out that Gemini does tell users when a new memory is added, which lets them catch and remove it.
October 2025: Unit 42 and Amazon Bedrock Agents. Palo Alto Networks' Unit 42 showed how a malicious webpage could steer an agent's session summarization so injected instructions were stored, persisted across sessions and were folded into later orchestration prompts. Memory was scoped per user, so the compromise stayed with the targeted user.
February 2026: AI Recommendation Poisoning. Microsoft's Defender Security Research Team found companies hiding instructions in "Summarize with AI" buttons that tried to plant persistence commands in an assistant's memory through URL prompt parameters. The team counted over 50 unique prompts from 31 companies in 14 industries. The prompts asked assistants to treat a company as a trusted source or recommend it first. The actors were legitimate businesses, not criminal groups, and the topics at risk included health, finance and security.
April 2026: MemoryTrap in Claude Code. Cisco researchers described a chain in which a routine developer workflow, cloning a repository and approving a dependency install, let a payload reach persistent memory files and global hook configuration. The result was manipulated guidance, including insecure advice on storing API keys. After disclosure, Anthropic shipped a change in Claude Code v2.1.50 that removes user memories from the system prompt, which narrows the high-authority path Cisco used. Cisco also reported Anthropic's position: the user on the machine is a fully trusted principal, the attack requires interacting with an untrusted repository, and users are responsible for vetting dependencies.
May 2026: The sleeper-poisoning study. Covered above. It also confirmed the behavior on production web interfaces, not only in lab harnesses.
The academic baseline. PoisonedRAG, presented at USENIX Security 2025, reported a 90% attack success rate after injecting just five malicious texts per target question into a knowledge base of millions of texts. The MINJA study reported 98.2% average success injecting malicious records using nothing but ordinary queries. Then came a useful reality check: a January 2026 follow-up in electronic health record agents found that realistic conditions, with legitimate memories already in the store, dramatically reduced attack effectiveness.
Most public cases so far are researcher demonstrations. Microsoft's finding is the clearest evidence of live use in the wild among the sources reviewed here. That's a reason to prepare, not a reason to panic.
Where Does AI Memory Create the Biggest Enterprise Risk?
Risk concentrates where memory meets authority: agents that can send email, change code, move money or call internal APIs. A poisoned preference in a chat assistant skews advice. The same entry in an agent with tool access can trigger actions, which is why autonomy multiplies memory risk.
Autonomy Multiplies the Blast Radius
The more an autonomous AI workforce can do without a human in the loop, the more a single remembered instruction is worth to an attacker. The same applies to agentic AI and computer-use agents that click, type and submit on a person's behalf. Poisoned memory can act like privilege escalation by proxy: a fabricated "standing rule" that quietly widens what the agent thinks it may do.
The broader field is moving the same direction. OWASP released its 2026 Top 10 for LLM Applications on September 2, 2026, and Zenity's CTO noted that Excessive Agency now ranks third. The lesson for memory is direct. Contain what a fooled agent can reach, and assume it will sometimes be fooled.
The Model Context Protocol (MCP) matters here too. MCP gives agents a standard way to reach tools and data, which also means tool responses become a steady stream of content that can end up in memory. Treat every MCP tool output as an untrusted write source unless you've decided otherwise.
Cross-Tenant Memory Leakage
In SaaS products where many customers share one agent platform, memory has to stay per customer. AWS describes two patterns for vector stores: a silo pattern with dedicated databases per tenant, recommended for regulated industries, and a pool pattern with shared databases separated by metadata filters and namespaces. In the pool model, retrieval should have tenant filters injected automatically rather than left to the model to construct. Otherwise, a prompt injection that talks the model out of its filter becomes a cross-tenant memory leakage event. This one is an architectural risk more than a documented attack class, so test for it before assuming you're safe.
Vector Databases and Embeddings
Embeddings can feel abstract, but they are derived from real documents and conversations. Treat embeddings of personal or confidential data as sensitive data, apply access controls to the vector database as you would to a production SQL database, and remember that PoisonedRAG showed corrupted retrieval corpora can steer answers. OWASP's 2025 LLM list already catalogued Vector and Embedding Weaknesses as LLM08.
Shadow AI and Unmanaged Memory
Employees using consumer assistants with memory switched on are building state you don't govern. That's one more face of Shadow AI risks: project context, client names and internal preferences retained in a vendor's store, plus no visibility if someone gets a poisoned entry in. Microsoft's own advice to individuals is to review stored memories periodically, and Copilot exposes a Personalization setting for exactly that.
How Do You Secure AI Memory? A Four-Point Control Model
Secure AI memory by controlling four points: what gets written, how it's stored, what gets retrieved, and what the agent may do with it. Add provenance labels, write authorization, tenant isolation, expiry and human approval for high-impact actions. No single control is enough, so layer them.
I use a simple lens at FourfoldAI for this: Write, Store, Retrieve, Act. It isn't a formal standard, just an organizing model that maps onto the research. Good AI memory security follows the memory through its whole life.
1. Control the Write Path
Researchers studying memory poisoning argue defenses should move from the input path to the write path. In practice that means Write Authorization Policies: written rules for which sources may create memory and under what conditions.
Deny memory writes triggered by external content, such as web pages, emails and tool outputs, unless a person approves.
Require confirmation for security-relevant memories: permissions, payment details, URLs, "always do X" rules and trusted-source claims.
Replace vague retention rules like "save anything important" with narrow ones.
Hold new entries in memory quarantine until they pass checks. Forcepoint researchers suggest scoring each memory object and then rejecting, quarantining, flagging or marking high-risk items untrusted.
Prompt hardening helps, but treat it as a speed bump. In the sleeper study, optimized hardening drove injection to near zero for Claude Sonnet 4.6 and Gemini 3.1, yet an adaptive attacker lifted injection on Kimi-K2.6 from 6.2% to 64.6% in one test. Trust scoring has a double edge too. In a health-record agent study, one configuration rejected every candidate memory, benign ones included, while another accepted 54 poisoned entries with perfect trust scores.
2. Harden How Memory Is Stored
Attach memory provenance to every entry: source, timestamp, writing identity and trust level. Governance guidance mapped to OWASP ASI06 asks for provenance metadata on every memory write.
Make summaries inherit the lowest trust level of their inputs, which breaks the trust laundering chain.
Set Time-to-Live (TTL) values and memory decay so entries expire unless renewed. Deliberate forgetting windows limit how long a sleeper can sleep.
Separate operator-authored instructions from learned memory. Cisco's case shows what happens when learned memory sits in the highest-authority slot.
Isolate by tenant, user and task domain. Memory segmentation stops one poisoned context from contaminating unrelated work.
3. Govern Retrieval
Present retrieved memory to the model as untrusted context, labeled by source, not as system-level instruction.
Enforce tenant and permission filters in the platform layer before search runs.
Watch relevance patterns. Because poisoned entries activate on related topics, an unexplained memory that keeps surfacing on sensitive tasks deserves a look.
4. Limit What Memory Can Trigger
This is where zero-trust AI earns its name. Memory can inform an action, but it should never authorize one.
Give agents least-privilege tools and allowlisted destinations, so a poisoned "upload to this address" rule hits a wall.
Require human approval for consequential actions, and make sure the approval screen doesn't rely on the agent's own memory to explain itself.
Keep audit logging for memory writes, retrievals and the actions they influenced, so investigators can trace a bad decision back to the entry that caused it.
Build a purge-and-rollback playbook. If you can't quickly quarantine a suspect memory store, you can't respond.
The Control Model in One View
Control Point | Core Controls | Failure It Prevents | What the Evidence Says |
Write | Write Authorization Policies, confirmation, quarantine | Hostile content becoming memory | Defenses that only inspect inputs miss write-path attacks |
Store | Provenance, TTL, memory decay, isolation | Long-lived and laundered entries | Provenance and forgetting windows are core governance asks |
Retrieve | Untrusted labeling, pre-filtered tenancy | Poisoned recall and cross-tenant leakage | Activation is strongly topic-dependent |
Act | Least privilege, human approval, audit logging | Memory-driven exfiltration or sabotage | Agent actions followed poisoned recall in 60–89% of successful retrievals |
Where Controls Fall Short
Be honest with your board about limits. Prompt-level defenses were brittle against adaptive attacks in the sleeper study. Detection looked promising: lightweight probes on model internals and LLM document scanners scored well, though probes need access to a model's internals, which API-only teams don't have. Model choice matters, but memory harness design matters just as much. And realistic memory stores may blunt some attacks that look devastating in clean lab conditions. Layered controls beat any silver bullet.
What Should an AI Memory Governance Program Include?
It should include a memory inventory, written write-and-retention policies, provenance and audit logging, regular red-team tests, and an incident playbook for purging poisoned entries. Map it to OWASP ASI06, MITRE ATLAS and existing frameworks such as NIST AI RMF so audits have something concrete to check.
Inventory first. You can't govern memory you haven't found. Fold memory stores, vector indexes and instruction files into your LLMOps and AI systems in production inventory, including agents built by business teams.
Test on purpose. Run sleeper-style scenarios against your own agents: plant a benign marker through a document, wait, then see whether it resurfaces on a related task. Periodic evaluation against ground truth belongs in the release cycle.
Detect with telemetry. Modern AI in cybersecurity tooling can flag anomalies in memory writes, but you can also start simple. Microsoft published hunting ideas for URLs that point to AI assistant domains and carry keywords such as "remember," "trusted source" and "in future conversations."
Map to frameworks. Governance guidance ties ASI06 to NIST AI RMF (MAP 4, MEASURE 2.7 and 2.10), ISO/IEC 42001 Annex A controls, and EU AI Act Articles 10 and 15. Add MITRE ATLAS technique IDs to your threat models, and use OWASP's agent-focused guidance to structure reviews.
Ask vendors sharper questions. If you're comparing agent platforms, memory frameworks or observability tools, start with these:
Which sources can write to memory, and can we disable writes from external content?
Is provenance stored per entry, and can we query it?
Can we view, export, edit and bulk-delete memories, including derived summaries and embeddings?
How is tenant isolation enforced: separate stores or metadata filters?
Is learned memory ever placed in system-level instructions?
What audit logs exist for writes, reads and downstream tool calls?
How does the vendor test against sleeper and query-only injection?
What happens to memory when an employee leaves or a tenant is offboarded?
The Bottom Line: Treat Memory as Production State
AI memory is becoming a cybersecurity attack surface because the features that make agents feel intelligent, remembering, summarizing and learning from experience, are the same ones attackers can abuse. Nothing here argues for abandoning memory. It argues for treating it like any other production state: authenticated writes, labeled sources, expiry dates, isolation, logging and a rollback plan.
The good news is that the defensive playbook is emerging fast. OWASP, MITRE and major vendors now name the problem, and researchers are publishing concrete controls, not just alarms. The teams that move early will get to choose their architecture. Everyone else will inherit whatever their agents already remembered.
Start small. Inventory your memory stores this quarter, pick one high-authority agent, lock down its write path, and test whether a planted marker survives. That single exercise will teach you more than another policy document.
Frequently Asked Questions About AI Memory Security
What is AI memory poisoning?
AI memory poisoning is the deliberate corruption of what an AI agent stores and later retrieves. Attackers plant false facts, biased preferences or hidden instructions in long-term memory, a knowledge base or a memory file, so the agent repeats or obeys them in future sessions without the attacker being present.
How is memory poisoning different from prompt injection?
Prompt injection usually affects only the current session. Memory poisoning saves the malicious content so it can influence later sessions, sometimes weeks later. OWASP treats it separately as ASI06 for that reason, and research suggests standard prompt-injection defenses often miss the write path that memory attacks exploit.
What is sleeper memory poisoning?
Sleeper memory poisoning is a delayed attack where external content, such as a document or webpage, causes an assistant to store a fabricated memory about the user. The memory stays dormant and re-emerges when a related topic comes up, even after the original malicious content is gone.
Can ChatGPT, Claude or Gemini memory be poisoned?
Researchers have demonstrated memory attacks against ChatGPT in 2024 and Gemini in 2025, and a 2026 study reported inducing memory writes in ChatGPT, Claude and Gemini-family systems with varying success. Vendors have shipped mitigations, but behavior changes often, so check current settings and controls.
What is OWASP ASI06?
ASI06 is Memory & Context Poisoning, the sixth entry in the OWASP Top 10 for Agentic Applications released in December 2025. It covers attacks where persistent memory, retrieval stores or context are shaped to mislead an agent's future reasoning and actions across sessions.
What is MITRE ATLAS AML.T0080?
AML.T0080, AI Agent Context Poisoning, is the MITRE ATLAS technique for manipulating the context an AI agent uses so its behavior changes persistently. Its Memory sub-technique, AML.T0080.000, covers changes that carry into future chat sessions, and both fall under the Persistence tactic.
How can I tell whether an AI agent's memory has been poisoned?
Review stored entries for embedded instructions, unfamiliar URLs, "always" or "never" rules and claims that a company or site is trusted. Correlate memory writes with sessions that processed external content, and use test questions to spot behavior that shifted without a clear reason.
How do you protect a vector database used as AI memory?
Treat it like a production database. Enforce tenant isolation at the storage or platform layer, restrict who and what can write, log ingestion, verify document sources, and re-check retrieved content before it reaches the model. Embeddings of personal data should be handled as sensitive data.
Should companies turn AI memory off?
Not necessarily. Disabling memory for agents with access to sensitive systems or high-impact tools can be reasonable while controls mature. For lower-risk assistants, constrain writes, add expiry and review memories regularly. The right answer depends on what the agent can do, not on the feature itself.
How often should AI memory be reviewed or expired?
There is no universal number. Set retention by risk: short TTLs for high-authority agents and longer ones for low-risk personalization. Review high-impact memories on a fixed cadence, and purge on triggers such as offboarding, a suspected injection or a major model or tool change.
References and Citations
This article is backed by authoritative sources and research, including OWASP, MITRE, Microsoft Security, Palo Alto Networks Unit 42, Cisco, peer-reviewed conference papers and arXiv preprints. Preprints have not necessarily completed peer review, and figures reflect specific test conditions.
OWASP GenAI Security Project. "OWASP Top 10 for Agentic Applications." December 9, 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/ https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
Habler, I. (OWASP / Cisco). "Memory Is a Feature. It Is Also an Attack Surface." May 13, 2026. https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/ https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/
OWASP GenAI Security Project. "Unveils 2026 Top 10 for LLM Applications, New Agent Control Standard." September 2026. https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/ https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
OWASP GenAI Security Project. "OWASP Top 10 for LLM Applications." https://genai.owasp.org/llm-top-10/ https://genai.owasp.org/llm-top-10/
MITRE D3FEND. "AI Agent Context Poisoning (AML.T0080)." https://d3fend.mitre.org/offensive-technique/attack/AML.T0080 https://d3fend.mitre.org/offensive-technique/attack/AML.T0080
MITRE D3FEND. "Memory (AML.T0080.000)." https://d3fend.mitre.org/offensive-technique/attack/AML.T0080.000 https://d3fend.mitre.org/offensive-technique/attack/AML.T0080.000
Microsoft Security Blog. "Manipulating AI memory for profit: The rise of AI Recommendation Poisoning." February 10, 2026. https://www.microsoft.com/en-us/security/blog/2026/02/10/ai-recommendation-poisoning/ https://www.microsoft.com/en-us/security/blog/2026/02/10/ai-recommendation-poisoning/
Help Net Security. "That 'summarize with AI' button might be manipulating you." February 2026. https://www.helpnetsecurity.com/2026/02/11/ai-recommendation-memory-poisoning-attacks/ https://www.helpnetsecurity.com/2026/02/11/ai-recommendation-memory-poisoning-attacks/
The Hacker News. "Microsoft Finds 'Summarize with AI' Prompts Manipulating Chatbot Recommendations." February 2026. https://thehackernews.com/2026/02/microsoft-finds-summarize-with-ai.html https://thehackernews.com/2026/02/microsoft-finds-summarize-with-ai.html
Search Engine Journal. "Microsoft: 'Summarize With AI' Buttons Used To Poison AI Recommendations." February 2026. https://www.searchenginejournal.com/microsoft-summarize-with-ai-buttons-used-to-poison-ai-recommendations/567941/ https://www.searchenginejournal.com/microsoft-summarize-with-ai-buttons-used-to-poison-ai-recommendations/567941/
Cisco Blogs (Habler and Chang). "Identifying and remediating a persistent memory compromise in Claude Code." April 1, 2026. https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code https://blogs.cisco.com/ai/identifying-and-remediating-a-persistent-memory-compromise-in-claude-code
Palo Alto Networks Unit 42. "When AI Remembers Too Much: Persistent Behaviors in Agents' Memory." October 9, 2025. https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/ https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/
Pulipaka et al. "Hidden in Memory: Sleeper Memory Poisoning in LLM Agents." arXiv:2605.15338, May 2026. https://arxiv.org/abs/2605.15338 https://arxiv.org/abs/2605.15338
Dash et al. "From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents." arXiv:2606.04329, June 2026. https://arxiv.org/abs/2606.04329 https://arxiv.org/abs/2606.04329
"Securing LLM-Agent Long-Term Memory Against Poisoning: Non-Malleable, Origin-Bound Authority with Machine-Checked Guarantees." arXiv:2606.24322, June 2026. https://arxiv.org/pdf/2606.24322 https://arxiv.org/pdf/2606.24322
Dong et al. "Memory Injection Attacks on LLM Agents via Query-Only Interaction (MINJA)." arXiv:2503.03704. https://arxiv.org/abs/2503.03704 https://arxiv.org/abs/2503.03704
"Memory Poisoning Attack and Defense on Memory Based LLM-Agents." arXiv:2601.05504, January 2026. https://arxiv.org/abs/2601.05504 https://arxiv.org/abs/2601.05504
Zou, Geng, Wang and Jia. "PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models." USENIX Security 2025. https://www.usenix.org/conference/usenixsecurity25/presentation/zou-poisonedrag https://www.usenix.org/conference/usenixsecurity25/presentation/zou-poisonedrag
Rehberger, J. "Spyware Injection Into Your ChatGPT's Long-Term Memory (SpAIware)." Embrace The Red, September 2024. https://embracethered.com/blog/posts/2024/chatgpt-macos-app-persistent-data-exfiltration/ https://embracethered.com/blog/posts/2024/chatgpt-macos-app-persistent-data-exfiltration/
The Hacker News. "ChatGPT macOS Flaw Could've Enabled Long-Term Spyware via Memory Function." September 2024. https://thehackernews.com/2024/09/chatgpt-macos-flaw-couldve-enabled-long.html https://thehackernews.com/2024/09/chatgpt-macos-flaw-couldve-enabled-long.html
Futurism. "You Can Insert False Memories Into ChatGPT, Researcher Finds." September 2024. https://futurism.com/the-byte/insert-false-memory-chatgpt https://futurism.com/the-byte/insert-false-memory-chatgpt
Ars Technica. "New hack uses prompt injection to corrupt Gemini's long-term memory." February 2025. https://arstechnica.com/security/2025/02/new-hack-uses-prompt-injection-to-corrupt-geminis-long-term-memory/ https://arstechnica.com/security/2025/02/new-hack-uses-prompt-injection-to-corrupt-geminis-long-term-memory/
Modulos. "OWASP Top 10 for Agentic Applications (2026) — Governance Guide." https://docs.modulos.ai/frameworks/owasp-top-10-agentic https://docs.modulos.ai/frameworks/owasp-top-10-agentic
Amazon Web Services. "Building multi-tenant agents with Amazon Bedrock AgentCore." May 2026. https://aws.amazon.com/blogs/machine-learning/building-multi-tenant-agents-with-amazon-bedrock-agentcore/ https://aws.amazon.com/blogs/machine-learning/building-multi-tenant-agents-with-amazon-bedrock-agentcore/
Amazon Web Services. "Securing Amazon Bedrock Agents: A guide to safeguarding against indirect prompt injections." May 2025. https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-agents-a-guide-to-safeguarding-against-indirect-prompt-injections/ https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-agents-a-guide-to-safeguarding-against-indirect-prompt-injections/
ITPro. "Trust your AI agents? New research shows 'memory poisoning' can dupe them into 'remembering' fake information." August 2026. https://www.itpro.com/security/trust-your-ai-agents-new-research-shows-memory-poisoning-can-dupe-them-into-remembering-fake-information-and-its-a-huge-security-risk https://www.itpro.com/security/trust-your-ai-agents-new-research-shows-memory-poisoning-can-dupe-them-into-remembering-fake-information-and-its-a-huge-security-risk
Disclaimer
This article is for general informational and educational purposes only and is not security, legal or compliance advice. Research findings reflect specific test conditions and may not match your environment. Vendor features and mitigations change quickly, so verify current behavior with vendors and qualified professionals before making decisions. For the full terms, read our disclaimer: https://www.fourfoldai.com/disclaimer
Explore More on FourfoldAI
Building or buying agents with memory? Keep learning with FourfoldAI's practical guides on agentic AI, MCP vs APIs, persistent AI agents and how to build an AI agent. Browse everything at fourfoldai.com and subscribe to The Daily Pulse for new AI security explainers.
About the Author
Muizz Shaikh is an AI enthusiast and digital technology professional at FourfoldAI. He is passionate about exploring AI tools, industry trends, and practical applications of emerging technologies. Through FourfoldAI, Muizz contributes to simplifying artificial intelligence for businesses and learners. Connect with him on LinkedIn: linkedin.com/in/muizz-shaikh-45b449403/
© 2026 FourfoldAI. All rights reserved.
Comments