Your Agent Memory Needs a Quarantine Layer, Not Just a Vector Store

Persistent memory is one of the most seductive features in agentic AI. The demo is easy to love: the assistant remembers your preferences, your team’s vocabulary, the project’s history, the last decision, the exception that mattered, and the small detail you do not want to repeat again. The agent stops feeling like a chat window and starts feeling like a teammate.

That is also the moment memory stops being a convenience feature and becomes infrastructure.

A normal prompt injection tries to influence the model now. Agent memory changes the timeline. If a system stores something from today’s interaction, retrieves it next week, and quietly blends it into the next prompt, then memory has become a durable write path into future reasoning. It is not just context. It is a delayed execution surface.

That framing is the useful takeaway from a new arXiv paper, “InjecMEM: Memory Injection Attack on LLM Agent Memory Systems.” The authors study a memory-injection pattern against LLM agent memory systems: a single interaction plants a record that can later be retrieved under a related topic and steer future responses. The paper’s abstract is careful but uncomfortable. The attack does not require read or edit access to the memory store. It relies on high-recall topical anchors, so the record is likely to be retrieved later, and an adversarial command designed to remain effective when mixed into different future contexts.

For builders, the important lesson is not “never use memory.” It is that an append-only vector store is not a memory system. It is a raw intake bin. Production memory needs a quarantine layer before any stored item earns the right to influence future actions.

OWASP already treats prompt injection as a top GenAI risk, including indirect prompt injection through external or user-provided content. Persistent agent memory turns that risk into something more operationally awkward: the malicious or misleading content can outlive the session in which it arrived. It can sit dormant until the retrieval system decides it is relevant. A support agent might remember a customer-specific “exception.” A sales agent might remember a pricing instruction. A coding agent might remember a local convention. A clinical workflow assistant might remember a preference that should have expired when the task ended.

In each case, the failure is not only that bad text got stored. The failure is that the system treated storage as trust.

A quarantine layer starts by separating raw memory from promoted memory. Raw memory is what the agent observed: a user statement, a tool result, a document fragment, a preference, a correction, or a workflow note. Promoted memory is what the system is allowed to retrieve into high-trust prompts or use when taking action. Those two states should not be the same.

The first control is provenance. Every memory should carry who or what created it, when it was created, which session produced it, what task it belonged to, and whether it came from a user, tool, document, model summary, or automated extraction. “The system remembered X” is not enough. The system needs to know whether X came from an authenticated admin, a one-time external page, an unauthenticated form field, or a model’s own summary of a noisy transcript.

The second control is scope. A memory about one patient, customer, repository, ticket, or tenant should not become a global operating rule. A memory about a brainstorming session should not become a billing policy. A memory about a temporary workaround should not become a permanent exception. Scope should be explicit, narrow by default, and visible at retrieval time.

The third control is promotion. New memory should pass through a gate before it is trusted. Some memories can be auto-promoted because they are low-risk preferences: “use concise status updates” or “prefer weekly rollups.” Others should require confirmation, corroboration, or an administrative source: pricing terms, compliance exceptions, permissions, clinical facts, credentials, or anything that changes how the agent acts. The gate does not need to be bureaucratic. It does need to exist.

The fourth control is retrieval-time conflict checking. Even promoted memory should not be treated as final truth. When the retriever pulls a memory into context, the orchestrator should ask simple questions: Does this conflict with current policy? Is it stale? Does it come from a lower-authority source than the current instruction? Is it trying to change tool-use behavior, access boundaries, or output requirements? If so, the memory should be demoted, ignored, or escalated rather than silently blended into the prompt.

The fifth control is decay. Memory that never expires becomes policy by accident. Enterprises already understand retention windows for logs, documents, and records. Agent memory needs the same discipline. Some entries should expire quickly. Some should require revalidation. Some should be revocable by a user or operator. Some should remain available for audit but no longer eligible for retrieval into active reasoning.

Finally, memory needs tests that match the risk. Do not only test whether the agent can remember useful facts. Test whether one interaction can change later behavior in an unrelated or semi-related session. Test whether targeted memories remain confined to their intended scope. Test whether poisoned or low-authority memories can be found, explained, and retired. Test whether non-target tasks stay normal when a suspicious memory exists nearby.

This is where the NIST AI Risk Management Framework’s verbs become practical: govern, map, measure, and manage. Govern who can create durable memory. Map where memories flow into prompts and tools. Measure whether retrieval changes behavior in unacceptable ways. Manage promotion, expiry, rollback, and incident response. Anthropic’s guidance on effective agents also points in the same direction: reliable agent systems tend to use clear workflows, boundaries, and orchestration rather than opaque autonomy. Memory should be part of that architecture, not an invisible side channel.

The teams most at risk are not the ones ignoring memory. They are the ones adopting it casually because it makes demos better. In production, memory is too powerful to be a hidden cache and too persistent to be treated like ordinary context. It deserves the same design attention as credentials, tool permissions, audit logs, and release gates.

A useful rule of thumb is simple: if a memory can influence a future action, it should have a lifecycle. Intake. Quarantine. Provenance. Scope. Promotion. Retrieval check. Expiry. Revocation. Audit.

The agent that remembers everything is not automatically more trustworthy. The trustworthy agent is the one that can explain why a memory was allowed into the room in the first place.