AIVAX
Console
All posts

Persistent memory is a write path, not a notebook

An agent that writes its own memory gains a second input channel that outlives the session. Recent poisoning research shows why that channel needs ownership, expiry, and review — and how AIVAX scopes it.

By AIVAX Labs

A weathered wall of card-catalog drawers with blank brass label plates, one drawer half-open with a slipped card tied by a single red thread to a small brass desk lamp

A support agent that remembers a customer's plan tier is personalization. The same agent, three weeks later, applying an approval threshold nobody can find in policy — because it once wrote that threshold into its own memory — is an incident. The mechanism is identical in both cases: something said or inferred in one conversation was stored, survived the session, and re-entered a later decision as trusted context.

That is the shift persistent memory introduces. A prompt is an input you inspect on the way in. Memory is a write path: entries are created during ordinary operation, persist across sessions, and are retrieved by similarity rather than by review. Every write is a small policy decision made at runtime, by a model, about what future invocations should treat as true. When teams add memory to get continuity, they also inherit that write path — whether or not they designed for it.

Recent research makes the cost of ignoring it concrete. In Temporal Dynamics of Memory Poisoning in Web3-Style LLM Agents (IEEE Access, vol. 14, 2026), Yazdinejad and Karimipour built a dataset of 2,614 simulated multi-step attack trajectories against memory-enabled agents and studied four attack types: chain poisoning, policy rewriting, backdoor triggering, and slow drift. Their finding, as the authors summarize, is that slow-drift and backdoor-trigger attacks were difficult to distinguish from normal behavior through most of an interaction and became apparent only later — evading evaluations that judged individual steps in isolation. Some attacks were also non-monotonic: behavior looked more concerning at one checkpoint, less at the next, and worse again later. So the security check has to span trajectories too: checking one prompt at a time can miss an attack whose write and whose effect are separated by days of normal operation.

That places memory squarely in the industry's agentic risk catalog. OWASP's Top 10 for Agentic Applications (2026) lists memory and context poisoning among the critical risks for systems that plan and act across workflows, and its AI Agent Security Cheat Sheet treats memory and context security as a distinct control area: what the system carries forward needs protection, not just the prompt in front of it.

The write path has four properties worth naming

Memory poisoning is not one bug; it is what happens when four properties of the write path go ungoverned:

  1. Writes happen at runtime, by the model. A memory entry can originate from user text, retrieved documents, tool output, or the model's own inference. The entry that poisons a future decision may have been written weeks before it is read, in a session nobody remembers.
  2. Reads are by similarity, not by review. Stored entries re-enter the prompt because they resemble the current context — not because anyone approved them for this decision. A misleading sentence filed under "preferences" can surface inside a task that touches authorization.
  3. Effect is delayed. The write and the consequence live in different sessions. Step-level evaluation sees a normal write on Tuesday and a normal-looking read three weeks later; neither step alone looks like an attack.
  4. Persistence outlives the conversation that created it. Until an entry expires or is deleted, every future session that retrieves it inherits the assumption.

Prompt injection ends when the conversation closes. A poisoned memory survives it — as recent coverage has put it, "poison once, exploit forever." That is why the fix is not a better prompt filter at the front door. It is governance of the write path itself: who may write, what scope the entry carries, how long it lives, and who can inspect and remove it.

How AIVAX scopes the write path

AIVAX Memories are persisted, user-specific facts a gateway can carry across conversations — preferences, known facts, reminders — backed by an explicit record with an owner, an expiry, and a scope. The design treats each of the four properties above as an operational control rather than a model behavior:

Writes are explicit operations, not ambient accumulation. The model writes through dedicated functions (memory_save, memory_update, memory_remove, memory_clear), each scoped to the calling gateway. Entries are capped at 10 KB with a retention window of 1–365 days (30 by default). A memory entry requires a session bound to an external user reference ID; without that identity, the write is refused. The API surface mirrors this: list, inspect, and delete memories per gateway, plus a 'shared' filter for entries with no gateway link.

Reads are bounded and attributable. On each inference, stored entries for that user and gateway scope are injected as a labeled User memory context block (serialized as structured data, carrying each entry's ID) with an explicit instruction to prioritize recent information and respect privacy. At most 10 entries are injected by default; when more exist, the prompt says so and points the model at memory_search for the rest, rather than silently truncating. Date-based reminders get their own block, filtered to a relevance window of 1.5 days back and 3 days forward. Because every injected item carries its ID, a suspicious assumption in the output can be traced back to the entry that supplied it.

Scope limits blast radius. Each entry is either linked to one gateway or shared. Gateway-scoped reads, writes, updates, and deletes are filtered by that scope, so a memory written through one gateway does not silently steer another gateway's decisions unless it was deliberately shared. The listing API exposes the link per entry, so operators can audit which gateway owns what the model remembers.

Expiry and deletion are first-class. Entries expire automatically (30 days unless the writer sets another retention), and both the model functions and the management API can delete individual entries or clear a user's memories entirely. A poisoned entry, once found, is removable through the same surface that created it; it does not require a model change or a redeploy.

None of this makes memory safe by default. A gateway that lets its model write freely, shares everything, and never reviews still inherits the full write-path risk. The scoping gives operators a concrete way to say no: this gateway writes gateway-scoped entries with 30-day expiry, reads at most 10 per turn, keeps reminders in a dated window, and lists every entry with its owner for review.

Operate memory like a data store with a model attached

Four practices follow directly:

  • Default to gateway scope. Shared memory is cross-application influence by design. Keep entries gateway-scoped unless a specific personalization case requires sharing, and review the shared set on a schedule.
  • Set retention from the data, not the default. A plan tier that changes quarterly should not carry a 365-day memory. Match expiry to how fast the underlying fact can go stale — and remember that stale is a milder form of poisoned.
  • Review the write log the way you review access logs. The listing API shows what was stored, for whom, under which gateway, and when it expires. A memory nobody can enumerate is a memory nobody governs.
  • Test across the delay, not just the step. The poisoning research argues for trajectory-aware evaluation: follow behavior across interactions rather than judging each step alone. The same trajectory vocabulary used for monitoring conversations applies here — a memory whose retrieval correlates with drifting outcomes is evidence, even when the write looked benign.

Memory turns an agent from a function of the current input into a function of its own history. That is where the product value lives: continuity, preferences, follow-through across sessions. It is also where a second, quieter input channel opens: one that is written at runtime, read by similarity, and patient enough to wait weeks between the write and the consequence. Govern the write path with the same seriousness as the prompt path — ownership, scope, expiry, review — and memory stays personalization. Leave it ungoverned, and it becomes whoever wrote to it last.

References