Agent Memory Erasure Propagation: From User Forgetting Request to Verifiable Purge

After a user clicks "forget this," the primary database record may disappear, but the vector index can still recall it; the summary contains the same fact, Redis still caches the old prompt, and a nightly backup restore will bring the record back. A deletion API returning 204 only proves the entry accepted the request, not that the system has forgotten. AI Application Data Privacy provides overall principles; this article focuses on the copies and derived propagation of Agent memory.

Freeze identity scope first, then execute deletion

The request is parsed into a stable (tenantId, subjectId) or a specified (memoryId, version), not fuzzy-searched by name or email string. The control plane creates a deletion job that contains no original text, recording the request basis, scope, policy version, and deadline. subjectEpoch is only atomically incremented when deleting all of a subject's memories; deleting a single memory only appends a precise (memoryId, version) tombstone, and unrelated memories must not all be invalidated due to an epoch change.

REQUESTED -> FROZEN -> DELETING -> VERIFYING -> COMPLETE
                         |             |
                         +----------> BLOCKED

Each run's lease is bound to the subjectEpoch at read time and all (memoryId, version) fences. Outputs, tools, and state sinks obtain a single permit at the acceptance point from a linearizable gate; the gate atomically checks the fencing token and registers in-flight work, and the executor holds the permit until the boundary ends. A stale worker cannot bypass the sink—this is not check-then-act, and it cannot be replaced by a prompt.

Deletion atomically closes the fence at the same gate; once closed, no more permits are issued, the model stream is aborted, buffered tokens are discarded, and undispatched tools are revoked. Subject deletion cancels all old leases; single-memory deletion only cancels leases that reference that version. FROZEN waits for existing permits to be cancelled or drain; lease TTL only reclaims ownership, it doesn't count as draining. Un-drained items leave the job BLOCKED and cannot be completed by timeout. Expired outbox, offline devices, and recovery tasks must also obey the epoch or precise tombstone.

The deletion inventory covers facts, indexes, and derived artifacts

The asset registry defines owner, locator key, deletion adapter, maximum completion time, and validation query for each class of storage. It must at least cover the version primary table, current projection, vector and keyword indexes, summary artifacts, prompt snapshots, caches, queues, exports, analytics replicas, and vendor storage. Data that only stores aggregates and cannot be re-identified to individuals may not need row-by-row deletion, but the decision and proof must be recorded.

Derived artifacts must have a derivedFrom edge so the control plane can find summaries and caches from the source memory; legacy data lacking lineage is first isolated wholesale from the read side, then backfilled with asset scans—you cannot assume it has already been cleaned. Memory Consolidation Lineage makes the invalidation scope computable, and the deletion tombstone from RAG Incremental Indexing Consistency can be used by index workers.

{
  "jobId": "del-817",
  "scope": "SUBJECT",
  "scopeHash": "hmac:41bf7d8ce205a9630f6b147ea29d54c8b31f9062de785ac443f0921cb67e38ad",
  "subjectEpoch": 12,
  "targets": {
    "primary": "DONE:14",
    "vector": "DONE:14",
    "summaries": "DONE:3",
    "cache": "DONE:8",
    "backup": "PENDING_EXPIRY:2026-08-17"
  }
}

The completion proof only saves the scope HMAC, counts, adapter version, time, and error codes; it does not copy the deleted content. Whether regulations such as EU GDPR Article 17 apply should be determined by the organization's legal and data governance process; the engineering system is only responsible for reliably executing the approved scope.

Backups cannot pretend to support instantaneous row-by-row erasure

Immutable backups usually cannot be safely modified. The policy must specify the maximum backup lifetime, access isolation, and recovery gate: any recovery environment must first load the deletion journal and the latest epoch, replay all tombstones and verify them, before business reads are allowed. When independent data keys are used per tenant or partition, cryptographic unreadability can be achieved by destroying the key, but this only holds when key copies, wrapping keys, and snapshot paths are all included in the inventory. Media disposal references NIST SP 800-88 Rev. 2; specific cloud storage capabilities still need to be tested. The document page was accessed on 2026-07-18.

Use a unique canary for end-to-end deletion verification

Write a random canary into an isolated test tenant and let it go through extraction, vectorization, summarization, caching, and backup drills. After submitting the deletion, query each backend precisely by ID, and run recall tests with multiple semantic rewrites; expect the primary record, index hits, summary lineage, and cache to all be zero, and old-epoch replays to be rejected. Do not globally search production logs for the user's original text—that creates new sensitive copies.

Fault tests place the gate closure between the worker request and sink acceptance, and cover model-already-read memory, buffered tokens, queued tools, deletion before final commit, adapter response loss, vector offline, and old backup recovery. After closure, assert zero new permits and zero new admissions; permits already obtained before closure must be confirmed cancelled or reach a terminal state and drain, after which you assert zero subsequent outputs, effects, and writes. Any un-drained target/permit prevents COMPLETE.

Roll out first on test tenants and internal accounts, confirming completion latency, blocking rate, old-generation rejection counts, and recovery drills. Then add hard gates backend by backend; storage without an adapter must not accept new memories. During an incident you can pause new deletion requests or switch adapter versions, but you cannot "roll back" an already-completed user deletion, nor restore reads of old epochs.

Before downgrading software to an old version, you must prove the old service also recognizes the deletion journal and epoch; otherwise keep memory reads closed. Disaster Recovery should not come at the cost of resurrecting deleted data. True forgetting is complete when all copies are inaccessible, old events cannot be resurrected, and data remains invisible after recovery—not when a database DELETE runs.

Further Reading

• AI Application Data Privacy
• Memory Consolidation Lineage
• RAG Incremental Indexing Consistency
• Disaster Recovery