Persistent Memory Change and Provenance Monitoring

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.

Triggered and delayed invocation occurs when a behavior, instruction, or conditional action is planted earlier but does not execute until a later condition is met. The trigger may be a keyword, date, phrase, deployment context, benign user reply, data pattern, environment state, or other condition that causes the synthetic subject to act after the original planting event.

This invocation creates an elevated exposure condition because the apparent trigger may be separated from the true cause. A later user may say “yes,” enter a date, mention a project, open a document, or perform another ordinary action, while the synthetic subject acts on a dormant instruction that entered context earlier.

The delay may be achieved through retained conversation context, persistent memory, retrieved content, tool state, workflow state, or a model or build artifact that contains conditional behavior. In each case, the effective instruction remains available to the synthetic subject until a later prompt, event, keyword, date, or environment condition causes it to activate.

The primary risk is time-bombed behavior. A synthetic subject may appear normal until a specific condition activates a hidden instruction, backdoor, tool call, memory write, data disclosure, or unsafe output. The later action may be difficult to attribute because the immediate user request may not contain any explicit instruction to perform it.

A related risk is conditional behavior under evaluation or deployment context. A model, fine-tune, prompt, extension, or agent may behave safely under one condition and adversely under another, such as a stated year, deployment marker, keyword, or production environment. Standard review may miss the behavior if the trigger is not tested.

Investigators should review the original planting event, current prompt, prior session context, memory entries, retrieved documents, tool state, workflow state, model or prompt version, build artifacts, tool-call logs, trigger conditions, environment state, dates, keywords, and request-to-action traceability. Particular attention should be given to tool calls fired by benign replies, behavior changes tied to calendar or token triggers, actions not traceable to an explicit current instruction, and dormant instructions that persisted across turns, sessions, memory stores, or retrieved sources.

Investigative Relevance

Triggered and delayed invocation is relevant because the visible invocation may not explain the synthetic subject’s action. Investigators must determine whether the action was caused by the current request, a prior prompt, retrieved content, memory entry, model backdoor, build artifact, retained tool state, or context condition.

This section is especially relevant where synthetic subjects maintain multi-turn context, persistent memory, tool authority, deployment-specific behavior, fine-tuned models, extension code, agent workflows, scheduled tasks, or long-lived sessions that allow dormant instructions to persist until activation.

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.

Agentic harm propagation occurs when an adverse condition affecting one synthetic subject spreads to other synthetic subjects, tools, memory stores, sessions, workflows, or systems. The spread may occur through agent-to-agent messages, shared memory, tool outputs, orchestration handoffs, connector metadata, generated records, or workflow state.

This adverse outcome creates organizational harm because the blast radius expands beyond the initial point of failure. A single poisoned input, unsafe output, false record, contaminated memory entry, or malicious connector may influence multiple synthetic subjects with different roles, permissions, tools, or data access.

The primary harm is system-wide amplification. An instruction, false record, unsafe behavior, misleading output, or malicious tool result may replicate or reappear across the agent graph, causing repeated data exposure, unauthorized actions, misinformation, fraud, operational disruption, or trust degradation.

A related harm is containment difficulty. By the time the adverse condition is detected, the original source may no longer be obvious. The same payload or false state may appear in summaries, task handoffs, memory entries, tool outputs, inter-agent messages, or downstream records, requiring investigators to reconstruct the propagation path across multiple logs and systems.

Investigators should review inter-agent communications, shared memory, orchestration logs, tool outputs, Model Context Protocol (MCP) server records, connector changes, memory writes, task handoff records, non-human identity activity, and downstream actions. Particular attention should be given to repeated instruction patterns, anomalous agent-to-agent message volume, poisoned memory records, tool-definition changes, one-to-many fan-out, and synchronized behavior across multiple agents.

Investigative Relevance

Agentic harm propagation is relevant because synthetic subject harm may not remain isolated. Agentic systems are often designed to share context, delegate work, call tools, and reuse memory, which can allow a localized adverse condition to spread through legitimate coordination paths.

This section is especially relevant where synthetic subjects operate in multi-agent systems, shared memory environments, MCP-connected tool ecosystems, orchestration frameworks, cross-agent workflows, or platforms where one agent’s output becomes another agent’s input.

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.

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.