When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model Agents

# When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model Agents
Source: [https://arxiv.org/html/2607.06595](https://arxiv.org/html/2607.06595)
###### Abstract

Personal AI agents powered by large language models can reason and act using available tools to access emails, manage calendars, and push code to remote repositories, all with minimal oversight\. When augmented with long\-term memory, an agent can recall specific details relevant to the current task, reducing the need for large context windows\. Currently, long\-term memory agents tend to fall into two distinct domains: conversational and action\-planning agents\. Personal assistant agents sit at the convergence of these two domains and handle sensitive information while interacting with untrusted information sources, creating previously unaccounted security vulnerabilities\. In this work, we introduce the novel attack vector, GhostWriter, which exploits current memory subsystems in tool\-using personal agents to poison their memory store\. GhostWriter operates in two phases: injection, where an adversary sends a hidden attack payload to the target agent; and activation, in which the poisoned memory is retrieved\. We show that GhostWriter achieves near\-universal injection rates of approximately 98% and a high average activation rate of approximately 60% against state\-of\-the\-art agents\. This attack is possible due to the lack of security\-focused memory governance\. In response, we propose Agentic Memory Sentry \(AM\-Sentry\), which leverages two mitigation techniques: a memory\-saving policy and a memory\-retrieval screen\. Our experiments show that AM\-Sentry dramatically reduces GhostWriter’s success rate while preserving agent utility\.

## 1Introduction

Large language model \(LLM\) agents can reason and act with minimal human oversight, enabling automation of complex, multi\-step tasks\. These agents have access to tools that improve their efficiency and agency, allowing them to access emails, reply to calendar invites, and even push code to remote repositories\[[20](https://arxiv.org/html/2607.06595#bib.bib7),[25](https://arxiv.org/html/2607.06595#bib.bib21)\]\. An agent’s reasoning, decision\-making, and accuracy can be further improved through the integration of long\-term memory\[[17](https://arxiv.org/html/2607.06595#bib.bib8),[38](https://arxiv.org/html/2607.06595#bib.bib12)\]\. An agent with long\-term memory can recall specific details relevant to its current task, reducing the need for large context windows that do not scale well\. Figure[1](https://arxiv.org/html/2607.06595#S1.F1)illustrates this with an example: across sessions or after long periods between related tasks, an agent with only its context window struggles to accurately answer the user’s question and may even hallucinate\. In contrast, the agent equipped with a long\-term memory store can dynamically retrieve the necessary context and accurately answer the given question\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/x1.png)Figure 1:Stateless LLM agents process each interaction in isolation\. LLM agents with persistent memory allow for querying and retrieving saved information\.The existing literature on agents with long\-term memory has primarily been split into two distinct domains: conversational agents \(i\.e\., chatbots\)\[[17](https://arxiv.org/html/2607.06595#bib.bib8),[10](https://arxiv.org/html/2607.06595#bib.bib9)\], whose primary role is to talk with a user, and action\-planning agents\[[9](https://arxiv.org/html/2607.06595#bib.bib19),[38](https://arxiv.org/html/2607.06595#bib.bib12)\], which focus on improving tool use or other complex operations, such as robotic control or code execution\. Practical use cases that combine aspects of both domains, such as personal assistant agents or automated coding agents\[[16](https://arxiv.org/html/2607.06595#bib.bib25),[28](https://arxiv.org/html/2607.06595#bib.bib27)\], are currently underrepresented, and these agents would clearly benefit from including both fact\-based and action\-planning memory for tool use\. When long\-term memory is used in such agents, new security risks arise in the context of untrusted sources of information, their storage, and how they may, in turn, affect the agent’s future behavior\.

These agents routinely interact with untrusted sources of information, such as emails and documents, creating a distinct attack surface for indirect memory poisoning\. An adversary can send malicious or misleading content to an agent \(e\.g\. email agent\), which is then stored in the agent’s memory store for later use\. Later, when the user submits a benign prompt, the malicious content is retrieved from the memory store and added to the agent’s context, which alters the agent’s behavior to align with the adversary’s goals\. For example, consider a personal assistant agent that saved a malicious workflow instruction that later directs it to include an unauthorized recipient in emails containing confidential information about the user’s current project, thereby compromising the user’s nondisclosure agreements\.

Such attacks are enabled by the lack of security\-focused memory governance\. Currently, long\-term memory agents tend to retain every interaction\. Memory governance for agents has been proposed by A\-MAC\[[37](https://arxiv.org/html/2607.06595#bib.bib16)\], though it primarily focuses on improving utility rather than detecting malicious or misleading content, leaving the underlying memory stores vulnerable to these attacks\. Security\-focused memory governance is needed to protect agents from the influence of malicious content while remaining productive\.

The poisoning of an agent’s memory store or knowledge base has been explored by works such as AgentPoison\[[2](https://arxiv.org/html/2607.06595#bib.bib13)\]and MINJA\[[5](https://arxiv.org/html/2607.06595#bib.bib14)\], which demonstrated that corrupted memory can significantly degrade agent behavior and can be exploited to induce harmful actions\. The adversaries in these works have direct access to the memory system or direct interaction with the target agents, allowing them to directly inject memories or prompt agents to store poisoned memories\. A more realistic scenario assumes that an adversary would not have direct access to the agent or its memory store; instead, they must poison the agent’s memory through the inputs it receives, such as emails, documents, and calendar events\.

To address these gaps in the literature, we detail a novel attack vectorGhostWriter, which exploits the lack of security\-focused memory governance in tool\-using personal assistant agents to poison the memory store\.GhostWriteroperates in two phases: injection, where an adversary sends a hidden attack payload to the target agent, followed by activation, in which the poisoned memory is retrieved and influences the agent’s behavior\. We show thatGhostWriterachieves average injection rates of roughly 98% and a high average activation rate of roughly 60% across all tested state\-of\-the\-art agent architectures\. We also compareGhostWriterto prompt injection\[[4](https://arxiv.org/html/2607.06595#bib.bib3)\], another type of attack against agents, and highlight the differences in attack signature and activation, showing thatGhostWriterhas a greater impact on the evaluated agents\.

We also propose Agentic Memory Sentry \(AM\-Sentry\), which combines two mitigation techniques: a memory\-saving policy and a retrieval screen, designed to prevent these attacks while maintaining utility\.AM\-Sentry’s memory\-saving policy has three levels of strictness, each adding stronger constraints and vulnerability\-detection capabilities\. The retrieval screen can be enabled or disabled\. When enabled, it reviews each retrieved memory entry and filters out those that contain vulnerabilities or hidden directives that could alter the agent’s behavior\. The three memory\-saving policies, paired with the two retrieval screen settings, yields six configurations\. We analyze the effectiveness of each configuration in preventingGhostWriterattacks and its effects on agent performance\. We show that attack effectiveness can be dramatically reduced at minimal cost to agent utility\. We also introduce a custom test suite that assesses an agent’s recall and task performance in a personal assistant use case, allowing us to assess the impactAM\-Sentryhas on each agent’s base utility\.

Ournovel contributionsinclude:

- •We detailGhostWriter, a novel attack vector that exploits the lack of security\-focused memory governance in long\-term memory tool\-using agents to poison the memory store via untrusted tool inputs\.
- •We proposeAM\-Sentry, a novel memory defense framework with six configurations of memory policy strictness and retrieval screening\.
- •We evaluateGhostWriteragainst five state\-of\-the\-art agents across four LLM models and assess the effectiveness ofAM\-Sentryin reducing attack success and preserving agent utility\.

We plan to release our implementation and evaluation toolkit, which includes our attack setup and agent performance test suite, to spur others to test new attack vectors and mitigation techniques or to evaluate the utility of their agent implementation\.

The rest of the paper is organized as follows\. Section[2](https://arxiv.org/html/2607.06595#S2)provides a literature review on LLM agents and memory poisoning, while Section[3](https://arxiv.org/html/2607.06595#S3)defines our system and threat models\. We present theGhostWriterattack vector in Section[4](https://arxiv.org/html/2607.06595#S4)and theAM\-Sentrymitigation architecture in Section[5](https://arxiv.org/html/2607.06595#S5)\. Our experimental methodology and evaluations are then covered in Sections[6](https://arxiv.org/html/2607.06595#S6)and[7](https://arxiv.org/html/2607.06595#S7), respectively\. Finally, Sections[8](https://arxiv.org/html/2607.06595#S8)and[9](https://arxiv.org/html/2607.06595#S9)detail limitations, future work, and our concluding remarks\.

## 2Background and Related Work

### 2\.1LLM Agents

LLM agents are autonomous systems that leverage LLMs to perceive, reason, and take dynamic actions based on their current context\[[25](https://arxiv.org/html/2607.06595#bib.bib21)\]\. Agents are increasingly deployed in real\-world settings\[[31](https://arxiv.org/html/2607.06595#bib.bib22)\], with open\-source frameworks such as AutoGPT\[[23](https://arxiv.org/html/2607.06595#bib.bib23)\]and BabyAGI\[[15](https://arxiv.org/html/2607.06595#bib.bib24)\]providing easy means of adoption\. Multi\-step reasoning agents, such as ReAct\[[36](https://arxiv.org/html/2607.06595#bib.bib6)\], interleave reasoning with actions, enabling them to generate thoughts that enrich their current context and improve later decisions\. Equipping agents with external tools provides them with a structured means of interacting with external elements and improving their performance\[[20](https://arxiv.org/html/2607.06595#bib.bib7)\]\. Tools are widely used and incorporated into production\-level LLM interfaces such as ChatGPT and Claude\[[16](https://arxiv.org/html/2607.06595#bib.bib25),[1](https://arxiv.org/html/2607.06595#bib.bib26)\]\. Combining tool use and multi\-step reasoning has greatly increased agent utility across the board\[[25](https://arxiv.org/html/2607.06595#bib.bib21),[29](https://arxiv.org/html/2607.06595#bib.bib20)\]\.

### 2\.2Memory\-based Agents

Memory context is a prevailing issue in current agents and LLM interfaces; large context windows tend to slow down performance and increase computational costs\[[17](https://arxiv.org/html/2607.06595#bib.bib8)\]\. To address this issue, systems that manage an agent’s current context via an additional database have been proposed\. One such approach is the Retrieval\-Augmented Generation \(RAG\) system, which pulls in real\-time context from a pre\-seeded database\[[13](https://arxiv.org/html/2607.06595#bib.bib4)\]based on the given prompt\. A variety of RAG systems have been proposed\[[8](https://arxiv.org/html/2607.06595#bib.bib18)\]in the literature, but they mostly rely on pre\-existing information and are unable to learn from their experiences\.

RAG systems and other information stores benefit from agents saving their own examples, experiences, and acquired knowledge in them\. The concept of long\-term cross\-session memory was introduced by works such as MemGPT\[[17](https://arxiv.org/html/2607.06595#bib.bib8)\]and Generative Agents\[[18](https://arxiv.org/html/2607.06595#bib.bib5)\], showing that improvements in agent response and recall greatly outweigh those of simple systems that rely on longer context windows, which are not scalable\. Agents store knowledge/interactions in their memory stores, labeling them with descriptive tags that enable later retrieval based on semantically similar prompts\. MemoryOS\[[10](https://arxiv.org/html/2607.06595#bib.bib9)\]introduced a memory system composed of three types of memory stores: short\-, medium\-, and long\-term\. A\-MEM\[[32](https://arxiv.org/html/2607.06595#bib.bib10)\]introduces dynamic memory linking, which uses an LLM call to help manage the memory store and the relationship between memories\.

The works discussed thus far have focused on conversational agents that engaged in conversation with a single user; a separate line of work involves action\-planning agents such as Reflexion\[[22](https://arxiv.org/html/2607.06595#bib.bib11)\], which uses repeated self\-reflections on past attempts to improve its current action plan\. These action plans represent the steps an agent takes to reach a goal, which could involve successfully using an external tool or the steps needed to move a robotic machine\. Retrieval\-augmented planning \(RAP\)\[[9](https://arxiv.org/html/2607.06595#bib.bib19)\]introduces a long\-term memory store for these types of agents, allowing them to draw on previously successful attempts \(trajectories\) at the same or similar tasks to improve performance and reduce the number of attempts needed to succeed\. ExpeL\[[38](https://arxiv.org/html/2607.06595#bib.bib12)\]pairs both successful and failed stored trajectories with reflections to further improve performance, allowing agents to extract insights from their past experiences\.

Current work on long\-term memory agents can be separated into two domains: conversational agents, which remember facts about their users, and action\-planning agents, which remember optimal means for performing various actions and tool calls\. Both domains focus on improving how memories are stored, tagged, and retrieved within their own context, leaving their convergence underexplored\. Realistic, practical deployment, such as an automated coding or a personal assistant agent, is missing from these works\. These types of agents require aspects from both domains, as they must store information about their users or work environments and use tools to perform specific actions\.

### 2\.3Memory Poisoning Attacks and Defenses

Personal assistant agents are responsible for handling sensitive information and operations; thus, it is critical that their behavior not be steered toward adversarial outcomes\. Agents powered by LLMs have been shown to be easily manipulated when provided with false or misleading information, as demonstrated by recent incidents involving Meta customer support chat agents\[[7](https://arxiv.org/html/2607.06595#bib.bib38)\]\. AgentPoison\[[2](https://arxiv.org/html/2607.06595#bib.bib13)\]shows the potential damage when such false or misleading information is persisted into long\-term memory, showing that an injected poisoned memory can hijack an agent’s actions and induce malicious behavior\. Agents can also be tricked into executing and then saving a malicious action plan through careful prompt injection, as detailed by MINJA\[[5](https://arxiv.org/html/2607.06595#bib.bib14)\]\. These attacks center on impractical adversarial models; either the adversary has direct access to the memory store or to the agent itself, which would require access to the user’s credentials to mount an attack\.

Another means of mounting a memory poisoning attack is to feed an agent corrupted inputs through its tool interface, which are saved as part of an agent’s regular operations\. Some early work has considered this attack vector, such as Zombie Agents\[[33](https://arxiv.org/html/2607.06595#bib.bib15)\], which details how web search\-capable agents exposed to malicious web pages can be manipulated into storing adversarial instructions that alter behavior upon retrieval\. However, this work operates under assumptions that limit its applicability to realistic deployments; it requires an agent with RAG\-based memory to repeatedly store the same attack payload hundreds of times to be effective, something that would not work on memory systems with simple deduplication\. This and similar works, such as MemoryGraft\[[24](https://arxiv.org/html/2607.06595#bib.bib28)\], focused their attack evaluations on their own agent implementations rather than demonstrating their applicability to the state\-of\-the\-art\.

Defenses against these poisoning attacks are an emerging area with limited dedicated work\. The existing literature tends to focus on AgentPoison and MINJA\-type attacks\. A\-MemGuard\[[27](https://arxiv.org/html/2607.06595#bib.bib29)\], for example, proposes a consensus\-based retrieval mechanism to detect anomalous memories, an approach that is inapplicable to fact\-based memory systems where no comparable reasoning paths exist\. A\-MAC\[[37](https://arxiv.org/html/2607.06595#bib.bib16)\]introduces the concept of memory governance, but focuses solely on utility and does not address memory poisoning vulnerabilities\. No existing work investigates indirect memory poisoning through untrusted tool inputs against state\-of\-the\-art agents, nor proposes defenses that address this attack path or evaluate the resulting security\-utility tradeoff\. In this paper, we attempt to plug this gap\.

## 3Models and Assumptions

In this section, we describe the models and assumptions underlying our work on personal AI agents\. We first present the system model, then outline our security assumptions, and finally define the threat model\.

### 3\.1System Model

We envision a practical deployment in an office environment where a personal AI agent assists with email and calendar management\. The agent autonomously monitors the user’s inbox and activates when the user receives emails or calendar invites\. The user can also submit prompts directly to the agent to request email summaries, feedback on in\-progress documents, reminders of upcoming meetings, or to send emails on their behalf\. To support interactions with external services, the agent has access to tool APIs that enable email and calendar functionality\. The agent is also equipped with a long\-term memory store to improve recall and better support task continuity and context retention\.

We consider four entities in this deployment: the user, their agent, internal contacts, and external contacts\. Agents remain dormant until an event triggers their response\. Events include direct user input, incoming emails or calendar invites, and scheduled events\. When triggered, an agent processes the interaction and writes it to memory as a summary, extracted facts, a useful trajectory, or verbatim text, depending on the agent’s design\. During processing, agents tag each memory based on its content and link it to closely related memories\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/x2.png)Figure 2:AI email assistant with persistent memory\.When the user later submits a task or question, the agent retrieves relevant information into its context and responds accordingly\. Retrieval typically proceeds by matching the tags in the user’s query to those in the memories\. Figure[2](https://arxiv.org/html/2607.06595#S3.F2)illustrates a use case for an AI email assistant: the agent retrieves the relevant meeting invite, recalls a deadline change, and drafts an email to the correct recipient\. An agent without memory lacks this context and would fail to recall the deadline change or identify the correct recipient\.

### 3\.2Security Assumptions

Our security analysis is predicated on a set of operational assumptions\. First, we assume the agent’s core execution logic is benign; its hardcoded actions operate in good faith and are free of malicious code\. Second, we assume the agent’s memory infrastructure maintains strict cryptographic or logical isolation, rendering it fully resilient to out\-of\-band tampering thus functioning as a black box to the adversary\. Finally, we assume user accounts are secure, and external adversaries cannot bypass standard access controls to directly interface with the agent or its host environment\.

### 3\.3Threat Model

We consider the user to be fully trusted, but it’s agent can be steered toward malicious actions if its context is compromised by adversarial directives\. We also consider internal and external adversaries\. Internal adversaries are parties with an established working relationship with the user’s organization, including employees, contractors, vendors, and other business partners\. External adversaries are third parties with no such relationship\. Both classes share the same attack mechanism: they use disguised inbound messages, such as emails that appear benign at a glance but contain hidden instructions\. They differ, however, in contextual knowledge\. Internal adversaries possess knowledge of the user’s work environment, including organizational structure, colleague names, ongoing projects, and project\-specific context, making their attacks more convincing\. External adversaries are limited to publicly available information, such as professional networking sites and company websites\. Neither class can directly access the agent’s API, modify the memory store, or compromise the user’s account\.

The adversary attempts to get the agent to store malicious or misleading information in its persistent memory, thereby influencing its future behavior\. The adversary’s goals fall into four categories:

1. 1\.Integrity corruption:the adversary injects misleading information, causing the agent to produce incorrect outputs or take unintended actions in future interactions\.
2. 2\.Sensitive information leakage:the adversary induces the agent to disclose the user’s private information\.
3. 3\.Covert exfiltration:the adversary plants instructions that cause the agent to covertly transmit information about the user’s activities to an external party\.
4. 4\.Scope escalation:the adversary causes the agent to take actions beyond its intended scope\.

## 4GhostWriterArchitecture

In this section, we elaborate onGhostWriter’s mechanisms and walk through formalized protocols\.GhostWriterfollows a two\-phase protocol:injection\(Section[4\.1](https://arxiv.org/html/2607.06595#S4.SS1)\), where the adversary feeds a poisoned memory to the target, andactivation\(Section[4\.2](https://arxiv.org/html/2607.06595#S4.SS2)\), where the poisoned memory is retrieved on a benign query, altering the agent’s behavior\. Note that the adversary controls only the injected content; they have no influence on future user prompts or on the agents’ retrieval mechanisms\. Figure[3](https://arxiv.org/html/2607.06595#S4.F3)gives an overview of both phases where an adversary sends an email claiming that a colleague’s email address has changed\. This information is stored by the agent and later retrieved when the user requests to send an email to their colleague, at which point the agent redirects the email to the malicious address\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/x3.png)Figure 3:Two\-phase memory injection attack: Phase 1 poisons the memory, which is retrieved and acted upon in Phase 2 during a legitimate user request for an email address\.### 4\.1Memory Injection

GhostWriter’s first phase is formalized in Protocol[1](https://arxiv.org/html/2607.06595#alg1), which begins with adversary𝒜\\mathcal\{A\}choosing a goal \(gg\) \(Line 1\)\.𝒜\\mathcal\{A\}then selects a target prompttt\(e\.g\., “Send an email to the client”\), that aligns withgg\(Line 2\)\. Bothggandttare then used to construct a malicious payloadpp, which is then embedded within a legitimate\-looking messagexx, such as a team meeting email \(Lines 3\-4\)\.𝒜\\mathcal\{A\}then sendsxxto the inbox of their targeted user \(𝒰\\mathcal\{U\}\), at which point agentℳ\\mathcal\{M\}will automatically pass the message to its ingestion functionff\(Line 5\-6\)\. The function returns a created memorymm, and adds it to its memory store𝒮\\mathcal\{S\}\(Line 6\)\. Ifppis preserved withinmm, then Phase 1 is considered successful\.

Protocol 1Memory Injection \(Phase 1\)0:Adversary \(

𝒜\\mathcal\{A\}\), Agent \(

ℳ\\mathcal\{M\}\), User \(

𝒰\\mathcal\{U\}\), ingestion function \(

ff\), memory store \(

𝒮\\mathcal\{S\}\)\.

0:Adversary𝒜\\mathcal\{A\}

1:Select goal

g∈\{g\\in\\\{Integrity\_corruption, Sensitive\_info\_leakage, Covert\_exfiltration, Scope\_escalation

\}\\\};

2:

t←SelectTarget​\(g\)t\\leftarrow\\texttt\{SelectTarget\}\(g\); // Target prompt is chosen\.

3:

p←Construct​\(g,t\)p\\leftarrow\\texttt\{Construct\}\(g,t\); // Attack payload

ppis created\.

4:

x←Embed​\(p\)x\\leftarrow\\texttt\{Embed\}\(p\); //

ppis inserted into a email\.

5:Deliver

xxto

𝒰\\mathcal\{U\}’s inbox;

5:Agentℳ\\mathcal\{M\}

6:

m←f​\(x\)m\\leftarrow f\(x\); store

m∈𝒮m\\in\\mathcal\{S\}// Email is converted into a memory\.

6:Injection succeeds

⇔\\iffpppreserved within

m∈𝒮m\\in\\mathcal\{S\}

To increase the probability that the malicious memory is retrieved by the user’s agent, an adversary can optimize their payload to better match the targeted prompt\. This optimization can take place in black\-, gray\-, or white\-box settings\. Similar to how attacks on machine learning models are studied\. While we consider all of the settings to be relevant, as outlined by our security assumptions we consider only a black\-box approach\.

Score​\(p,T,E\)=1\|T\|​∑qi∈Tcos⁡\(E​\(p\),E​\(qi\)\)\\texttt\{Score\}\(p,T,E\)=\\frac\{1\}\{\|T\|\}\\sum\_\{q\_\{i\}\\in T\}\\cos\\bigl\(E\(p\),\\,E\(q\_\{i\}\)\\bigr\)\(1\)
Protocol[2](https://arxiv.org/html/2607.06595#alg2)describes our approach, in which an adversary can use a public email corpus, such as the Enron Email Corpus\[[11](https://arxiv.org/html/2607.06595#bib.bib30)\], clustering it intokktopics which are stored inQQ, examples of these topics include client communications, deadline extensions, workflow policies, etc \(Line 1\)\. The adversary can then identify the cluster \(TT\) most closely aligned to their target prompttt, allowing them to score \(ss\) the similarity of their attack email toTT\(Lines 2\-3\)\. The score is calculated using Equation[1](https://arxiv.org/html/2607.06595#S4.E1), which takes an attack payloadpp, a topic clusterTT, and an embedding algorithmEEas parameters\. ForEEthere are several options to choose from for the attacker\[[19](https://arxiv.org/html/2607.06595#bib.bib39),[30](https://arxiv.org/html/2607.06595#bib.bib40)\], which may or may not align with the user’s agent’s embedding model\.

The computed similarity scoressis then compared to a target thresholdτ\\tau\. If the score is belowτ\\tau, thenppwill be rewritten and saved as a temporary attack emailp′p^\{\\prime\}, which will then be scored and saved ass′s^\{\\prime\}\(Lines 4\-6\)\. If the resulting scores′s^\{\\prime\}is higher than the previous scoress, thenppis overwritten withp′p^\{\\prime\}\(Lines 7\-8\)\. This process is repeated until the similarity score exceedsτ\\tau, and the final optimized attack email is returned \(Line 11\)\. This iterative process ensures that the attack is potent\.

Protocol 2Black\-Box Retrieval Optimization0:Payload \(

pp\), email corpus \(

𝒞\\mathcal\{C\}\), embedding model \(

EE\), number of topics \(

kk\), target prompt \(

tt\), similarity threshold \(

τ\\tau\)\.

0:Optimized payload

p∗p^\{\*\}
1:

Q←Cluster​\(𝒞,k,E\)Q\\leftarrow\\texttt\{Cluster\}\(\\mathcal\{C\},k,E\); // Cluster

𝒞\\mathcal\{C\}into

kktopics\.

2:

T←classify​\(t,Q,E\)T\\leftarrow\\texttt\{classify\}\(t,Q,E\); // Find topic cluster for

tt\.

3:

s←Score​\(p,T,E\)s\\leftarrow\\texttt\{Score\}\(p,T,E\); // Score

pp’s similarity to

TT;

4:while

s<τs<\\taudo

5:

p′←Rewrite​\(p\)p^\{\\prime\}\\leftarrow\\texttt\{Rewrite\}\(p\);

6:

s′←Score​\(p′,T,E\)s^\{\\prime\}\\leftarrow\\texttt\{Score\}\(p^\{\\prime\},T,E\);

7:if

s′\>ss^\{\\prime\}\>sthen

8:

p←p′p\\leftarrow p^\{\\prime\},

s←s′s\\leftarrow s^\{\\prime\}; // Update

ppwhen

p′p^\{\\prime\}scores better\.

9:endif

10:endwhile

11:return

p∗=pp^\{\*\}=p; // Return the final result\.

### 4\.2Attack Activation

Protocol[3](https://arxiv.org/html/2607.06595#alg3)outlinesGhostWriter’s second phase\. Once a poisoned memorymmis added to the memory store𝒮\\mathcal\{S\}, it lies dormant until it is later retrieved\. The user \(𝒰\\mathcal\{U\}\) submits a prompt \(qq\) to its agent \(ℳ\\mathcal\{M\}\), which then passesqqto its memory retrieval function \(Line 1\)\. The function returns a set of memories,ℛ\\mathcal\{R\}, composed of the topkkresults that most closely align withqq\(Line 2\)\.ℛ\\mathcal\{R\}is then added to the agent’s current context \(CC\), which is utilized to generate a responserr\(Lines 3\-4\)\. Ifmmis present inℛ\\mathcal\{R\}, the agent’s behavior will be steered toward the adversary’s goal \(Lines 5\-6\)\. Otherwise, the agent proceeds normally \(Lines 7\-9\)\.

Once the user submits a prompt that closely mirrors the targeted prompt, such as ‘send an email’, ‘schedule a meeting’, etc\., the agent will be highly likely to retrieve the poisoned memory from its memory store\. The agent, believing the memory to be trusted, follows the malicious directive planted within, which may have it add a malicious address to an email or leak sensitive information\. An agent’s memory architecture affects its susceptibility to retrieving poisoned memories, as it may apply summarization steps, delete older memories in favor of newer ones, or combine details from a new memory into an old one\. The impact of these architectural differences is analyzed in Section[7](https://arxiv.org/html/2607.06595#S7)\.

Protocol 3Attack Activation \(Phase 2\)0:Agent \(

ℳ\\mathcal\{M\}\), User \(

𝒰\\mathcal\{U\}\), memory store \(

𝒮\\mathcal\{S\}\), retrieval window \(

kk\), poisoned memory \(

mm\)\.

0:User𝒰\\mathcal\{U\}

1:Submits a benign prompt

qqto

ℳ\\mathcal\{M\}\.

1:Agentℳ\\mathcal\{M\}

2:

ℛ←Retrieve​\(q,k,𝒮\)\\mathcal\{R\}\\leftarrow\\texttt\{Retrieve\}\(q,k,\\mathcal\{S\}\); //

kkentries are retrieved from

𝒮\\mathcal\{S\}\.

3:

C←\{q\}∪ℛC\\leftarrow\\\{q\\\}\\cup\\mathcal\{R\}; // Retrieved memories

RRis added to context\.

4:

ℳ\\mathcal\{M\}generates response

rrbased on context

CC;

5:if

m∈Rm\\in Rthen

6:

rrdeviates from

𝒰\\mathcal\{U\}’s intent;

7:else

8:

rrproceeds normally; //

𝒰\\mathcal\{U\}’s intent is preserved\.

9:endif

## 5AM\-Sentry Architecture

Proposed memory systems for agents largely ignore the adversarial threat vector introduced by storing inputs in long\-term memory\. These ingestion channels also give an adversary a path to inject false or malicious information into the agent’s memory, which can then shape the summaries it produces, the recommendations it makes, and the actions it takes on the user’s behalf\. Adversaries can learn a lot about a company, such as employee names, communication protocol, allowing them to craft an attack payload indistinguishable from legitimate sources, as seen in targeted business email compromise \(BEC\) attacks\[[6](https://arxiv.org/html/2607.06595#bib.bib31)\]\.

In this context, spam filtering is insufficient because a targeted adversary can craft semantically valid messages that evade aggregate classifiers, and a single injection can persist across sessions\. Defending against this threat requires policy directives defining which inputs may modify the long\-term state\. A secure memory governance system must be designed to satisfy the following goals:

- •Preserve utility:maintain the assistant’s ability to reason over accumulated context\.
- •Signature\-independent defenses:defend against novel, previously unseen payloads\.
- •Malicious memory characterization:define what makes a memory unsafe\.
- •Source trust modeling:assess inputs by where they originate, not only what they contain\.
- •Architecture\-agnostic:operate across assistant implementations and model families without assumptions about the underlying memory or model\.
- •Two\-stage coverage:protection at memory saving and memory retrieval\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/x4.png)Figure 4:Incoming content is evaluated before being admitted to the memory store\. Legitimate updates are accepted, while malicious content is blocked\.We introduceAM\-Sentry, a modular, two\-stage defense system for securing stateful agentic applications\.AM\-Sentrycomprises two complementary mechanisms:\(i\)a policy component that governs which inputs are saved to memory, and\(ii\)a retrieval screening component that inspects retrieved memories before they influence the agent\. Each component uses an LLM as a judge alongside non\-LLM decision logic\. In the remainder of this section, we describe each mechanism in detail and demonstrate how their combination satisfies the outlined design goals\.

### 5\.1Policy Configurations

TABLE I:S2S\_\{2\}memory fields\. An LLM judge evaluates all four fields and assigns score to each\.Current agentic memory systems store inputs without restriction, regardless of future utility or safety, allowing malicious inputs to enter long\-term memory\. A policy that determines what is stored closes this vulnerability, but it requires a structured memory representation so that each input can be judged uniformly\. The policy imposes this structure and evaluates every candidate against a set of rules before admission to the memory store\. Figure[4](https://arxiv.org/html/2607.06595#S5.F4)illustrates this with an example of our policy blocking a malicious email from being saved into the memory store\. We formalizeAM\-Sentrywith three distinct policy configurations \(S1S\_\{1\},S2S\_\{2\}, andS3S\_\{3\}\) of varying strictness\. Moving fromS1S\_\{1\}toS3S\_\{3\}, each configuration builds on the security properties of the previous through tighter rules, a richer memory structure, and more rigorous security assessment\.

Each policy configuration uses an LLM judge to evaluate a memory candidate across varying metrics and formats\. The first policy configuration,S1S\_\{1\}, consists of a single LLM judge that determines whether a memory candidate should be saved based on the potential future use of the information in the proposed memory\.S1S\_\{1\}has the LLM judge make a simple yes\-or\-no decision\.

Our second configuration,S2S\_\{2\}, introduces a more explicit structure and is formalized in Protocol[4](https://arxiv.org/html/2607.06595#alg4)\. An LLM judge evaluates memory candidates across four fields, which are described in Table[I](https://arxiv.org/html/2607.06595#S5.T1)\. Each field is assigned a numerical score between 0 and 1 \(Lines 1\-5\)\. These fields are then passed to the non\-LLM decision logic and used to make a final determination on the memory\. The utility \(uu\) and trust \(rr\) fields are used to determine a usefulness score \(UU\) \(Line 6\)\. The type \(tt\) is used in an equation with the origin field \(oo\) to determine a vulnerability score \(VV\) \(Line 7\)\. The memory is admitted only ifUUis sufficiently high andVVis sufficiently low \(Lines 8\-12\)\.

Protocol 4S2S\_\{2\}Policy Configuration0:Candidate memory \(

mm\), LLM judge \(

𝒥\\mathcal\{J\}\)\.

0:Admit or reject

mm
0:LLM Judge𝒥\\mathcal\{J\}

1:Scores

mmon four fields \(each 0\.0–1\.0\);

2:

o←Origin​\(m\)o\\leftarrow\\texttt\{Origin\}\(m\); // source identifiability

3:

r←Trust​\(m\)r\\leftarrow\\texttt\{Trust\}\(m\); // reliability of information

4:

t←Type​\(m\)t\\leftarrow\\texttt\{Type\}\(m\); // fact

\|\|workflow

\|\|contact

\|\|instruction

5:

u←Utility​\(m\)u\\leftarrow\\texttt\{Utility\}\(m\); // future task relevance

5:Non\-LLM Decision Logic

6:

U←0\.6⋅u\+0\.4⋅rU\\leftarrow 0\.6\\cdot u\+0\.4\\cdot r// usefulness equation

7:

V←t×\(1−o\)V\\leftarrow t\\times\(1\-o\); // vulnerability equation

8:if

U\>0\.4U\>0\.4and

V<0\.6V<0\.6then

9:returnAdmit;

10:else

11:returnReject;

12:endif

Protocol 5S3S\_\{3\}Policy Configuration0:Candidate memory \(

mm\), source metadata \(

S​MSM\), LLM judges \(

𝒥1,𝒥2\\mathcal\{J\}\_\{1\},\\mathcal\{J\}\_\{2\}\)\.

0:Admit or reject

mm
0:First LLM Judge𝒥1\\mathcal\{J\}\_\{1\}

1:Scores

mmon seven\-point checklist \(each 0\.0–1\.0\);

2:

s1←Vulnerables\_\{1\}\\leftarrow\\texttt\{Vulnerable\};

s2←Sensitivitys\_\{2\}\\leftarrow\\texttt\{Sensitivity\};

s3←Sources\_\{3\}\\leftarrow\\texttt\{Source\};

s4←Contradicts\_\{4\}\\leftarrow\\texttt\{Contradict\};

s5←Instructions\_\{5\}\\leftarrow\\texttt\{Instruction\};

s6←Verifys\_\{6\}\\leftarrow\\texttt\{Verify\};

s7←Justifys\_\{7\}\\leftarrow\\texttt\{Justify\};

2:Non\-LLM Decision Logic

3:if

s1<0\.6s\_\{1\}<0\.6then

4:returnReject; // hard reject on vulnerability

5:endif

6:

C←\(s2\+s3\)/2C\\leftarrow\(s\_\{2\}\+s\_\{3\}\)\\;/\\;2; // Critical item equation

7:

N←\(s4\+s5\+s6\+s7\)/4N\\leftarrow\(s\_\{4\}\+s\_\{5\}\+s\_\{6\}\+s\_\{7\}\)\\;/\\;4; // Non\-critical item equation

8:

F←0\.6⋅C\+0\.4⋅NF\\leftarrow 0\.6\\cdot C\+0\.4\\cdot N; // Final score equation

9:if

F<0\.4F<0\.4then

10:returnReject;

11:endif

11:Second LLM Judge𝒥2\\mathcal\{J\}\_\{2\}

12:

𝒥2\\mathcal\{J\}\_\{2\}receives

S​MSMand

s1s\_\{1\}\-

s7s\_\{7\}\.

13:return

𝒥2\\mathcal\{J\}\_\{2\}’s admit/reject decision\. // Looks for contradictions

TABLE II:S3S\_\{3\}checklist\. C = critical, NC = non\-critical\.ItemLevelScoring GuidanceVulnerabilityCNo harm potential \(1\.0\), Could change agent behavior \(0\.0\)\.SensitivityCNo sensitive data discussed \(1\.0\), Overrides sensitive data\. \(0\.0\)\.Source trustCUser \(1\.0\), Internal contact \(0\.8\), Client \(0\.3\), External untrusted \(0\.0\)\.ContradictionNCNo conflicts \(1\.0\), Contradicts multiple other memories \(0\.0\)\.InstructionNCInformative \(1\.0\), Directives \(0\.0\)\.VerifiabilityNCVerifiable \(1\.0\), Unverifiable \(0\.0\)\.JustificationNCClear future use \(1\.0\), Seemingly useless information \(0\.0\)\.S3S\_\{3\}is the strictest configuration; every memory candidate is evaluated on a seven\-point checklist, listed in Table[II](https://arxiv.org/html/2607.06595#S5.T2)\. There are three critical items \(vulnerability,sensitivity, andsource trust\), with thevulnerabilitytriggering a hard rejection if its score falls below the failing threshold\.S3S\_\{3\}is formalized in Protocol[5](https://arxiv.org/html/2607.06595#alg5), which begins with an LLM judge that evaluates each checklist item and assigns a score between 0 and 1 \(Lines 1\-2\)\. The filled\-in checklist is then passed to non\-LLM decision logic, which first checks whether the vulnerability score is too low and rejects it if so \(Lines 3\-5\)\. Otherwise, the other two critical items and the non\-critical items are combined to determine the final score \(FF\) for admission \(Lines 6\-8\)\. IfFFfalls below the acceptance threshold, the memory is rejected\. Otherwise, the scores and memory metadata are passed to a second LLM judge, which looks for signs that the first LLM judge was compromised through prompt injection \(Lines 9\-11\)\. If the second judge reasonably suspects the first judge was compromised, then the memory is dropped \(Lines 12\-13\)\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/x5.png)Figure 5:The retrieval screen blocks poisoned memories before they can enter an agent’s context\.Our policy configurations satisfy our design goals\. Theypreserve utilityby filtering out content deemed unnecessary, or that clearly signals malicious intent, thereby allowing legitimate useful content to be admitted\. Our policy configurations do not rely on pattern matching known attacks, making themsignature\-independent defensethat makes per\-memory decisions based on structure, provenance, and risk\.S3S\_\{3\}’s vulnerability assessment directly tests whether content could redirect communications, enable unauthorized actions, or leak information, providingmalicious memory characterization\.S2S\_\{2\}andS3S\_\{3\}make use ofsource trust modeling\. Our policy isarchitecture\-agnosticas it intercepts memory candidates before they enter a given agent’s memory store, and does not require changes to the underlying agent\.

### 5\.2Memory Retrieval Screen

When poisoned content is saved in the memory store, the defense must intercept it at retrieval time\. We accomplish this with a retrieval screen that evaluates each retrieved memory against the current context and blocks unsafe memories before they reach the agent\. Figure[5](https://arxiv.org/html/2607.06595#S5.F5)gives an example of the retrieval screen rejecting a suspicious memory containing an instruction to redirect communications\. Along with the memory\-saving policy, the retrieval screen provides in\-depth defense against memory\-injection attacks, ensuring that any memory\-bypassing admission is re\-evaluated before it influences the agent\. When paired with eitherS2S\_\{2\}orS3S\_\{3\}, the screen can leverage the structured metadata they produce, enabling it to operate on explicit trust, risk, and type annotations \(e\.g\.,\[trust=external\-untrusted,risk=medium,type=instruction\]\) rather than inferring them from memory itself\.

The screen first evaluates each retrieved memory against the current query\. The screen considers four criteria, summarized in Table[III](https://arxiv.org/html/2607.06595#S5.T3):relevance,instruction suppression,contradiction detection, andsource trust\. An LLM judge is asked to evaluate the first three criteria to determine the utility and safety of a retrieved memory\. The LLM judges and considers those criteria in the context of source trust; for example, a memory containing a directive will be retained if the source is trusted, but is otherwise discarded\. After iterating through all memories, the LLM judge returns the surviving memories to the agent’s context\.

TABLE III:Retrieval screen exclusion criteria\. The screen drops a candidate if any criterion fires\.The retrieval screen aims to filter malicious memories while preserving utility\. It*preserves utility*by minimizing unnecessary exclusions and admitting legitimate content into the agent’s context\. It provides*malicious memory characterization*by evaluating each candidate against known attack properties, specifically embedded instructions and unverifiable external claims\. It*models source trust*by conditioning on memory origin during evaluation, exploitingS2S\_\{2\}andS3S\_\{3\}metadata annotations when available\. Finally, it completes*two\-stage coverage*, serving as the memory\-retrieval counterpart to the memory\-saving policy and intercepting attacks that survive admission\.

## 6Experimental Methodology

### 6\.1Agent Selection

Given the absence of long\-term memory agents that are purpose\-built for a personal assistant use case, we selected five state\-of\-the\-art agent architectures and adapted them to a common evaluation setting: A\-Mem\[[32](https://arxiv.org/html/2607.06595#bib.bib10)\], Mem0\[[3](https://arxiv.org/html/2607.06595#bib.bib32)\], ExpeL\[[38](https://arxiv.org/html/2607.06595#bib.bib12)\], Letta \(formerly MemGPT\)\[[12](https://arxiv.org/html/2607.06595#bib.bib33),[17](https://arxiv.org/html/2607.06595#bib.bib8)\], and MemoryOS\[[10](https://arxiv.org/html/2607.06595#bib.bib9)\]\. These agents represent a variety of memory representation, organization, and retrieval techniques, allowing us to compare against a variety of design choices\. The majority of selected agents use fact\-based memory, as they seemingly suit the use case best\. We also included ExpeL, an agent with trajectory\-based memory that stores successful action plans rather than facts, introducing distinct vulnerability characteristics for us to assess\.

We built a wrapper for each agent that exposes a common interface\. We only made architectural adjustments to allow us to evaluate each agent uniformly while preserving the mechanisms central to each agent’s design\. The wrapper includes a system prompt that informs the agent of their assignment and capabilities, a common tool interface accessible to all agents, and standardization of input feeding and output gathering\. Our simulated tool APIs allow agents to accept input from email or calendar events and sending email\. The agents were instrumented to capture all their output and operations to support analysis and iterative refinement of the adaptations\.AM\-Sentrywas also integrated into the wrapper, so that regardless of how an agent represents their memory,AM\-Sentrycould be applied to all\.

These agents have various ways of saving user inputs as memories; some extract information and save only facts, others summarize the event and save only the summary, while others save the entire interaction, such as Letta\. For most, we did not alter their design, though in the case of MemoryOS, a change was required\. MemoryOS saves a conversation pair; the input is saved verbatim, and so is the agent’s response\. The issue with that design is that many tasks result in a simple acknowledgment message from the agent, which creates problems with memory embeddings\. To account for bare\-bones responses, we changed MemoryOS to summarize its actions and tool inputs, better distinguishing memories from one another\.

### 6\.2Memory Snapshot and Utility Test Suite

Each agent is loaded with a memory snapshot constructed from events representing emails, calendar events, and meetings spanning five days, and fed to the agents in chronological order\. We list examples of these inputs in Appendix[C](https://arxiv.org/html/2607.06595#A3)\. Some events were also intentionally designed to change or evolve past events, such as deadline extensions\. Each agent builds their own memory store, saving information on contacts, deadlines, meetings, and emails\. After processing the simulated work week, we saved a snapshot of the memory state for later reuse, allowing each agent to make use of its snapshot during the experiments\.

To analyze the impact of our defenses, a baseline utility needed to be established for each agent, but no existing benchmark is well\-suited to our use case\. The closest are LoCoMo\[[14](https://arxiv.org/html/2607.06595#bib.bib34)\], HotpotQA\[[34](https://arxiv.org/html/2607.06595#bib.bib35)\], and Webshop\[[35](https://arxiv.org/html/2607.06595#bib.bib36)\], but all lack one or more aspects we sought to evaluate\. None of these benchmarks focuses on evolving information, such as changing meeting times or contact information updates\. Additionally, all information comes from a single source, and in the case of LoCoMo and HotpotQA, there are no tool\-based evaluations, while Webshop is not fact\-focused\. A proper evaluation for these types of agents needs to test three things: multiple input sources, tool\-based task evaluation, and events that evolve or change\. To address this, we also constructed an evaluation based on the synthetic workweek\. This allows us to determine the baseline utility and compare it with the utility scores for eachAM\-Sentryconfiguration\. For our evaluation, we defined four categories: recall of static events, recall of evolved \(changed\) events, task execution using static information, and task execution using evolved information\. Based on this, we can get a complete picture on agent utility and the impacts of the proposed defense mechanism\.

## 7Evaluation

### 7\.1Experiment Setup

We ran each agent with four LLM models: GPT\-5\.4\-mini, DeepSeek\-V4\-Flash, Gemini\-2\.5\-Flash, and Llama 3\.1 8B\. For brevity, throughout the remainder of this section, GPT\-5\.4\-mini, DeepSeek\-V4\-Flash, Gemini\-2\.5\-Flash, and Llama\-3\.1\-8B are referred to as ChatGPT, DeepSeek, Gemini, and Llama, respectively, unless otherwise specified\. We set the model temperature to 0\.7, where applicable\. All agents use their default configurations\. We ran all experiments on a workstation with a 13thGen Intel Core i9\-13900K, 128 GB of RAM, and an NVIDIA RTX 4080 \(16 GB VRAM\)\. We host Llama locally via Ollama using the Q4\_K\_M quantization, and we access ChatGPT, DeepSeek, and Gemini through their respective APIs\. We use each provider’s default decoding parameters across all models\. All of our agents use the all\-MiniLM\-L6\-v2 embedding model\[[19](https://arxiv.org/html/2607.06595#bib.bib39)\], while the adversary uses bge\-small\-en\-v1\.5\[[30](https://arxiv.org/html/2607.06595#bib.bib40)\]\. Each experiment was repeated five times to account for random variation unless otherwise noted\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/attack_results_v5.png)Figure 6:GhostWriter’s success results, broken down into memory injection \(P1\) success, attack retrieval success, and attack activation success \(P2\)\.
### 7\.2GhostWriter Analysis

Experiment Design:We created 16 attack scenarios, varying the delivery method between email and calendar invite\. For each test scenario, we used one malicious payload and tested the benign prompt once against agents with no active defense\. Each scenario was tested five times, and we reported the aggregated results\. We also tested two alternatives for each scenario:directive payloads, which have a more direct tone, anddescriptive payloads, which describe false facts or make polite requests\. Examples of each are in Appendix[B](https://arxiv.org/html/2607.06595#A2); we mainly focus on the descriptive payload in this section\. For each attack scenario, the agents’ memories are reset to a snapshot of a five\-day workweek built by each agent, which is free of malicious memories\.

We evaluate Phase 1 \(P1\) and deem the attack successful if the malicious payload is saved in memory\. We also evaluate Phase 2 \(P2\) of the attack, using a benign trigger to determine the malicious memory’sretrieval rateandactivation rateafter retrieval\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/category_heatmap_combined.png)

Figure 7:P2 activation rate \(%\) by category and separated by model and agent\.\\phantomsubcaption

\\phantomsubcaption

Result Analysis:Our results are shown in Figure[6](https://arxiv.org/html/2607.06595#S7.F6), where each bar cluster is organized by LLM model used by the agents, and each bar represents a memory agent architecture\. Memory Injection \(P1\) indicates whether the adversarial payload was stored in memory\. We observed 100% attack success across most agents, with an average of 98% across all agents, regardless of the LLM model used\. The only agents with an attack success rate below 100% were Mem0 and ExpeL, which transform the raw content before saving it\. As a result, attack payloads are not always preserved in memory for those two agents, resulting in lower attack success rates\. We also see that attack retrieval is high across all agents when paired with ChatGPT and DeepSeek, ranging from 79\-100% and averaging around 94% on these models\. Mem0 and Expel tend to have lower attack retrieval rates than the other agents, with rates as low as 57% and 65% for Gemini and Llama, respectively\. This is because Gemini and Llama are less accurate when transforming the input into the memory, reducing the likelihood of matching that attack payload to the targeted benign prompt\.

Attack activation is high across all models, averaging 60% across all agents and LLM models\. ExpeL had the lowest activation rates, ranging from 28% to 63% across all LLMs, making it the least vulnerable agent across models\. This is due to ExpeL’s trajectory\-based memory, which treats memories as prior examples rather than authoritative facts, reducing the likelihood of utilizing malicious or misleading information from poisoned memories\. The only other exception is MemoryOS on Llama, with an activation rate of 42%\. We observed that this agent and model combination struggled to even execute the requested task, as it would request more information or make incorrect tool calls, which naturally led to a lower attack activation rate\. Overall, we see that the attack success rate is highest for ChatGPT and DeepSeek\. Gemini and Llama are the least vulnerable to these attacks, but the attack success rate is still significant, with the lowest being ExpeL paired with Llama at 28%\. Overall, the Llama model has the lowest attack activation rates, while ChatGPT and DeepSeek have the highest\.

We analyzed attack activation across each attack category for both directive and descriptive payloads, as shown in Figures[7](https://arxiv.org/html/2607.06595#S7.F7)and[7](https://arxiv.org/html/2607.06595#S7.F7)\. The heatmaps show the activation rates across four LLMs paired with various agents\. With directive payloads \(Figure[7](https://arxiv.org/html/2607.06595#S7.F7)\), we see that integrity corruption, and covert exfiltration exhibit the highest activation rates, peaking at 100% for ChatGPT, DeepSeek, and Llama\. Conversely, sensitive info leakage shows the lowest overall susceptibility across all LLM models\. Interestingly, for descriptive payloads \(Figure[7](https://arxiv.org/html/2607.06595#S7.F7)\), we see that sensitive info leakage performs actually rates comparable to integrity corruption and covert exfiltration\. Scope escalation activates at much lower rates for descriptive payloads, as this attack requires ignoring the normal bounds set by the user, such as never sending emails without review, and the attack payloads are not presented as strict instructions; the agents are more likely to treat them as optional guidelines to be ignored\. In general, we also see the attack activation rates for descriptive payloads uniformly fall for integrity corruption and covert exfiltration with Llama, whereas in other models they are more varied, with some rising and others falling\.

### 7\.3Prompt Injection Attacks and Defenses\.

We also evaluated the impact of prompt\-injection attacks on these long\-term memory agents\. We reused the experimental setup forGhostWriter, using a prompt\-injection payload from the AgentDojo benchmark\[[4](https://arxiv.org/html/2607.06595#bib.bib3)\]\. Our results are presented in Figure[7](https://arxiv.org/html/2607.06595#S7.F7a), which shows that prompt injection fails almost 100% of the time against most of these agents, except for ExpeL and MemoryOS\. Prompt injection had activation rates of 1\-22% against MemoryOS and 92% against ExpeL\. ExpeL’s trajectory\-based design causes it to almost always follow the directives from the prompt injection attack due to their authoritative nature\. Additionally, we found that while P1 injections rate were very similar toGhostWriter, the P2 activation rates were very low, ranging from 0% to 16\.7%\. This is due to low retrieval rates and the payloads being unoptimized for activation in later prompts\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/agentdojo_pi_only.png)Figure 7:Prompt injection results against all of our evaluated agents\. Notably, ExpeL is very vulnerable to this attack\.We also wanted to determine if prompt injection detection methods would filter outGhostWriterpayloads\. To this end, we ran our directive and descriptive payloads through two prompt\-injection detection methods to evaluate whetherGhostWritercan be detected by them\. We used DataFilter\[[26](https://arxiv.org/html/2607.06595#bib.bib1)\], a Llama model trained to detect prompt\-injection attacks, and PromptArmor\[[21](https://arxiv.org/html/2607.06595#bib.bib2)\], a prompt\-only defense where we used ChatGPT\. We found that DataFilter had a 0% detection rate against all of our attack payloads\. Surprisingly, it was more effective to ask ChatGPT to look for prompt injection, as it actually had an 85% detection rate against our directive payloads, but that fell to only 6% against our descriptive payloads\. We noticed that ChatGPT tends to classify payloads as prompt injection when they use authoritative language, which is why it can reliably detect our directive payloads\. However, our descriptive payloads use more polite language, easily fooling this method, whereasAM\-Sentrycan reliably detect the attack regardless of whether the payloads are directive or descriptive\.

### 7\.4AM\-Sentry Effectiveness

Experiment Design:AM\-Sentryhas defenses at ingestion and at retrieval, so we separated the test for each phase\. For the first\-phase test, we compared the results ofS1S\_\{1\},S2S\_\{2\}, andS3S\_\{3\}to assess their effectiveness\. We also compared against A\-MAC\[[37](https://arxiv.org/html/2607.06595#bib.bib16)\], using its default parameters\. A\-MAC is not focused on vulnerability detection, and any attack payload it blocks is incidental, as its mechanisms only evaluate the utility of saving new memories\. For the second\-phase test, we combine the retrieval screen withS1S\_\{1\},S2S\_\{2\}, andS3S\_\{3\}, and compare the overall results to determine the combined effectiveness of our approach\. We began by generating a new snapshot for eachAM\-Sentrypolicy configuration and reused our adversary setup from Section[7\.2](https://arxiv.org/html/2607.06595#S7.SS2)\. We evaluated our defenses against both directive and descriptive payloads, but for brevity, we discuss only our results against descriptive payloads, which were the hardest to detect\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/defense_p1_blocks_by_policy_v5.png)Figure 8:Memory Saving policy performance; shows the number of malicious memories admitted by each policy into the agents’ memory store\. Overall,S3S\_\{3\}performs best at blocking poisoned memory\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/defense_truep2_by_policy_v5.png)Figure 9:The total attack success rate for each policy configuration when paired with R\. An attack is successful if it activates and alters the agent’s behavior\. Pairing R withS1S\_\{1\}\-S3S\_\{3\}greatly improves their overall performance againstGhostWriter\.Result Analysis:Figure[8](https://arxiv.org/html/2607.06595#S7.F8)shows the effectiveness of our memory saving policies at preventing malicious memory injection\. We first evaluate the A\-MAC baseline, which was optimized solely for utility and does not consider vulnerability\. Compared to our proposed policies, A\-MAC exhibits greater variability across agents and inadvertently permits most attacks\. The minimum attack success rate observed under A\-MAC was 54% with an average of 84%\. The lowest admission rates were under DeepSeek, which tended to score our descriptive payloads very low on utility\.

S1S\_\{1\}admits almost everything under Gemini, but for DeepSeek and ChatGPT, it admits around 80% and 97% respectively\. In contrast, Llama tends to indiscriminately overblock, considering the fact thatS1S\_\{1\}only evaluates if a given memory will be useful or not\. As a result, Llama is prone to filtering both malicious and legitimate payloads, which negatively impacts the agent’s operations\.

S2S\_\{2\}reduces the admission of poisoned memories across all models except Llama\. Notably, while Llama exhibits a lower block rate underS2S\_\{2\}than underS1S\_\{1\}, it’s less prone to blocking legitimate payloads, thereby improving the agent’s overall utility \(detailed analysis in Section[7\.5](https://arxiv.org/html/2607.06595#S7.SS5)\)\. ChatGPT benefits the most fromS2S\_\{2\}, bringing the attack success rate down to 71% at the lowest\. Gemini also benefits significantly fromS2S\_\{2\}’s improved structure, reducing attack success to between 70\-84%\. Conversely, DeepSeek is largely the same, and in some cases worse, because the model tends to rank the utility of our attack email fairly low\.S2S\_\{2\}is consistent across most agents, but performance degrades with A\-Mem and MemoryOS due to their memory structures, makingS2S\_\{2\}more permissive in those agents and reducing its effectiveness\.

S3S\_\{3\}is the most effective and consistent approach for most models\. We observe improved performance across ChatGPT, DeepSeek, and Gemini, reducing the average attack success rate to 15%\. A glaring exception is Llama, which seemed to struggle with the more strict, precise format ofS3S\_\{3\}admitting 77% of malicious payloads\. Overall,S3S\_\{3\}is highly effective in blocking the attack, provided it is paired with a capable LLM model\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/utility_agent_amem.png)Figure 10:Utility metrics for A\-Mem showing the F1\-similarity score, LLM judged scores, and tool accuracy across the baseline, A\-MAC, and all sixAM\-Sentryconfigurations\. Overall,AM\-Sentryhas minimal impact on utility\.We analyzed the total attack success rates when each policy configuration \(S1S\_\{1\}\-S3S\_\{3\}\) is integrated with the retrieval screening \(R\)\. Figure[9](https://arxiv.org/html/2607.06595#S7.F9)shows the end\-to\-end attack success rates under the various policies\. For an attack to be considered successful, it must pass both the policy and the retrieval screen\. In this configuration,S1S\_\{1\}andS2S\_\{2\}exhibit comparable performance\. The addition of the retrieval screen effectively mitigates the inherent permissiveness ofS1S\_\{1\}andS2S\_\{2\}, bringing their performance to a similar level\.S3S\_\{3\}is highly effective in this combined setup, reducing the average attack success rate to below 12% across all LLMs except Llama, which averages 20% across all agents\. We can see thatRwas able to make up for the weakness ofS3S\_\{3\}exhibited under Llama during memory injection\.

### 7\.5AM\-Sentry Utility Analysis

Experiment Design:In addition to evaluating the mitigation’s effectiveness, we also evaluate the impactAM\-Sentryhas on each agent’s utility\. This allows us to better understand the trade\-off between protection and utility\. For each agent across all models, we ran our test suite on the simulated work week to evaluate the agent’s recall and tool\-calling accuracy\. We repeated this evaluation for eachAM\-Sentryconfiguration and for A\-MAC as an additional baseline\. Each configuration created a snapshot based on the simulated work week and its memory\-saving policies\. In this subsection, we focus on A\-Mem and present per\-agent utility for the other agents in Appendix[D](https://arxiv.org/html/2607.06595#A4)\.

Result Analysis:The utility results for A\-Mem are presented in Figure[10](https://arxiv.org/html/2607.06595#S7.F10), which gives the average utility scores for each configuration ofAM\-Sentry, A\-MAC, and the baseline \(no policy\)\. We evaluated three metrics: F1\-similarity score, LLM\-judge score, and tool accuracy\. The F1\-score measures how closely the generated answer matches a reference; the LLM\-judge score uses a ChatGPT model to assess answer accuracy; and tool accuracy measures how often the correct tool call was made\.

F1\-scores remain consistent with the baseline across all LLMs, DeepSeek exhibiting the most consistent performance\. A small reduction underS3S\_\{3\}is observed compared to the baseline, but we determined that this is an acceptable trade\-off for protection\. The remaining models show degraded performance when paired with R orS3S\_\{3\}, ranging from 0\.01 to 0\.04 relative to the baseline\. With Llama, we also observe a stepwise reduction in utility starting atS1S\_\{1\}, due to indiscriminate over\-blocking of legitimate memories\. A\-MAC is a utility\-focused approach, but it did not have a strong positive effect on baseline performance in our experiments; the only exception is Llama, which scores significantly higher than the other policy configurations\. We attribute this to A\-MAC’s policy decisions being less reliant on LLMs, whereas our approach is more reliant on LLMs to score all parameters\.

The LLM judged scores follow the same trend\. Notably,S2S\_\{2\}outperforms the baseline in several cases\. Tool accuracy is likewise consistent, with one exception\. For ChatGPT, we observe a drop\-off under A\-MAC andS1S\_\{1\}relative to the baseline, and accuracy generally increases as the policy configuration becomes more strict\. Notably, our policy configurations have minimal impact on overall utility, a trend that holds across other agent architectures as well, as further detailed in Appendix[D](https://arxiv.org/html/2607.06595#A4)\.

## 8Limitations & Future Work

In this paper, we focused on email and calendar invites as the attack surface\. Other input channels, including documents, web content, and code repositories, were not explored\. As an initial step in investigating this attack vector, our proposed defense relies on intuitively chosen weights in its equations, which may not be the optimal configuration for protecting againstGhostWriter\. Our utility benchmark is a custom test suite built around a simulated workweek rather than real user data or live deployments, and it may not capture the full range of tasks a personal assistant agent encounters in practice\.

Our evaluation covers five state\-of\-the\-art memory agents, but the scope of memory architectures is broader\. Agents with fundamentally different memory designs may exhibit different vulnerability profiles\. We evaluated each agent using multiple models, but we were limited to those available and economically viable for us\. We evaluatedAM\-Sentryagainst non\-adaptive attackers unaware of the defense\. An adaptive attacker may employ techniques to circumvent the policy checklist and retrieval screen\.

From these limitations, we identify the following items for future work\. InvestigatingGhostWriteracross additional input channels and deployment contexts beyond the office assistant setting\. Evaluating a wider range of memory architectures and additional LLM backends\. Developing a dedicated benchmark spanning diverse task types, input sources, and memory architectures\. EvaluatingAM\-Sentryagainst adaptive attackers, performing a Monte Carlo for optimizing selection of policy weights, and attack analysis with multiple concurrent attack payloads\.

## 9Conclusion

In this work, we introduced the novel attack vectorGhostWriterwhich exploits memory systems in tool\-using personal agents and poisons their memory store to steer their future behavior\. We showed that it has near\-universal success against current memory architectures and demonstrates high retrieval and activation rates due to the lack of security\-focused memory governance\. In response to these findings, we also proposedAM\-Sentry, which utilized two mitigation techniques: a memory\-saving policy and a retrieval screen\. We show thatAM\-Sentrycan greatly reduce the effectiveness ofGhostWriter\. The strictest version ofAM\-Sentryalmost completely blocksGhostWriteracross most models in our experiments\. This results in a minimal drop in utility, introducing an acceptable trade\-off between security and utility\.

## References

- \[1\]Anthropic\(2023\)Claude Model Card\.Note:[https://www\.anthropic\.com/model\-card](https://www.anthropic.com/model-card)Accessed: 2026Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[2\]Z\. Chen, Z\. Xiang, C\. Xiao, D\. Song, and B\. Li\(2024\)Agentpoison: Red\-teaming llm agents via poisoning memory or knowledge bases\.Advances in Neural Information Processing Systems37,pp\. 130185–130213\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p5.1),[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p1.1)\.
- \[3\]P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. Yadav\(2025\)Mem0: Building production\-ready ai agents with scalable long\-term memory\.arXiv preprint arXiv:2504\.19413\.Cited by:[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.
- \[4\]E\. Debenedetti, J\. Zhang, M\. Balunovic, L\. Beurer\-Kellner, M\. Fischer, and F\. Tramèr\(2024\)Agentdojo: A dynamic environment to evaluate prompt injection attacks and defenses for llm agents\.Advances in Neural Information Processing Systems37,pp\. 82895–82920\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p6.1),[§7\.3](https://arxiv.org/html/2607.06595#S7.SS3.p1.1)\.
- \[5\]S\. Dong, S\. Xu, P\. He, Y\. Li, J\. Tang, T\. Liu, H\. Liu, and Z\. Xiang\(2025\)Memory Injection Attacks on LLM Agents via Query\-Only Interaction\.arXiv preprint arXiv:2503\.03704\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p5.1),[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p1.1)\.
- \[6\]FBI Internet Crime Complaint Center \(IC3\)\(2024\)Internet Crime Report 2023\.Note:Accessed: 2026\-04\-26External Links:[Link](https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf)Cited by:[§5](https://arxiv.org/html/2607.06595#S5.p1.1)\.
- \[7\]L\. Franceschi\-Bicchierai\(2026\-06\-01\)Hackers hijacked instagram accounts by tricking meta ai support chatbot into granting access\.Note:Accessed: 2026\-06\-05External Links:[Link](https://techcrunch.com/2026/06/01/hackers-hijacked-instagram-accounts-by-tricking-meta-ai-support-chatbot-into-granting-access/)Cited by:[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p1.1)\.
- \[8\]Y\. Gao, Y\. Xiong, X\. Gao, K\. Jia, J\. Pan, Y\. Bi, Y\. Dai, J\. Sun, H\. Wang, H\. Wang,et al\.\(2023\)Retrieval\-augmented generation for large language models: A survey\.arXiv preprint arXiv:2312\.109972\(1\),pp\. 32\.Cited by:[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p1.1)\.
- \[9\]T\. Kagaya, T\. J\. Yuan, Y\. Lou, J\. Karlekar, S\. Pranata, A\. Kinose, K\. Oguri, F\. Wick, and Y\. You\(2024\)Rap: Retrieval\-augmented planning with contextual memory for multimodal llm agents\.arXiv preprint arXiv:2402\.03610\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p2.1),[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p3.1)\.
- \[10\]J\. Kang, M\. Ji, Z\. Zhao, and T\. Bai\(2025\)Memory os of ai agent\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,pp\. 25972–25981\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p2.1),[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p2.1),[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.
- \[11\]B\. Klimt and Y\. Yang\(2004\)The enron corpus: A new dataset for email classification research\.InEuropean conference on machine learning,pp\. 217–226\.Cited by:[§4\.1](https://arxiv.org/html/2607.06595#S4.SS1.p4.10)\.
- \[12\]Letta Team\(2024\)Letta: build and deploy stateful agents\.Note:[https://github\.com/letta\-ai/letta](https://github.com/letta-ai/letta)Formerly MemGPTCited by:[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.
- \[13\]P\. Lewis, E\. Perez, A\. Piktus, F\. Petroni, V\. Karpukhin, N\. Goyal, H\. Küttler, M\. Lewis, W\. Yih, T\. Rocktäschel,et al\.\(2020\)Retrieval\-augmented generation for knowledge\-intensive nlp tasks\.Advances in neural information processing systems33,pp\. 9459–9474\.Cited by:[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p1.1)\.
- \[14\]A\. Maharana, D\. Lee, S\. Tulyakov, M\. Bansal, F\. Barbieri, and Y\. Fang\(2024\)Evaluating very long\-term conversational memory of llm agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 13851–13870\.Cited by:[§6\.2](https://arxiv.org/html/2607.06595#S6.SS2.p2.1)\.
- \[15\]Y\. Nakajima\(2023\)BabyAGI\.Note:[https://github\.com/yoheinakajima/babyagi](https://github.com/yoheinakajima/babyagi)Accessed: 2026Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[16\]OpenAI\(2024\)GPT\-4 Technical Report\.External Links:2303\.08774,[Link](https://arxiv.org/abs/2303.08774)Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p2.1),[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[17\]C\. Packer, V\. Fang, S\. Patil, K\. Lin, S\. Wooders, and J\. Gonzalez\(2023\)MemGPT: towards LLMs as operating systems\.\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p1.1),[§1](https://arxiv.org/html/2607.06595#S1.p2.1),[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p2.1),[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.
- \[18\]J\. S\. Park, J\. O’Brien, C\. J\. Cai, M\. R\. Morris, P\. Liang, and M\. S\. Bernstein\(2023\)Generative agents: Interactive simulacra of human behavior\.InProceedings of the 36th annual acm symposium on user interface software and technology,pp\. 1–22\.Cited by:[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p2.1)\.
- \[19\]N\. Reimers and I\. Gurevych\(2019\)Sentence\-bert: sentence embeddings using siamese bert\-networks\.External Links:1908\.10084,[Link](https://arxiv.org/abs/1908.10084)Cited by:[§4\.1](https://arxiv.org/html/2607.06595#S4.SS1.p4.10),[§7\.1](https://arxiv.org/html/2607.06595#S7.SS1.p1.1)\.
- \[20\]T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, E\. Hambro, L\. Zettlemoyer, N\. Cancedda, and T\. Scialom\(2023\)Toolformer: Language models can teach themselves to use tools\.Advances in neural information processing systems36,pp\. 68539–68551\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p1.1),[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[21\]T\. Shi, K\. Zhu, Z\. Wang, Y\. Jia, W\. Cai, W\. Liang, H\. Wang, H\. Alzahrani, J\. Lu, K\. Kawaguchi,et al\.\(2025\)Promptarmor: Simple yet effective prompt injection defenses\.arXiv preprint arXiv:2507\.15219\.Cited by:[§7\.3](https://arxiv.org/html/2607.06595#S7.SS3.p2.1)\.
- \[22\]N\. Shinn, F\. Cassano, E\. Berman, A\. Gopinath, K\. Narasimhan, and S\. Yao\(2024\)Reflexion: Language agents with verbal reinforcement learning, 2023\.URL https://arxiv\.org/abs/2303\.113668\.Cited by:[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p3.1)\.
- \[23\]Significant Gravitas\(2023\)AutoGPT\.Note:[https://github\.com/Significant\-Gravitas/AutoGPT](https://github.com/Significant-Gravitas/AutoGPT)Accessed: 2026Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[24\]S\. S\. Srivastava and H\. He\(2025\)MemoryGraft: Persistent compromise of LLM agents via poisoned experience retrieval\.arXiv preprint arXiv:2512\.16962\.Cited by:[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p2.1)\.
- \[25\]L\. Wang, C\. Ma, X\. Feng, Z\. Zhang, H\. Yang, J\. Zhang, Z\. Chen, J\. Tang, X\. Chen, Y\. Lin,et al\.\(2024\)A survey on large language model based autonomous agents\.Frontiers of Computer Science18\(6\),pp\. 186345\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p1.1),[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[26\]Y\. Wang, S\. Chen, R\. Alkhudair, B\. Alomair, and D\. Wagner\(2025\)Defending against prompt injection with datafilter\.arXiv preprint arXiv:2510\.19207\.Cited by:[§7\.3](https://arxiv.org/html/2607.06595#S7.SS3.p2.1)\.
- \[27\]Q\. Wei, T\. Yang, Y\. Wang, X\. Li, L\. Li, Z\. Yin, Y\. Zhan, T\. Holz, Z\. Lin, and X\. Wang\(2025\)A\-memguard: A proactive defense framework for llm\-based agent memory\.arXiv preprint arXiv:2510\.02373\.Cited by:[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p3.1)\.
- \[28\]S\. Wu\(2024\-03\)Introducing Devin, the first AI software engineer\.Note:[https://cognition\.ai/blog/introducing\-devin](https://cognition.ai/blog/introducing-devin)Cognition AI Blog\. Accessed: 2025Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p2.1)\.
- \[29\]Z\. Xi, W\. Chen, X\. Guo, W\. He, Y\. Ding, B\. Hong, M\. Zhang, J\. Wang, S\. Jin, E\. Zhou,et al\.\(2025\)The rise and potential of large language model based agents: A survey\.Science China Information Sciences68\(2\),pp\. 121101\.Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[30\]S\. Xiao, Z\. Liu, P\. Zhang, N\. Muennighoff, D\. Lian, and J\. Nie\(2024\)C\-pack: packed resources for general chinese embeddings\.External Links:2309\.07597,[Link](https://arxiv.org/abs/2309.07597)Cited by:[§4\.1](https://arxiv.org/html/2607.06595#S4.SS1.p4.10),[§7\.1](https://arxiv.org/html/2607.06595#S7.SS1.p1.1)\.
- \[31\]T\. Xie, F\. Zhou, Z\. Cheng, P\. Shi, L\. Weng, Y\. Liu, T\. J\. Hua, J\. Zhao, Q\. Liu, C\. Liu,et al\.\(2023\)Openagents: An open platform for language agents in the wild\.arXiv preprint arXiv:2310\.10634\.Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[32\]W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. Zhang\(2025\)A\-mem: Agentic memory for llm agents\.arXiv preprint arXiv:2502\.12110\.Cited by:[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p2.1),[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.
- \[33\]X\. Yang, Y\. He, S\. Ji, B\. Hooi, and J\. S\. Dong\(2026\)Zombie agents: Persistent control of self\-evolving llm agents via self\-reinforcing injections\.arXiv preprint arXiv:2602\.15654\.Cited by:[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p2.1)\.
- \[34\]Z\. Yang, P\. Qi, S\. Zhang, Y\. Bengio, W\. Cohen, R\. Salakhutdinov, and C\. D\. Manning\(2018\)HotpotQA: A dataset for diverse, explainable multi\-hop question answering\.InProceedings of the 2018 conference on empirical methods in natural language processing,pp\. 2369–2380\.Cited by:[§6\.2](https://arxiv.org/html/2607.06595#S6.SS2.p2.1)\.
- \[35\]S\. Yao, H\. Chen, J\. Yang, and K\. Narasimhan\(2022\)Webshop: Towards scalable real\-world web interaction with grounded language agents\.Advances in Neural Information Processing Systems35,pp\. 20744–20757\.Cited by:[§6\.2](https://arxiv.org/html/2607.06595#S6.SS2.p2.1)\.
- \[36\]S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. R\. Narasimhan, and Y\. Cao\(2022\)React: Synergizing reasoning and acting in language models\.InThe eleventh international conference on learning representations,Cited by:[§2\.1](https://arxiv.org/html/2607.06595#S2.SS1.p1.1)\.
- \[37\]G\. Zhang, W\. Jiang, X\. Wang, A\. Behr, K\. Zhao, J\. Friedman, X\. Chu, and A\. Anoun\(2026\)Adaptive Memory Admission Control for LLM Agents\.arXiv preprint arXiv:2603\.04549\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p4.1),[§2\.3](https://arxiv.org/html/2607.06595#S2.SS3.p3.1),[§7\.4](https://arxiv.org/html/2607.06595#S7.SS4.p1.6)\.
- \[38\]A\. Zhao, D\. Huang, Q\. Xu, M\. Lin, Y\. Liu, and G\. Huang\(2024\)Expel: Llm agents are experiential learners\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.38,pp\. 19632–19642\.Cited by:[§1](https://arxiv.org/html/2607.06595#S1.p1.1),[§1](https://arxiv.org/html/2607.06595#S1.p2.1),[§2\.2](https://arxiv.org/html/2607.06595#S2.SS2.p3.1),[§6\.1](https://arxiv.org/html/2607.06595#S6.SS1.p1.1)\.

## Appendix AEthical Considerations

This paper studies security vulnerabilities in personal assistant agents that use long\-term memory\. We formalize and evaluate an attack setup against long\-term\-memory agents from the literature in a controlled environment using synthetic tasks and data; our experiments do not involve real users, sensitive user data, or third\-party systems\. Our evaluation is limited to author\-controlled systems, and we focus on measuring the attack’s impact and developing defenses\. The attack technique could be misused to compromise deployed agents with memory systems, so we also propose and evaluate a practical mitigation that substantially reduces the attack’s effectiveness\. We plan to release our codebase to support reproducibility and further defensive research\.

## Appendix BAdversary Emails

Figures[11](https://arxiv.org/html/2607.06595#A2.F11)and[12](https://arxiv.org/html/2607.06595#A2.F12)show an example of the same attack scenario across two payload variations, directive and descriptive\. Directive payloads use more demanding and authoritative language, while descriptive payloads use more passive and polite language\. While both are effective at driving agent behavior once stored in memory, their activation profiles differ slightly\. The descriptive payloads are more often flagged as benign, while the directive payloads raise more red flags\. All of our 16 scenarios and their variations will be included in our released codebase\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Attack_Email1.png)Figure 11:A directive attack email that uses explicit instructions and autocratic language\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Attack_Email2.png)Figure 12:A descriptive attack email that introduces the malicious contact as a team member\.
## Appendix CSynthetic Work Week

We present five examples of inputs from our simulated workweek in Figures[13](https://arxiv.org/html/2607.06595#A3.F13)through[17](https://arxiv.org/html/2607.06595#A3.F17)\. One email is about team coordination and scheduling a lunch, while the other is a technical discussion on a current issue\. Our workweek consists of 32 events, combining both emails and calendar invites\. All of these events are organized into a timeline of events and fed to the agents in chronological order\. These inputs will be included in our released codebase\.

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Work_Email1.png)Figure 13:An internal email from a colleague coordinating a team lunch\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Work_Email2.png)Figure 14:An email from a developer discussing implementation options for API rate limiting and reporting a pagination bug\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Work_Email4.png)Figure 15:A calendar event for a team lunch\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Work_Email3.png)Figure 16:A calendar update moving the date for a client demo\.![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Work_Email5.png)Figure 17:An announcement notifying the change in location for the daily standup meeting\.
## Appendix DRemaining AM\-Sentry Utility Analysis

![Refer to caption](https://arxiv.org/html/2607.06595v1/Figures/Plots/utility_combined_appendix.png)Figure 18:Utility metrics for Mem0, Letta, Expel, and MemoryOS\. Showcasing the F1 similarity score, LLM judged scores, and tool accuracy across the baseline, A\-MAC, and all sixAM\-Sentryconfigurations\.Figure[18](https://arxiv.org/html/2607.06595#A4.F18)outlines the remaining utility results not included in the main paper\. Overall, the trends align with those seen in A\-Mem with a few notable exceptions\. Llama tends to show much more weakness and variability for these agents\. In particular, MemoryOS shows high variance when paired with Llama, while ExpeL and Letta degrade in performance as we switch between policy configurations\. ExpeL, in general, also seems to suffer as policy configurations grow more strict\.