Attributed Memory
Store what an agent remembers as records that carry their origin, an owner who can remove them, and a lifetime — never as an anonymous blob of text. Memory is what turns a one-shot attack into one that re-triggers on future, unrelated tasks; attribution is what makes that reversible.
Definition
Attributed memory is the practice of writing every persistent agent memory as a record with its provenance (where the claim came from and whose authority it carried), a named owner who can delete it, and an expiry — so a false fact can be traced, removed and, failing that, dies on its own.
Problem
An agent that writes free text into persistent memory cannot tell later which of its memories it was told, which it read from a stranger's web page, and which it inferred. One poisoned write then reappears as trusted context in tasks that have nothing to do with the conversation that planted it.
When to use it
Use it wherever memory outlives the session that created it: assistants that remember preferences, agents that accumulate project state, any retrieval store the agent itself writes to. The longer the retention and the more of the corpus the agent authored, the more the memory needs to be a record store rather than a notebook.
Solution
Refuse anonymous writes. Every record carries where the claim came from — the session and turn, the tool or document, and the URL if it came from outside — as structured fields, not as a sentence inside the text.
Record whose authority the claim carried. A fact the operator configured, one the end user asserted, and one the agent read on a third-party page are three different claims; keep the class explicit so the retrieval path can weight them and a reviewer can sort them.
Give every record a lifetime, and make the default short. Memory that never expires is memory nobody will ever review, and it is the half-life of a poisoned write that decides how long an attack keeps paying.
Make removal a first-class operation with a named owner, and make it propagate. Deleting the record is not enough if the claim survives in an embedding, a cached summary or a derived profile.
Treat the write path as an action. Memory writes change future behaviour, so they go through the same authorisation and logging as any other write — not through a side door because the destination happens to be a file.
Never let retrieved memory re-enter the prompt as instruction. It arrives as data with an origin attached, and a record whose origin is a third party is treated exactly as untrusted input from that party.
Components
Benefits
- Makes memory poisoning reversible: you can find the write, see where it came from and remove everything derived from it.
- Turns 'what does this agent believe about me?' into a question with an answer a person can read.
- Lets retrieval weight a claim by its origin rather than by how confidently the text was written.
- Satisfies the retention and erasure obligations that apply to anything persisted about a person, without a separate mechanism bolted on later.
Risks
- Provenance theatre: an origin field that always says 'agent', which documents nothing and looks like a control.
- Compaction laundering — the most common way attribution dies. Summarising ten attributed records into one paragraph produces an unattributed claim that now looks like consensus.
- Partial deletion: the primary record goes, the vector stays, and the claim keeps being retrieved.
- Over-expiry destroying the continuity the memory existed for, which pushes people to disable expiry entirely.
When not to use it
- Single-session agents with no persistence: there is no memory to attribute, and the ceremony buys nothing.
- When the store is a cache of your own already-governed system of record — attribute the source system once, not every derived row.
- When the overhead would push operators to keep the real notes outside the system, which is strictly worse than an imperfect record inside it.
Technologies
Examples
- An assistant that writes 'prefers metric units'. The record carries the session id and the turn where the user said it, so a wrong preference can be traced to the sentence that caused it and removed.
- A research agent that reads a third-party page and stores a claim tagged 'observed at that URL, on that date', never as a fact. When the same claim is retrieved months later, its origin travels with it.
- A support agent whose memory records expire in 90 days by default, with a longer lifetime only for entries a human explicitly confirmed — so the unreviewed majority ages out and the reviewed minority persists.
KPIs
- Attributed write share
- Share of memory records carrying a machine-readable origin. Below 100% the store cannot answer where a claim came from, which is the whole control.
- Median record age
- How old the memory in play actually is. A rising median with no removals means the store is accumulating rather than being curated.
- Deletion propagation lag
- Time between removing a record and the claim stopping being retrievable from every derived artefact. The window in which a deleted claim still acts.
- Expired-on-schedule share
- Share of records that reached their expiry and were actually removed. Evidence the lifetime is real rather than declared.
Observed failure modes
- Delayed-action poisoning: a false fact planted in one conversation surfaces in an unrelated task weeks later, where nothing in the context explains why the agent believes it.
- Summary survival: the record is deleted, the compacted summary that absorbed it is not, and the claim outlives its own source.
- Shadow index: the embedding of a removed record stays searchable, so the delete succeeded everywhere the auditor looked and nowhere it mattered.
- Identity bleed: memory keyed loosely enough that one user's record is retrieved for another, turning a memory design flaw into a disclosure.
Lessons learned
- Attribution is cheap at write time and impossible to reconstruct later. The field has to exist before the claim does.
- Every compaction step is an attribution boundary. If the summariser cannot carry origins forward, it is producing new unsourced claims.
- An expiry nobody has ever seen fire is a policy, not a control.
- Deletion is only as complete as the derived artefact you forgot about.
FAQs
- Isn't this just retention policy with extra steps?
- Retention answers when data goes. Attribution answers where a claim came from and who may remove it, which is what you need the moment a memory turns out to be wrong rather than merely old. The two are complementary: without expiry, attribution accumulates; without attribution, expiry deletes evidence you never understood.
- The agent writes its own memories. Whose authority do those carry?
- Its own, and that is the class worth naming. An agent-inferred claim is weaker than an operator-configured one and should be retrievable as such — otherwise the model's own guesses come back later indistinguishable from configuration.
- How do we keep provenance through summarisation?
- Either the summary carries the union of its sources' origins, or it is written as a new agent-inferred record pointing at the ones it replaced. What cannot happen is the summary quietly becoming an unsourced fact, because that is the step where poisoning becomes permanent.