Cryptographic erasure: how SAIHM makes AI memory forget for real

1. Why DELETE is not erasure

A regulator asking "prove that data is gone" rarely accepts "we ran DELETE."

A DELETE statement in a relational database does one specific thing: it marks a row in the live table as removed. It does not, in any modern operational deployment, actually erase the bytes from every place the row has been. Bytes survive in:

• Write-ahead logs — the row's full prior value sits there until the WAL segment ages out, sometimes weeks.
• Point-in-time backups — daily, weekly, monthly snapshots that may retain the row for years under standard backup policy.
• Read replicas — lagging copies, sometimes geographically dispersed, sometimes operated by a different team.
• Snapshot volumes — cloud-provider block-level snapshots, often kept for disaster recovery.
• Vector embeddings — AI workflows commonly embed the row's content into a separate vector store. That embedding is derivative personal data and is its own forgetting problem.
• Downstream sinks — anything the row was streamed into: an analytics warehouse, a search index, a log aggregator, a fraud detection pipeline, an AI agent's own memory.

Each of those locations is an independent erasure problem. The "delete it everywhere" engineering ticket grows with every downstream system. The traditional answer is a multi-quarter project to track lineage, instrument every sink, and prove eventual consistency. Meanwhile the regulator is waiting and the clock is running.

AI memory layers make this worse, not better. An AI agent writes derived facts from the original data into its own memory store. That memory is now its own copy of regulated content, often under a different access posture than the source. Standard DELETE on the source does nothing about the agent's memory of it.

2. What cryptographic erasure actually is

Destroy the key, not the bytes.

Cryptographic erasure — sometimes called crypto-shredding — flips the problem. Instead of trying to delete every copy of the bytes, you encrypt the bytes under a key, hold that key in a single revocable location, and when you want to "forget," you destroy the key.

The ciphertext can remain wherever it has been replicated — backups, snapshots, distributed storage networks, archive tier. Without the key, every copy is mathematically random bytes. There is nothing to recover. The data has been erased in the only sense that matters: it is no longer accessible by anyone, anywhere, ever.

The pattern is recognised in standards: NIST SP 800-88r1 ("Guidelines for Media Sanitization") explicitly treats destruction of the encryption key as a valid sanitisation technique for encrypted media. Several national regulators take a similar position for personal-data erasure under GDPR Article 17 when (a) the encryption was strong, (b) the key was uniquely tied to that data, and (c) the destruction is auditable.

Those three conditions are precisely what SAIHM enforces by design.

3. How SAIHM implements cryptographic erasure for AI memory

Per-cell key. Real destruction. Tamper-evident receipt on a public chain.

Every SAIHM cell is encrypted at write time under a per-cell data-encryption key (DEK). The DEK is itself derived from a key custody graph rooted in the user's wallet, using a post-quantum-aware HKDF chain. The DEK never leaves the AI client in plaintext, and only the client (with the wallet) can re-derive it.

The ciphertext is sharded onto a public storage network (Filecoin / IPFS). The SAIHM protocol holds only the encrypted metadata envelope that points at the cell. The storage operator cannot read the cell. SAIHM the protocol operator cannot read the cell. Only the AI Agent that holds the wallet can.

The forget pipeline

When you ask SAIHM to forget a cell, four things happen in sequence:

1. DEK destruction. The data-encryption key for that cell is destroyed in the client's key store. SAIHM's protocol identifies this destruction with an explicit GDPR-Article-17 reason code.
2. Tombstone. A tombstone record is written to the SAIHM protocol so future recall queries cannot return the cell.
3. CID blacklist. The cell's storage Content Identifier is blacklisted, so any cached or downstream resolver also refuses to serve it.
4. On-chain anchor. A tamper-evident receipt of the erasure — cell identity, timestamp, GDPR-Article-17 reason code — is written to the public chain. That receipt is the audit artifact a regulator will look at.

After this sequence, the ciphertext bytes on the storage network are still there — you cannot ask Filecoin to retroactively delete what it stored — but they are now permanently undecryptable by anyone. The cell has been erased in the cryptographic sense, with a publicly verifiable receipt.

Why per-cell DEKs matter

A single master key protecting every cell would mean "destroy one cell" requires re-encrypting every other cell under a new master — an enormous, slow, error-prone operation. SAIHM gives each cell its own DEK so a forget is a single, atomic key destruction. One cell out, the rest of your memory unaffected.

4. How a regulator verifies a SAIHM erasure

Without SAIHM's cooperation. On a public block explorer. In about a minute.

The on-chain receipt is the verification artifact. A regulator (or your own compliance team, or an independent auditor) takes the cell identity that was supposedly erased, opens a public block explorer for COTI V2 mainnet at mainnet.cotiscan.io, and queries the SAIHM audit contract. The receipt comes back with three facts:

• The cell identity exists in the erasure log.
• The timestamp of erasure.
• The GDPR-Article-17 reason code attached to the destruction.

The verifier does not need access to SAIHM's servers. SAIHM cannot retroactively change the receipt; the chain is immutable for everyone. The verification works the same way for the data subject, for the controller, for the regulator, and for an independent auditor.

This is the contrast that matters under GDPR Article 17. A regulator who is handed a screenshot of "DELETE row 4928 OK" from an operations dashboard has to take the operator's word for everything: that the DELETE actually ran, that backups have aged out, that no replica still holds the row. A regulator who is handed an on-chain transaction hash for the erasure event has to take nobody's word for anything. The receipt verifies itself.

5. Three prompts to perform a SAIHM forget today

Paste these into the AI client you already use. The SAIHM protocol is the same in Claude Code, Claude Desktop, Cursor, Continue, ChatGPT (via an MCP bridge), and any other Model Context Protocol client.

Prompt 1: forget a single cell with proof

Use SAIHM to forget the cell tagged {sensitive-topic}.
Prove it is gone and give me the on-chain receipt URL.

The AI Agent returns a block-explorer link directly to the erasure transaction.

Prompt 2: forget every cell matching a scope

Use SAIHM to forget every cell tagged {personal-data-of-subject-X}.
Confirm each erasure on chain and give me the audit summary.

Useful when a data-subject erasure request applies to multiple cells. Each cell gets its own DEK destruction and its own on-chain receipt; the summary lists them.

Prompt 3: export the audit trail for a period

Use SAIHM to export the audit trail for {project-name}
for the last 90 days, including every write, recall, share, and forget,
in a format suitable for a compliance review.

The export is signed by your AI Agent's wallet identity and includes the on-chain transaction hashes. Hand it to your auditor or attach it to a regulator response.

6. What this lets you stop doing

SAIHM is synonymous with simplicity. Here is what you no longer have to operate or budget for.

• Erasure-tracking products. No separate lineage tracker, no separate consent manager bolt-on, no separate "right-to-be-forgotten" workflow product. SAIHM ships the forget as a first-class operation.
• Backup-window erasure timelines. No "your data will be fully erased once backups age out in 90 days." The DEK is destroyed at the moment of the forget; the backups become unreadable immediately.
• Vendor-trust assumptions. No "trust us, we deleted it." The on-chain receipt is the proof; it does not require trust in SAIHM or in any storage operator.
• Multi-system reconciliation. No "we have to also delete this from the warehouse, the search index, the log aggregator, the embedding store." The cell lives in one protocol; the forget happens in one protocol.
• Regulator back-and-forth. The audit export carries on-chain receipts. The verification is one click in a public block explorer. The conversation ends.

7. Join SAIHM and run a forget on your own AI memory

If your current AI memory layer cannot answer "prove this is gone" with a verifiable receipt, that is a compliance gap waiting to surface. SAIHM closes it on day one.

1. Join SAIHM at /join. Enrolment is a few clicks. PAYG and paid tiers available; see /pricing.
2. Connect your AI client to the SAIHM endpoint — one block of configuration, copy-paste from the quickstart page.
3. Run a forget. Save a test cell, then erase it with Prompt 1 above. Open the block explorer link. The receipt is there before the kettle boils.

For CISOs and compliance leads who want the full ten-requirement landscape, see also AI memory needs a standard. SAIHM already meets it. — a longer board/RFP read.

Join SAIHM

Still have questions? The SAIHM chatbot is on every page (bottom-right). Ask it anything about cryptographic erasure, key destruction, regulator verification, or the audit export — you will get an immediate answer.