An Agent's Memory Is Persistent, Attacker-Writable State.

Prompt injection is usually described as a problem with a lifespan. An attacker plants instructions in something the agent reads, the agent misbehaves, the session ends, and the damage ends with it. Long-term memory removes that last clause. The moment an agent can write notes to itself that survive the session — user preferences, facts about a task, summaries of earlier work, lessons it decided were worth keeping — the context window stops being the boundary of the attack.

Memory is a database. It is written by a process that reads untrusted text, and it is read later by a process that treats the contents as the agent's own knowledge. That is the textbook shape of a stored-injection flaw, and it deserves the discipline you would apply to any other store of attacker-influenced data.

Memory changes the threat model

Without memory, an agent's context is rebuilt for every session from a short list of inputs: the system prompt, the current user's request, and whatever tools return. An injected instruction therefore has a lifetime of one session and a blast radius equal to what that session is allowed to do.

With memory there are two new paths. The write path is the decision about what is worth remembering, and it is frequently made by the model itself, on the basis of content it has just read: a web page, an email, a shared document, a tool result, another agent's message. The read path is the retrieval step at the start of a later session, which places relevant records into context in a framing that says, in effect, this is what you already know. The model has no native way to tell a fact the user stated from a sentence a page contained that it later summarised into a note.

Two properties follow. The first is persistence: the payload survives the session that planted it. The second is a trust upgrade. Content that was visibly third-party when it was ingested is stored without its origin and returns as the agent's own prior knowledge. An instruction inside a retrieved page at least arrives marked as outside material. The same instruction rewritten as a memory — a standing preference about where reports should be sent, say — arrives as settled fact.

Stored injection outlives the session

The attack has three stages, separated in both time and privilege. In the plant stage, attacker-controlled content reaches the agent during some session. In the persist stage, the agent writes a record, either because its own memory logic judged the content worth keeping or because the injected text simply told it to remember something. In the trigger stage, a later session retrieves that record because it is relevant to a new task, and the model acts on it with the privileges of that later session.

That separation is what makes the pattern dangerous. The session that planted the record may have been low-stakes — summarising a page, triaging an inbox — while the session that triggers it may hold far broader authority. The attacker never has to be present at trigger time, and the evidence is hard to find: the later session's logs show an agent acting on its own memory, with no hostile input in sight. Prompt injection has not gone away. It has gained a time delay and lost its fingerprints.

Summarisation makes this worse, not better. A summariser that reads attacker text will often carry the instruction through, sometimes verbatim, sometimes paraphrased into a standing preference or a lesson learned. Paraphrase defeats any string matching applied to the original input, and consolidation jobs that merge records can fold a low-trust note into a summary alongside legitimate ones, erasing per-record provenance. As with prompt injection generally, nothing inside the model reliably separates instructions from data, so filtering at ingestion is not a control on its own.

Cross-user contamination

Persistence across sessions is the first widening of the blast radius. Sharing is the second. Memory is frequently scoped more loosely than the people using it assume: per deployment rather than per user, per workspace rather than per task, per agent persona rather than per principal. Wherever a store is shared, a record planted through one user's session can be recalled in another's, and the second user inherits a behaviour that neither they nor the first user ever authorised.

The question to ask is not whether the database is encrypted or access-controlled — it usually is — but whose authority a recalled record carries when the model acts on it. A record written under a low-privilege identity should never be able to steer an action taken under a high-privilege one. Recall is where that boundary has to be enforced, because the database cannot see what the model will do with the text.

What should never enter memory

The cheapest control is the most neglected: decide in advance what the memory is for, and refuse to store anything outside that remit. A memory built from typed fields and short enumerated values is a far smaller attack surface than a free-text scratchpad: a field that can only hold a language code cannot hold an instruction.

• Instructions — Records phrased as commands, policies, or standing rules about agent behaviour are the payload format of this attack. If a behaviour change matters, it belongs in reviewed configuration, not in a note the model wrote about itself.
• Credentials and secrets — Tokens, keys, and passwords that pass through a session must not become recallable text that a later session, or an attacker steering one, can ask for.
• Untrusted content, verbatim — Raw excerpts of pages, emails, and third-party documents carry their instructions with them. Store the fact you need, with its source, not the surrounding prose.
• Authority claims — Statements such as "this user is an administrator" or "approvals are pre-granted" are exactly what an attacker wants remembered. Authority comes from the identity layer, never from recall.

A memory store is where today's untrusted input becomes tomorrow's trusted instruction, and the write is the only point at which you still know the difference.

Scope, expire, and tag provenance

Then bound where and for how long a record applies. Scope every record to the narrowest principal that makes the feature work: a user and, within that user, a task or workspace, rather than an agent-wide or organisation-wide pool. A record should be retrievable only by sessions running under the identity and purpose it was written for, and that filter should be a deterministic query condition, not a request to the model to ignore irrelevant memories.

Give every record an expiry. Time-to-live limits are crude, but they turn a permanent compromise into a temporary one. Pair that with provenance: each record carries a tag for where it came from — user statement, tool result, retrieved document, another agent — and the trust level of that source at the time. Provenance has to survive summarisation, which means consolidation jobs must either preserve the weakest source tag among their inputs or refuse to merge across trust levels. Log every recall that influenced an action, with the record identifiers it used; without that link, a poisoned memory is indistinguishable from the model simply behaving oddly.

A defensible memory design

Treat recall as untrusted input. The read side must assume some bad record is already in the store. Retrieved memories belong in a clearly delimited, lower-trust part of the context: they inform the model's answers, but they do not authorise tool calls. Any consequential action — sending data out, spending money, changing a permission — is decided by deterministic policy outside the model, against the current user's identity and task, regardless of what the agent remembers.

A sound design therefore comes down to a narrow schema, validation and scoping on write, isolation on read, expiry and provenance on every record, and a policy layer that never takes instructions from recall. Together they turn memory from an implicit trust grant into an ordinary, auditable datastore. When 6QURE reviews an agentic system, memory is one of the first places the hours go: tracing what the agent is allowed to write, who else can read it, how long it lives, and what an attacker who planted a single record could make a later session do with the privileges it holds at that point.