Lethe Delete · definition

What is a deletion certificate?

A deletion certificate is a signed, tamper-evident record proving that a specific person's data was removed from an AI system's configured retrieval layers — a vector store, plus any RAG index or cache you connect — and re-queried to confirm the records are absent at the moment it was issued. It is verified against the operator's published public key, so a third party can check it without access to the underlying data.

Why AI memory needs one

Deleting a source row doesn't remove the embedding you already wrote to your vector store. The person is gone from Postgres and still perfectly searchable in pgvector, Pinecone, or Qdrant — and often copied again into a RAG index or a downstream cache. So a "delete me" request isn't done when the row is gone; it's done when every copy is gone and you can show it.

That second half is the gap. Most vector databases can delete, but none of them natively prove the deletion happened — which is exactly what a regulator, or an enterprise customer's security review, asks for. The deliverable isn't the deletion; it's the evidence.

What the certificate contains

A Lethe Delete certificate (schema lethe.cert/2) is an Ed25519-signed payload that records:

What was deleted, and where

The subject (as a hash), the retrieval layers swept, and per layer the deleted count and the declared_scope — the stores Lethe was configured to check, so a reader can see what was in scope and infer what wasn't.

The verification, as evidence

Each layer carries residual_count (how many records the post-delete re-query still found — 0 backs the absence claim) and verify_method (the exact query behind it). Absence is auditable, not asserted.

When it was true, and for how long

issued_at plus valid_until — a deletion certificate is not eternal; it asserts absence at issue time and tells you to re-verify past its freshness bound, because the underlying index can change.

How you verify one

You pin the operator's published public key and check the signature against it. This matters: a certificate carries the key that signed it, so a self-verifying check ("does the embedded key validate the embedded signature?") only proves internal consistency — an attacker can mint a fully self-consistent certificate with their own key. Only a check pinned to the operator's out-of-band key proves authenticity. An AI agent can do this with zero infrastructure via Lethe's verify-only mode. Try it on three live certs →

What it does not prove. A deletion certificate proves absence from the configured retrieval layers at issue time — not erasure from backups, model weights, or read replicas, and for eventually-consistent stores (e.g. Pinecone) not a guarantee across replicas. A self-signed certificate proves self-consistency; independent third-party attestation is a separate layer. Lethe Delete is a tool that helps you prove deletion — it is not a compliance guarantee or legal advice.

Frequently asked

How do you prove data was deleted from a vector database?
Track every place the subject's data landed, remove it, re-query to confirm zero residual matches, and sign that result against a published key. Lethe records the residual count and the re-query behind each verified-absent claim.
Does deleting from a vector store satisfy GDPR or CCPA right to be forgotten?
Running the delete is necessary; the harder ask is showing a specific person's data is gone and proving it. A signed certificate is the evidence you hand an auditor. It is not itself a compliance guarantee.
Can an AI agent verify a certificate itself?
Yes — verify-only mode needs no database, just the operator's pinned public key. See the live demo.
Is it open source?
Yes — Apache-2.0, self-hosted. pip install lethe-delete. Source.