AI Agent Long-Term Memory Is the New Attack Surface: What MemGhost and GhostWriter Mean for Enterprises

"Our AI assistant answered fine last week. This week it keeps giving people the wrong contact. Nobody changed any settings."

If you have already deployed a memory-enabled AI assistant internally, this kind of "something is off but I can't point at it" situation may sound familiar. We used to blame model updates or prompt drift. But two research papers published in July 2026 raise another possibility: something was written into the agent's long-term memory that should not be there.

This article is not about panic. Both studies were conducted in sealed test environments, and both proposed defenses. For IT and security leaders, the useful translation is one sentence: if your AI Agent "remembers things," that memory is an asset that needs governance — not a harmless cache.

If you are not yet familiar with the broader AI security picture, start with AI Security Complete Analysis: AI-Driven Threats and Defense Strategies.

First, What Is "Long-Term Memory" in an AI Agent?

An ordinary chatbot's memory lives only inside a single conversation. Close the window and it remembers nothing.

But once AI moves from chatbot to Agent — handling your mail, organizing documents, managing schedules, writing code — no memory means no usefulness. So modern agent frameworks add persistent memory: user preferences, project background, frequent contacts, and past decisions get written to files or a vector store and loaded automatically at the start of each session.

Two implementations are common:

• Plain-text memory files: files such as AGENTS.md or MEMORY.md that get read into context every session
• Vector memory backends: memory chunked into embeddings and retrieved by semantic similarity when needed

Both are convenient. The problem is that in both cases, writes usually have no gatekeeper. The agent decides "this is worth remembering" and writes it — and the source of "this" might be an email from a stranger.

To understand how different frameworks handle memory and state, see AI Agent Frameworks Deep Dive.

Research One: MemGhost — One Email, and the False Memory Stays

The Team and the Threat Model

MemGhost is an AI agent attack framework from researchers at Nanyang Technological University (Singapore), the Agency for Science, Technology and Research (A*STAR), and Johns Hopkins University, published on arXiv in July 2026 under the title "When Claws Remember but Do Not Tell."

The threat model is deliberately restrictive, which is exactly why enterprises should care:

1. The attacker can send only one crafted email
2. The attacker cannot directly modify the agent's memory
3. The attacker cannot observe the outcome after delivery, so cannot iterate based on feedback

In other words, this is not "after breaching the system, do whatever you want." It is "throw one letter in from the outside." A much lower bar.

The researchers call this class of attack stealth memory injection. The emphasis is on stealth: as the agent reads the email and writes false information into persistent state, the reply in that session does not reveal that memory was modified. The user just sees a message that was processed normally.

The Definition of Success Is Stricter Than You Think

MemGhost counts an attack as end-to-end successful only when all three conditions hold simultaneously:

1. The false information is actually written into memory
2. The reply in that session does not disclose the injection
3. Behavior in later sessions is genuinely affected

All three, or it does not count. So the numbers below are not "had a chance to get written in" — they are "the whole chain completed."

Success Rates

Agent environment tested	End-to-end success rate
OpenClaw + GPT-5.4 (background execution)	87.5%
Claude Code SDK + Sonnet 4.6 (same execution mode)	71.4%

The study also tested NanoClaw, Hermes Agent, and the Mem0 vector memory backend, showing that MemGhost-generated payloads transfer across different agent architectures and memory mechanisms — meaning this is not one product's implementation flaw.

How They Tested: WhisperBench

The team built a benchmark called WhisperBench using real IMAP/SMTP mail flows and actual mail agent tooling, not a simulated environment. It contains 108 cases — 52 for training and 56 held out for testing — covering both factual and preference poisoning, mapped to five risk categories: health and safety, financial loss, information integrity, security, and operational disruption.

For enterprises, "financial loss" and "operational disruption" deserve particular attention, since those are precisely the business scenarios agents are most often assigned to.

Why Existing Defenses Struggle

The researchers evaluated three different defensive approaches:

• DataSentinel: detection of malicious instructions in external content
• Meta-SecAlign: model-level built-in alignment defenses
• AgentDoG: auditing of agent execution traces

MemGhost was still able to evade some detections or complete memory injection in their experiments. The team's diagnosis is worth copying down verbatim: existing defenses largely focus on preventing external instructions from immediately controlling the agent, and do much less to constrain how external content gets converted into long-term memory usable across sessions.

Defenders are watching the present. Attackers are playing for later.

What the Researchers Recommend

The MemGhost paper proposes:

• Agents should record the provenance of each memory (did this come from the user, or from an external email?)
• Require user confirmation before writing sensitive memories
• Separate external content from trusted memory
• Retain an audit trail of memory modifications

Research Two: GhostWriter — ~98% Injection, but Activation Rate Is the Real Story

This is a completely separate piece of research with no connection to MemGhost, and the numbers are not interchangeable.

GhostWriter comes from researchers at New Mexico State University in the United States. It also targets long-term memory in AI assistants, but decomposes the problem differently.

A Two-Phase Attack

GhostWriter splits memory contamination into two phases:

1. Injection phase: false or malicious information is written into the AI's long-term memory store
2. Activation phase: when the AI retrieves that memory during a later task, the attack behavior triggers automatically

Read the Two Numbers Separately

• Memory injection success rate: about 98% — getting something into the memory store almost always works
• Average activation rate of the planted memory: about 60% — measured across state-of-the-art AI agent systems

The gap between the two numbers carries a practical message: "it can be written in" does not mean "it will definitely be used." Defenders have room to intervene at both stages — you can block on write, and you can block on retrieval.

The research notes that affected systems include AI assistants that handle email, documents, scheduling, and code, with potential consequences such as mis-sorting bank emails, forwarding sensitive messages, and remembering incorrect contacts, deadlines, or preferences.

The Proposed Defense

The GhostWriter team proposes a defense mechanism called Agentic Memory Sentry (AM-Sentry), which reduces attack success through memory screening and stricter management policy.

Conceptually it points the same direction as the MemGhost recommendations: put a checkpoint at both the entrance and the exit of memory.

How Memory Poisoning Differs From Ordinary Prompt Injection

This is the single most important distinction in this article, because many enterprise AI policies already say "guard against prompt injection" and assume that covers it.

Dimension	Ordinary (indirect) prompt injection	Memory poisoning
When it fires	Immediately, in the session that reads the malicious content	Later — possibly a different session days afterward
Lifespan	One session; ends when the content is gone	Persists until someone actively clears it
Repeat triggering	Requires repeated delivery	Written once, potentially effective every time it loads
User visibility	Anomalous behavior happens on the spot, easier to notice	The immediate reply looks normal; anomalies appear "later," hard to attribute
Investigation difficulty	Traceable to that specific input	Requires finding which email, on which day, wrote it in
Primary defense focus	Input filtering, instruction isolation	Write gating, source tagging, memory auditing

The hardest part is attribution. When ordinary prompt injection goes wrong, you at least know the document you just processed was the problem. When memory poisoning goes wrong, the agent starts behaving oddly weeks later, and the original email is buried deep in a mailbox. Without a memory write log, that investigation goes nowhere.

This is why "retain an audit trail of memory modifications" is not optional — it is a prerequisite.

Connectors: How External Service Integration Expands the Risk Radius

Memory poisoning is dangerous because agents do not just remember — they act. And the ability to act comes from connectors: the integrations that link an agent to mail, cloud storage, meeting systems, and ticketing.

Security firm PromptArmor published research on the third-party connector ecosystems of ChatGPT and Claude (reported by The Register in July 2026). Several findings are directly relevant to enterprise procurement and security review:

1. Connectors Change Faster Than Your Review Cycle

• Over six weeks (mid-May to end-June), 37% of connectors changed substantially — 931 out of 2,517
• 1,686 new tools were added to existing connectors
• 1,127 tool descriptions were rewritten, and tool descriptions influence when the AI decides to call them

The Dropbox connector illustrates the trend: it went from three write-capable tools to ten, and from zero potentially destructive tools to four.

This is a structural challenge for governance: the connector you approved in Q1 is not the same thing in Q2, and nobody necessarily tells you.

2. Your Data May Take an Extra Hop

The research found that roughly 40% of Claude connectors (189 of 487) call additional external AI services. That creates untracked data pathways, where sensitive information may be processed by third-party AI subprocessors without the enterprise knowing.

The reported example: when using the Zoom connector for a sensitive query, Zoom AI may send that data to any of its ten AI subprocessors.

For anyone who has run a data inventory or an ISO 27001 program, the implication is blunt: your data flow diagram is probably missing a layer.

3. The Lethal Trifecta

PromptArmor invokes the widely discussed "lethal trifecta" — risk rises sharply when a single agent simultaneously has:

1. Access to private data
2. Exposure to untrusted content
3. A path for external communication

Most enterprise AI assistants satisfy all three out of the box. Memory poisoning makes the second item's impact permanent.

---

Feeling like there is too much to inventory? A security assessment does not have to be exhaustive on day one. Starting with "which agents have memory, and which are connected to external services" already delivers real value. Schedule a security assessment and we will help you set priorities.

---

What to Evaluate Before Deploying AI Agents

The following six points translate the research above into actionable steps. None of them require buying a new product to start.

1. Ask First: Does This Agent Have Long-Term Memory?

The most basic question, and the most frequently skipped. Ask it during procurement or PoC:

• Where is memory stored — plain text files or a vector database?
• Who can write to it? Who can read it?
• Is memory shared across users or across projects?
• Can you list, export, and clear the memory?

If the vendor cannot explain how to clear memory, that is a red flag.

2. Treat Memory Writes as a Privileged Operation

This is the core recommendation both studies converge on. In practice:

• Sensitive memory types (contacts, amounts, credentials, internal procedures) require user confirmation before being written
• Tag every memory entry with provenance: user input, internal system, or untrusted external content
• Memory written from external sources should not directly drive actions by default — treat it as reference only

3. Isolate Untrusted Input Channels

Email is the archetypal untrusted channel, because anyone can send you one.

One approach that has been proposed: have a separate agent with no memory and no file access read the mail, and pass only summaries to the main system. The main system then receives processed information rather than the raw attack surface.

The same logic applies to support tickets, external forms, files in shared cloud drives, and scraped web content.

4. Inventory the Connector Ecosystem, Not Individual Tools

Three practical rules follow from PromptArmor's observations:

• The unit of review is the connector ecosystem, not a single tool — the tool list under one connector grows over time
• Approvals should expire, with a re-review mechanism; one-time permanent approval does not hold up
• Require vendors to disclose their subprocessor chain, and note that inference-location settings do not govern third-party data processing

5. Bring Memory Into Existing Logging and Audit Processes

Your SIEM already collects logins, API calls, and file access. Memory writes deserve the same treatment:

• Log every memory write: timestamp, content, source, triggering session
• Alert on high-risk memory categories
• During incident response, memory modification records must reconcile with email or document sources

6. Manage the Agent Like a Privileged Employee

The last point is a mindset issue. Enterprises give employees tiered permissions, offboarding revocation, and behavioral monitoring. AI agents often receive broader access than a new hire, with far less governance.

Least privilege applies directly: an agent that needs to read mail does not need to send mail; one that needs to query a database does not need to write to it.

For a fuller enterprise adoption framework, see AI Agent Enterprise Application Guide. If you are designing agent architecture and state management, AI Agent Frameworks Deep Dive compares how frameworks handle memory and checkpointing.

Should You Pause Adoption Over This?

No. A few reasons:

First, both studies were academic work conducted in sealed test environments, not reports of real-world incidents. Both teams also proposed defensive directions.

Second, defenders have plenty of intervention points. GhostWriter's numbers show roughly 98% injection success but around 60% average activation — that gap is defensive room. Add write gating and provenance tagging, and there are more control points still.

Third, these controls are cheap. Provenance tagging, write confirmation, and memory logging are mostly configuration and process work, not a procurement cycle.

What you should actually avoid is deploying a memory-enabled agent, granting it full access to mail and cloud storage, and putting no memory governance in place at all. That is stacking all three risk factors together.

A One-Page Action List for IT and Security Leaders

This week

1. Inventory which AI agents and assistants in your organization have long-term memory
2. For each one, confirm where memory is stored and how to clear it
3. Check whether any agent reads external email or forms directly

This month

1. Establish logging and retention policy for memory writes
2. Add user confirmation for high-risk memory categories
3. Re-review your approved connector list to see whether tool scope has expanded

This quarter

1. Bring AI agents into your existing permission inventory and access review cycle
2. Add a memory-poisoning section to your AI usage policy (most policies today cover only prompt injection)
3. Run a red team exercise against critical agents, focused on delayed effects rather than immediate hijacking

Frequently Asked Questions

Should memory poisoning and prompt injection be separate sections in our security policy?

Yes, we recommend separating them. The defensive focus differs: prompt injection is about input filtering and instruction isolation, while memory poisoning is about write gating, provenance tagging, and audit trails. A policy that only says "guard against prompt injection" tends to produce input-layer controls only, leaving the memory-write path unaddressed.

We use vector memory rather than plain text files. Is that safer?

Do not assume so. Alongside plain-text-memory agents, the MemGhost research also tested vector memory backends such as Mem0, and found the payloads transferred across memory mechanisms. What determines risk is not the storage format but whether writes are gated and whether retrieved content carries verified provenance.

Which is more serious — MemGhost's 87.5% or GhostWriter's 98%?

They measure different things, cannot be compared directly, and must never be swapped when cited. MemGhost's 87.5% is an end-to-end success rate requiring memory write, non-disclosure in the immediate reply, and impact on later behavior all at once, measured on OpenClaw with GPT-5.4. GhostWriter's 98% is a memory injection success rate — the first stage of the chain — and that study separately reports about 60% average activation. They are independent studies by different teams.

If an agent has already been poisoned, how would I know?

Today the practical answer is log-based reconstruction. If you have memory write records (timestamp, content, source), you can compare the point at which behavior became anomalous against what was written before and after, and where it came from. With no records at all, the usual remaining option is to clear memory and rebuild it from trusted sources. This is exactly why memory logging should be established at deployment time, not after an incident.

We are an SMB with no dedicated security staff. What is the minimum we should do?

Three things. First, do not let AI agents read external email or forms directly — put a human or a memory-less processing layer in between. Second, make sure you know how to clear the agent's memory, and review its contents periodically. Third, apply least privilege: if the agent needs read access, do not grant write; if it needs query access, do not grant delete. None of these require purchasing a tool.

How often should connectors be reviewed?

There is no standard answer, but PromptArmor's observation gives a reference point: 37% of connectors changed substantially within six weeks, including new tools and rewritten tool descriptions. That makes annual review clearly insufficient. A practical approach is to re-confirm high-risk connectors (those with write or delete capability) quarterly, and to record the tool scope at time of approval so you can later detect expansion.

---

Need an AI Agent Security Assessment?

Agents with memory and connectors have a different risk model than traditional applications. Existing vulnerability scanning and access controls do not automatically cover them.

CloudInsight provides:

• AI agent security risk assessment (memory and connector attack surface inventory)
• AI usage policy design (adding memory poisoning and untrusted input isolation)
• Connector and third-party subprocessor chain inventory
• Permission governance for AI services and cloud resources

Schedule a security assessment and we will respond within 24 hours. All consultations are confidential, with no sales pressure.

---

Further Reading

• AI Security Complete Analysis: AI-Driven Threats and Defense Strategies: the overall AI-era threat landscape
• AI Agent Frameworks Deep Dive: how frameworks differ on state and memory management
• AI Agent Enterprise Application Guide: adoption strategy, evaluation frameworks, and ROI

Sources

• iThome: report on MemGhost — AI agent long-term memory as a new attack surface, up to 87.5% success planting false information via a single email (Nanyang Technological University / A*STAR / Johns Hopkins University)
• TechNews Infosecurity: report on the GhostWriter attack research (New Mexico State University)
• The Register: report on PromptArmor's research into ChatGPT and Claude third-party connector ecosystems (July 2026)