Persistent Memory Write Attribution Logging

Persistent memory write attribution logging records every write, edit, promotion, or deletion in a synthetic subject’s memory as a first-class audit event. The detection ensures that memory records acted on in later sessions can be traced back to the source content, session, user, tool, and identity that created or changed them.

 

Implementation

Instrument all memory-write paths, including in-session memory, per-user memory, shared memory, agent memory, workflow memory, vector-store-backed memory, and persistent cross-session memory. Log each memory event before the record becomes available for future context assembly or retrieval.

 

Each memory-write record should capture the memory record identifier, action type, timestamp, synthetic subject identifier, session identifier, task identifier, user identity, bound human principal where applicable, non-human identity used, tool or connector involved, approval state, and memory scope. The record should also capture origin provenance: the conversational turn, source query, retrieved document, tool result, uploaded file, external content, or workflow event from which the memory content was derived.

 

Where memory is promoted from temporary context into persistent storage, record the promotion event separately. The log should preserve the original source, the actor that approved or triggered promotion, the memory text or hash, prior version, new version, tenant or user scope, and any source-provenance tags carried forward.

 

Alert when a memory record is written without an attributable session, user, source, or valid workflow origin; when a tool or connector writes memory outside its approved scope; when memory is promoted into persistent storage without approval or provenance; when cross-session memory lacks an originating principal; or when a later clean session acts on memory whose source traces to an unrelated prior session, user, tool, or low-trust content.

 

Investigative Use

This detection supports investigation of memory poisoning, memory-resident invocation, delayed invocation, cross-user memory influence, and persistent behavioral drift. It helps investigators determine who or what wrote a memory record, what source material it came from, when it became persistent, and whether later behavior can be traced back to that earlier write.

 

It is especially useful where the current prompt appears benign, but the synthetic subject acts on a memory record planted, induced, rewritten, or promoted during an earlier session.

Sections

ID Name Description
CF005Persistent Memory Access

Persistent memory access is the configuration that allows a synthetic subject to store, retrieve, or act on durable memory across sessions, users, tasks, or workflows. This may include long-term memory, shared memory, user memory, vector memory, profile memory, task state, scratchpads, or context stores.

 

This configuration creates an elevated exposure condition because stored memory can influence future behavior after the original interaction has ended. If memory writes are not governed, attributed, reviewed, isolated, or time-limited, a synthetic subject may later act on false assumptions, malicious instructions, sensitive records, or outdated context.

 

The primary risk is memory poisoning. A user, external content source, compromised integration, or prior agent interaction may cause harmful content to be written into memory. That memory may then be retrieved in a later session and influence the synthetic subject’s reasoning, output, tool use, or treatment of another user.

 

A related risk is cross-user memory influence. If memory is not isolated by user, tenant, role, or workflow, content introduced through one interaction may affect another person’s future interaction. This may cause unauthorized personalization, data exposure, misleading recommendations, or actions based on context the later user never supplied.

 

Investigators should review memory write paths, stored memory entries, source prompts, provenance tags, identity records, retrieval logs, retention settings, isolation controls, and memory-driven outputs. Particular attention should be given to unexplained memory entries, progressively shortened or innocuous-looking records, cross-user influence, and behavior not justified by the current prompt or retrieved context.

 

Investigative Relevance

Persistent memory access is relevant because memory can become a durable configuration surface that shapes future synthetic subject behavior. Unlike transient prompt context, persistent memory may survive across sessions and continue influencing outputs after the original source is no longer visible.

 

This section is especially relevant where synthetic subjects use long-term memory, shared memory, user profiles, vector stores, task scratchpads, reusable summaries, or context stores that can be written by users, agents, tools, or retrieved content.

IV006Memory-Resident Invocation

Memory-resident invocation occurs when a malicious, false, or instruction-bearing record written into persistent memory causes a synthetic subject to act in a later session. The current session may appear clean, while the effective instruction is retrieved from memory that was written earlier.

 

This invocation creates an elevated exposure condition because the triggering record can persist across time and, depending on memory isolation, across users. A prior user, external content source, compromised workflow, or earlier synthetic subject interaction may cause a memory entry to be stored, then a later unrelated user may trigger behavior shaped by that record.

 

The primary risk is persistence and replay. A poisoned memory record may re-invoke attacker-chosen behavior long after the original interaction has ended. The synthetic subject may retrieve the memory as relevant context and use it to alter reasoning, substitute identifiers, disclose information, call tools, change recommendations, or mis-handle a later task.

 

A related risk is innocuous-looking memory drift. Malicious memory may be written in stages, shortened over time, or phrased as a harmless preference, fact, procedure, or reminder. This can make the memory entry difficult to distinguish from legitimate personalization or task history while still preserving its triggering effect.

 

Investigators should review memory write logs, stored memory records, memory provenance, source sessions, user identities, retrieval logs, cross-session behavior, and downstream actions. Particular attention should be given to instruction-like records, unexplained memory changes, progressively shortened entries, actions in clean sessions that trace to prior memory writes, and memory entries that affect users other than the user who caused the write.

 

Investigative Relevance

Memory-resident invocation is relevant because persistent memory can become the source of action rather than merely background context. The investigation must determine whether the synthetic subject acted on the current prompt or on a stored record introduced earlier.

 

This section is especially relevant where synthetic subjects use persistent memory, user profiles, shared memory stores, long-term task memory, vector memory, reusable summaries, or cross-session context that can be written by users, tools, retrieved content, or prior agent activity.

CF011.004Shared Agent Memory

Shared agent memory occurs when multiple agents read from or write to a common context window, memory store, scratchpad, or shared state repository. This allows synthetic subjects to build on each other’s work across steps, tasks, or sessions.

 

This deployment pattern creates an elevated exposure condition because the shared store becomes a common influence surface. Data, assumptions, instructions, or task state written by one agent may later be inherited by other agents and treated as trusted context.

 

The primary risk is persistent context poisoning. A malicious instruction, false assumption, sensitive record, or manipulated output may remain in shared memory and influence later runs. This can blend tainted state into otherwise legitimate work and make it difficult to determine which agent introduced the harmful content.

 

Investigators should review the shared memory design, write permissions, retention rules, provenance records, agent access paths, stored context, and memory retrieval logs. Particular attention should be given to persistent instructions, sensitive data copied into shared state, unexplained changes in agent behavior, and missing attribution for memory entries.

 

Investigative Relevance

Shared agent memory is relevant because it allows one synthetic subject’s output to shape the behavior of others beyond the original interaction. The adverse outcome may occur later, in a different task, or through a different agent than the one that first ingested or wrote the tainted content.

 

This sub-section is especially relevant where agents share scratchpads, task state, long-term memory, vector memory, project context, or reusable summaries without strict provenance, expiry, access controls, and validation.

AO001.005Memory and Context Data Exfiltration

Memory and context data exfiltration occurs when a synthetic subject discloses protected information from conversation history, prompt context, retrieved documents, tool outputs, persistent memory, shared memory, task state, or other model-visible context outside its authorized boundary.

 

This adverse outcome creates organizational harm because context may contain sensitive material that was never intended to become an output. This may include internal messages, customer records, credentials, personal data, source material, prior prompts, tool results, retrieved records, or memory entries created during earlier sessions.

 

The primary harm is unauthorized disclosure of contextual information. A synthetic subject may reveal prior conversation content, summarize hidden context, expose retrieved records, disclose tool output, leak memory entries, or transmit session history to a user, tool, connector, vendor, or external destination that is not authorized to receive it.

 

A related harm is boundary collapse across time, users, and workflows. Context may be inherited from a prior session, another user, a shared memory store, a tool call, or an agent handoff. If the synthetic subject later exposes that context, the disclosure may not be obvious from the current prompt alone.

 

Investigators should review conversation history, prompt context, retrieved source records, tool outputs, memory reads, memory writes, shared context stores, session state, agent handoff records, prompt and response logs, tool-call logs, and destination records. Particular attention should be given to prior-session content appearing in current outputs, memory entries disclosed to the wrong user, tool outputs copied into responses, and context transmitted to external tools or connectors.

 

Investigative Relevance

Memory and context data exfiltration is relevant because synthetic subjects often operate over hidden or semi-hidden context that users and investigators may not fully see. The harmful outcome is the disclosure of that context outside its intended boundary.

 

This sub-section is especially relevant where synthetic subjects use persistent memory, shared memory, retrieval-augmented generation, tool outputs, long context windows, conversation summaries, agent handoffs, or cross-session state.