Memory Poisoning: When AI Agent Memory Becomes a Security Boundary

Application security has spent two decades refining a single question: what can this system execute? Input validation, sandboxing, least privilege, and memory-safe languages are all answers to that question in different registers. Agentic systems do not remove it, but they add a second one that traditional controls were never designed to answer: what is this agent allowed to trust?

The distinction matters because an agent's behaviour is not determined solely by the code it runs, but by the content that reaches its reasoning context when a decision is made. When that content is durable — stored between turns, between sessions, sometimes between users — trust stops being a per-request concern and becomes a property of a stateful system.

Persistent state is not a cache

Agent frameworks have converged on some form of long-lived memory. Implementations differ — vector stores of prior interactions, user preference records, summarised session histories, scratchpads shared across a multi-agent graph — but the function is consistent. The agent writes something now so that a future instance of itself, or of another agent, can retrieve it later.

It is tempting to treat this store as a cache: an optimisation, derived from a source of truth, discardable without consequence. The analogy breaks down immediately. A cache returns data to a program that acts on it according to fixed logic. Agent memory returns data into a reasoning process whose logic is not fixed, and which treats the retrieved content as context rather than as untrusted input. The entry does not merely inform the decision; often it is the decision, restated.

Once that is true, memory is not an optimisation layer. It is a control surface, and it sits on the path between an attacker and a privileged action.

The threat model

The threat model assumes an attacker who cannot directly invoke the agent's privileged tools and cannot modify its code, but who can influence content that the agent may ingest — a document, a web page, an email, a ticket, a repository file, a response from a third-party service, or the output of another agent in the same workflow. The attacker's objective is not to trigger an action during the interaction in which the content is encountered. It is to influence what the agent stores.

The attractive property, from an adversarial point of view, is separation in time. If the malicious content is written into memory during an unremarkable session, it can lie dormant. It is then recalled later, in a different session, under a different prompt, possibly for a different user, and it arrives already framed as something the agent previously learned. Content the agent wrote itself carries an implicit authority that content arriving from an external source does not.

The payload need not look like an instruction. A subtly incorrect fact, a preference that was never expressed, a stored claim that a particular endpoint is internal and trusted, a summarised procedure with one altered step — each is a plausible entry and each biases a later decision. We investigate this as a state-integrity problem rather than a prompt-injection variant, because the defensive question is not how the content was phrased but how it acquired standing.

Dimensions of the problem

Discussion of memory security tends to collapse into one question: is this entry malicious? That framing is too coarse to build controls from. We find it more useful to decompose the problem into dimensions that can each be instrumented and enforced separately.

Provenance

Where the content originated. Whether an entry came from a user statement, a tool result, a retrieved document, another agent, or the model's own generation — and whether that origin is still recoverable at the moment the entry is recalled.

Trust

What standing the entry is granted once retrieved. Whether stored content is treated as fact, as a hypothesis, or as untrusted input requiring the same scrutiny as any external data.

Integrity

Whether the entry is still what was written. Whether it can be detected as altered, and whether a chain exists linking the stored content to the event that produced it.

Persistence

How long the entry survives, and under what conditions. A short-lived working note and a permanent user profile carry different risk even when their content is identical.

Scope

Which agents, sessions, workflows, and tenants can read the entry. Memory that is written in one context and readable in another creates a lateral path that does not appear in any network diagram.

Authorisation

Who or what was permitted to write the entry, and who is permitted to recall it. Write authorisation and recall authorisation are distinct decisions and are frequently conflated.

Mutation

How an existing entry may be updated, merged, summarised, or overwritten. Consolidation processes that rewrite older entries can quietly launder the provenance of the content they absorb.

Expiration

Whether the entry has a defined end of life, and whether expiry is enforced by the runtime rather than left to the agent's discretion.

Observability

Whether memory writes, recalls, mutations, and expiries emit telemetry at all — with enough context to reconstruct which entry influenced which action.

Behavioural impact

What measurable change in agent behaviour a given entry produces. Without this, there is no way to distinguish an inert stored note from one that is steering privileged tool calls.

Why this is a blind spot for the SOC

Security operations is organised around the detection of execution and communication. Process creation, authentication events, command lines, network flows, file writes on endpoints, API calls against cloud control planes — these are the substrates on which detection engineering has been built, and they are well covered. Memory poisoning produces almost nothing on any of them.

Three properties make this hard operationally. The first is temporal separation: the write and the resulting harmful action can be days or weeks apart, beyond the correlation windows most detection content uses and often beyond the retention of the logs that would connect them. The second is contextual separation: the write may occur in one session or tenant and the effect in another, so the two events share no session identifier, user, or source address to correlate on. The third, and most consequential, is that the telemetry frequently does not exist. Many runtimes log model calls and tool invocations while treating memory reads and writes as internal implementation detail. There is no event to correlate because nothing was recorded.

The practical consequence is that an analyst investigating an agent's harmful action can usually see that a tool was called and can often see the prompt that preceded it, but cannot answer the question that actually matters: why did the agent believe that was the right thing to do, and where did that belief come from?

Treating memory operations as security events

The first defensive step is unglamorous and mostly an engineering exercise: make memory operations observable. A memory write is a state change to a system that influences privileged behaviour — the same category of event as a change to an IAM policy or a scheduled task, and deserving comparable treatment.

• Emit a structured event for every memory write, recall, mutation, and expiry, with a stable identifier for the entry so that its lifecycle can be reconstructed.
• Record provenance at write time. Provenance cannot be reliably reconstructed afterwards, so if it is not captured at the moment of the write it is gone.
• Carry the entry identifier through to the tool-call telemetry, so that an action can be traced back to the entries that were in context when it was taken.
• Retain memory telemetry over windows appropriate to persistent state rather than to session-scoped logs.
• Monitor for behavioural drift: changes in an agent's decisions or tool usage that persist across sessions and do not correspond to a change in code, prompt, or configuration.

Defensive directions

Beyond observability, the controls we consider most promising share one idea: the security decision belongs at recall time, not only at write time. Filtering on the way in is worth doing, but it assumes the filter can recognise malicious content in advance — precisely the assumption that fails against subtle, plausible entries. A recall-time decision knows what the entry is about to be used for.

• Evaluate policy when an entry is retrieved, using its provenance, age, scope, and the sensitivity of the operation it is about to influence.
• Enforce scope and tenant isolation in the memory store itself rather than relying on retrieval queries to stay within bounds.
• Apply time-to-live and enforced expiry, so that a dormant entry does not remain available indefinitely.
• Constrain mutation: define which processes may rewrite, merge, or summarise existing entries, and preserve provenance across those operations rather than flattening it.
• Separate write authorisation from recall authorisation, and treat elevation between the two as an explicit decision.
• Require human approval where a high-risk recall would influence a privileged tool call, rather than gating the tool call alone.
• Degrade gracefully: where an entry's provenance is unknown or its trust level is insufficient, prefer proceeding without it over proceeding with it.

None of these is exotic. They are data governance controls applied to a store that has not historically been governed, and their difficulty is architectural rather than conceptual — most agent runtimes offer no place to put them.

Mapping to public frameworks

Practitioners rarely have the freedom to describe a new problem in entirely new terms. Findings have to be communicated to risk functions, auditors, and detection engineers who work from shared references. Two public bodies of work are commonly used as the anchor points for this class of problem: MITRE ATLAS, which catalogues adversarial behaviour against machine learning and AI systems in a structure familiar to teams already working from ATT&CK, and OWASP's work on the security of large language model applications and agentic systems, which is more often used to frame risk categories for application and platform teams.

We reference both as the frameworks organisations map against, deliberately without asserting a particular identifier or category number. Both are actively maintained and their contents change, and the mapping is in any case something each organisation should perform against the version it has adopted.

Where this leaves the practitioner

The useful reframing is that persistent agent memory is a security boundary. Content crosses into it, acquires standing there, and crosses back out into a reasoning process with tool access. Anywhere else, a boundary of that shape would carry provenance, authorisation, retention rules, and an audit trail as a matter of course. In most agent deployments it carries none of them.

That gap is the substance of the problem, and it is more tractable than it appears. It does not require solving the open question of model robustness against adversarial text. It requires deciding, explicitly and in the runtime, what an agent is allowed to trust.