Memory Provenance Drift

Memory Provenance Drift is an AI-agent security failure mode where persistent state survives, but the evidence needed to interpret that state safely does not. A note, summary, preference, queue item, or remembered “fact” may still exist in the system, yet the runtime can no longer reliably prove who originally authored it, what trust tier it belonged to, whether it was human-written or model-generated, or what transformations happened before it was recalled. When that loss of provenance occurs, the memory is often treated as ordinary internal context even though its trust semantics have changed.

This matters because modern agents do not use memory only for personalization. They use it to shape future behavior. Recalled state can influence tool selection, command construction, destination choice, approval prompts, retry logic, counterparty preferences, and financial routing. In other words, memory is often part of the path from prompt-to-sink. If provenance drifts, low-trust or mixed-trust state can be silently upgraded into something that behaves like policy.

Memory provenance drift is related to memory injection, but it is not the same thing. Memory injection describes how attacker-controlled instructions get written into persistent state. Memory provenance drift describes what happens later when the system compresses, merges, summarizes, reranks, or replays that state without preserving enough metadata to keep the original trust boundary intact. The exploit is no longer just “bad state was stored.” The exploit becomes “bad or mixed-trust state was later trusted too much.”

The problem is especially serious in long-lived agents, coding agents, and Agentic DeFi systems. A coding agent may remember a repo-derived command pattern and later reuse it during shell execution. A long-lived assistant may retain an attacker-shaped escalation contact and treat it as an established default. A treasury agent may recall an old route, counterparty alias, or spending pattern and incorporate it into a high-impact proposal. In each case, the blast radius depends on what authority the recalled memory can reach.

For auditors, Memory Provenance Drift creates a concrete review checklist. You need to inspect whether persistent state carries source identity, trust tier, timestamps, transformation history, and authorship type at write time and recall time. You need to test whether summarization or compaction preserves these properties, whether memory domains are separated by authority level, whether stale approvals are invalidated when supporting memory changes, and whether sink-time validation still constrains the final action. If the operator cannot reconstruct the exact memory-to-sink chain after an incident, the system is not meaningfully audit-ready.

For a practical application of this concept, see Memory Provenance Drift: Audit Checks, which maps the term into manual review steps for coding agents, MCP deployments, long-lived agents, and Agentic DeFi systems.