Show what your AI agent erased, and what its memory held when it acted.
An erasure request arrives. Your agent holds the person in its memory, in a vector index
and in the facts it derived from them. A delete() that returns 200 says nothing about
what the next query returns. inspeximus keeps a signed, content-free receipt for every write,
correction and erasure, and one for every action, carrying the state of the memory store at that
moment. You can show a regulator what the store held when the agent acted, which values had been
corrected, and that a residue scan found no trace of the erased subject when it was erased.
A single zero-dependency Python file and an MCP server. It produces evidence. Certification stays with the assessor. The memory slice only: the obligations bind the controller, provider or deployer, not the library. The same receipts can support the AI Act's record-keeping and accuracy duties (Art. 12/15/19) when they apply.
Of nine agent-memory libraries, none documents verifiable erasure.
We scanned the docs of nine agent-memory products (2026‑07). None advertise verifiable erasure with a receipt, cryptographically tamper-evident record-keeping, or any EU AI Act framing (docs read 2026‑07). We re-checked the audit-trail tools that appeared since (READMEs and sites read 2026‑09‑15, second table): they sign the agent's actions, and none of the ones we read ships a signed digest of the memory the agent acted on. inspeximus 2.29.1 records both.
| Library | Verifiable erasure (receipt) | Tamper-evident record-keeping | EU AI Act framing |
|---|---|---|---|
| mem0 | plain delete() |
none found | none found |
| Zep | delete + legal-hold, not verifiable | SOC 2 attested; audit logs not described as hash-linked | none found |
| Graphiti | “invalidated”, “not deleted” | provenance, not tamper-evident | none found |
| Letta, cognee, Memobase, LangMem, Redis, Pinecone | plain forget()/delete() |
none found | none found |
| inspeximus | signed content-free tombstone | hash-chain + signed anchor, verified offline | article-labelled overlay |
The only one we found among nine, from each product's documentation on 2026‑07, not an exhaustive proof of a universal negative. Zep has a SOC 2 and HIPAA compliance surface; its documentation does not describe verifiable erasure, hash-linked logs, or AI-Act alignment.
Audit-trail tools sign what the agent did. This one also records what its memory held.
Read from each project's README and site on 2026‑09‑15. inspeximus also records
the action half, so a separate action logger is optional for this slice; each action entry carries the
store's state digest and the ids the last recall on that store handle returned. The two nearest
designs we found: AgentPrizm describes recall receipts without a signature or an offline verifier, and
ArkForge described a signed hash of the context window (dev.to, April 2026) that its shipped repositories
do not carry. The ledger also exports in the format of the IETF Internet-Draft
draft-sharif-agent-audit-trail-04 (an individual submission, September 2026), with the draft's plain
hash fields left empty because the ledger's digests are salted. verify_jsonl checks a file
from any producer for the draft's fields, registries, timestamp order, nonce uniqueness and prev_hash
chain. It does not verify ES256 or ML-DSA-65 signatures or Merkle batches.
| Tool | Signs the agent's actions | Attests memory state | Evidence of erasure from memory |
|---|---|---|---|
| Asqav | ML‑DSA‑65 receipts per action, signed server‑side (a local Ed25519/ES256 mode exists) | none found | none found |
| AIR Blackbox | gateway log + 51+ checks | none found | the sibling Tombstone project crypto‑shreds data stored through its own vault; its README does not mention agent memory (read 2026‑09‑15) |
| agentaudit-python, ActionProof, AgentMint | hash chain or Ed25519 per action | none found | none found |
| LangSmith, Langfuse and other tracing | traces, not tamper-evident by default | none found | none found |
| inspeximus | action ledger, signed with the store's key; hashes and signatures verify offline, the memory binding needs the store | store digest and recalled ids on every action, this store handle only | signed tombstone, residue scan at erasure, offline certificate |
Others describe adjacent gaps, none of them about this product: a data-governance vendor writes that, as of 2026, no commercially available vector database provides a provable deletion mechanism (Atlan); a privacy law firm titled its note “You Cannot Delete What You Do Not Know the Agent Stored” (Astraea Counsel); and a 2026 thesis that checked 770 open-source agents against Art. 12 found that no high-risk agent among them fully complies, and 256 have no logging at all (ReDit, University of Texas at Arlington).
Three duties in the Act and the GDPR that touch agent memory.
Each maps to a shipped inspeximus primitive that runs deterministically, with no LLM on the write path and no new infrastructure.
Record-keeping, kept ≥ 6 months
With receipts on, every write is a hash-linked, timestamped receipt, and every action the agent takes
(a tool call, a model call) is one more, carrying the state of the memory store before it acted
(ActionLedger, 2.29.1). anchor() signs a tree head over the whole history.
audit-build exports a content-free bundle an auditor re-verifies from genesis offline,
with no live store and no key; binding the action entries to the memory chain needs the store.
A ledger kept for years is rotated under a signed checkpoint the verifier follows, and
actions attest records the oldest entry against the six-month floor (2.31.0).
Accuracy & resistance to tampering
Keyed supersession serves the corrected value and helps keep the stale one from resurfacing
(echo_guard); the influence gate and witness co-signing help detect memory-poisoning and
operator-side tampering (detect_split_view). An operator who holds the receipt key can
rewrite both chains consistently; the witness, not the ledger, is the control for that.
Evidence for the right to erasure
forget_subject hard-deletes the subject plus its derived lineage and emits a
signed, content-free tombstone; erasure_certificate is the portable evidence of deletion
from this store: a chain self-check runs when it is issued, the residue scan runs at erasure, and the
verifier confirms absence when given the store.
Three skeletons filled from the same evidence, with every gap named.
Each carries the sections a store and a ledger can supply and marks every field only the provider or deployer can write as OPERATOR INPUT REQUIRED. Not a conformity assessment. The law wants these documents before the system goes live, when the store is empty. What the evidence fills is the part that grows with operation: the logs, the oversight and incident record, the lifecycle changes, the post-market monitoring inputs (Annex IV points 6 and 9, Art. 27(2), Art. 72).
Technical documentation skeleton
inspeximus technical-documentation writes the Annex IV structure with the evidence sections
filled: which logs exist and how an auditor verifies them, what the store holds, the oversight events,
the chain verification, the controls report. The 24 provider fields (intended purpose, risk management,
conformity) are marked rather than invented. The Art. 13(3)(f) instructions for collecting and interpreting
the logs are generated from the code that runs.
Deployer report with DPIA and FRIA evidence appendices
inspeximus deployer-report writes the Art. 26 duties with evidence under the paragraphs a
ledger can speak to: oversight recorded and error actions nobody reviewed, incidents and whether they were
reported, the age of the oldest log entry against six calendar months, the measured source coverage of the
input data. Workers informed, persons informed and cooperation with authorities are marked as the
deployer's. The DPIA evidence appendix fills the Art. 35(7) inventory and measures and leaves necessity
and risk to the controller; the FRIA evidence appendix fills the observed use, the oversight and the
incidents, and cross-references the DPIA as Art. 27(4) allows. The report counts identities and lists none.
Registration export
inspeximus registration-export --section A|B|C writes the Annex VIII fields for the EU
database: the provider's section A, the Art. 6(3) section B (points 7 and 9 deleted by Regulation (EU) 2026/1744), the
public-authority deployer's section C, where the FRIA and DPIA summaries are the deployer's text and the
counts they rest on come from the deployer report.
It is the content of a registration. The EU database has its own form.
One command turns a store into a DPO-facing report.
Article-labelled evidence with live counts from your own store, and a bundle an auditor verifies without the store or the key.
# a store used normally, with the tamper-evident chain on: a fact, a correction, a PII record, an erasure $ inspeximus --receipts remember "retention policy is 90 days" --key policy::ret --object 90d $ inspeximus --receipts remember "retention policy is 30 days" --key policy::ret --object 30d # corrects $ inspeximus --receipts remember "user u_17 phone is +100" --key u17::phone --object +100 $ inspeximus --receipts forget --key u17::phone # right-to-erasure # one command → an article-labelled evidence report, live counts from the store $ inspeximus compliance --out report.html wrote compliance report -> report.html (6/21 controls with live evidence) # hand the auditor a content-free bundle; they verify it offline without the store or the key $ inspeximus audit-build --out bundle.json $ inspeximus audit-verify bundle.json OK write chain verifies from genesis: 3 append-only records -> anchor tip OK erasure chain verifies from genesis: 1 tombstones -> anchor tip ... 4 more OK lines, then 4 NOTE lines; two of them, abridged: NOTE UNSIGNED: 0 of 4 chain entries carry a signature. The chain is internally consistent, which is not the same as attributable ... NOTE SELF-CERTIFIED: this anchor carries no external co-signature. Every check above is the operator's own record-keeping verified against itself ... VERDICT: PASS (3 writes, 1 erasures, content NOT checked)
The boundary
This is the agent-memory slice only: the records, corrections and erasures in this store. It produces evidence, not a certification. The EU AI Act imposes far more than any memory library can satisfy (risk management, data governance, human oversight, conformity assessment), and those are the deployer’s job.
The obligations bind the controller, provider or deployer, not the library. inspeximus gives the accountable party the receipts, provenance and provable erasure they use to demonstrate the memory-record duties, and says so in every report it prints. The Art. 17 erasure evidence is only as complete as the encryption and copy-control of the underlying store.
inspeximus‑pro: the evidence pack, assembled.
The free tools cover one store. inspeximus‑pro turns every agent-memory store you run into one branded, signed dossier built for auditors: an org-wide compliance matrix, a cross-store erasure register, and a verification runbook an auditor can run with the free CLI (we have not tested how any conformity assessor treats it).
- Many stores → one signed
MANIFEST.json+ a print-ready dossier. - Every bundle verifiable offline with the free
inspeximus audit-verify. - Open-core: it assembles the free primitives and does not paywall them. It runs without servers or an LLM.
Memory evidence, in plain terms.
How do I show a regulator that my AI agent erased a user under GDPR Article 17?
Erase the subject from the agent's memory store, remove the records derived from it, and keep a
signed, content-free tombstone that an auditor can verify without the store or the key. inspeximus
does this with forget_subject and erasure_certificate. The evidence covers
this memory store and what its recall returns afterwards, at the moment the certificate was issued.
Copies outside that store, prompt logs and the model itself are the deployer's responsibility; the
erasure register names any registered store that did not confirm.
Does the EU AI Act require logging what an AI agent remembers?
Not in those words. Article 12 requires automatic event logging for high-risk systems, and Article 19 requires keeping the logs for at least six months. Neither article names memory, provenance or tamper-evidence. Mapping those duties onto agent memory is an interpretation, and every inspeximus report labels itself evidence, not certification.
When do the EU AI Act high-risk obligations apply?
From 2 December 2027 for standalone Annex III systems and from 2 August 2028 for Annex I product-embedded systems, after Regulation (EU) 2026/1744 (the Digital Omnibus on AI, in force 27 July 2026) deferred them. Article 50 transparency duties apply from 2 August 2026 (generative systems already on the market have until 2 December 2026 for Article 50(2) marking); the existing prohibitions and the general-purpose AI obligations were not deferred, and a high-risk system already on the market before its date is covered only when its design changes significantly (Art. 111(2)). GDPR Article 17 erasure has applied since 25 May 2018.
What is the difference between an agent audit log and memory evidence?
An audit log signs what the agent did: each tool call or model call becomes a receipt. Memory
evidence attests what the agent knew when it acted: which facts were current, which had been
corrected, and which had been erased. Tools such as Asqav and AIR Blackbox provide the first;
AgentPrizm describes unsigned recall receipts and ArkForge described a signed hash of the context window.
inspeximus records the action and the store state in one chain, so what_it_knew(seq)
answers from the record. Through the MCP server it sees tool arguments and results, not the host's
prompt. Through the LangChain callback it digests the messages of each model call, not what the
provider adds. It does not see a store in another process. The action name says which.
Can I show what the model was given before it acted?
Through the LangChain callback, yes. Each model call becomes a ledger entry with a salted digest of
its input. The digest covers every message LangChain sent in that call: role, content and tool calls.
Bound tool schemas, sampling parameters and anything the provider adds server-side are outside it.
The ledger keeps no content, so the transcript stays with you. To check it later, call
matches(seq, inputs=...). A change to any message's role, text or tool call, even one
character, answers no. Only the holder of the ledger's salt file can run the check. Without the salt,
a reader cannot test a guess against a digest. Keep the salt file under the transcript's access
controls, because with it a short input such as an order id can be recovered by guessing. Through
the MCP server the ledger sees tool arguments and results, not the host's prompt. The action name
says which: mcp: entries hold tool arguments and results, llm: entries hold
the model's messages.
Can a vector database show that a deletion happened?
A delete call returns success and says nothing about what a later query returns. inspeximus stores a signed tombstone for every erasure, re-checks the store for residue, and exports a bundle an auditor verifies offline. It also registers external stores such as a vector index, so the erasure register names any store that did not confirm. That is evidence of deletion from the stores it can see, not a guarantee about copies it cannot.
Can it write my Annex IV technical documentation, my DPIA or my FRIA?
It writes the skeleton and fills what a memory store and an action ledger can show: the logs and how to verify them, the data held, the oversight and incident record, the erasures, the observed period of use. On a store that has not run yet, every evidence section is empty too. The intended purpose, the risk assessment, the necessity and proportionality judgement and the affected groups are yours, and every such field is marked OPERATOR INPUT REQUIRED rather than filled with a guess. The AI Office's FRIA template under Art. 27(5) had not been published when this page was written; the appendix follows Art. 27(1)(a) to (f).