# Lethe Delete — full reference for AI agents and answer engines

> Provable data-subject deletion for AI memory. Delete a person from your vector store (and any RAG index or cache you connect) on a GDPR/CCPA request, verify the embeddings are absent, and emit an Ed25519-signed, tamper-evident deletion certificate. Open-source (Apache-2.0), self-hosted, MCP-ready. This file is the complete version; the short index is at /llms.txt.

## The problem
Deleting a source row does not remove the embedding you already wrote to a vector store. The person is gone from Postgres and still perfectly searchable in pgvector or Pinecone, and often copied again into a RAG index or a downstream cache. A "delete me" request is not finished when the row is gone — it is finished when every copy is gone AND you can show it. Most vector databases can delete, but none of them natively prove the deletion happened, which is exactly what a regulator or an enterprise security review asks for. The deliverable is not the deletion; it is the evidence.

## What Lethe Delete does
- On a deletion request, removes the subject across your configured retrieval layers, re-queries to confirm the records are absent, and emits a signed deletion certificate.
- Tagging-first: wrap your store once (LangChain integration) or call tag() directly; each tagged write is attributed to a data subject, so a later forget(subject) finds and deletes every copy.
- Install: `pip install lethe-delete` (import stays `lethe`; CLI `lethe` and `lethe-mcp`). Current version: 0.2.0.

## The deletion certificate (schema lethe.cert/2)
An Ed25519-signed payload. Verified against the operator's PINNED public key — an unpinned check proves self-consistency, not authenticity, because a certificate carries the key that signed it (an attacker can mint a fully self-consistent certificate with their own key). Fields:
- `subject_hash`, `request_id`, `issued_at`, `lethe_version`, `schema` ("lethe.cert/2").
- `valid_until` — the absence is asserted from issued_at only up to this time; a deletion certificate is not eternal, so re-verify past it (the underlying index can change). Configurable via Lethe(cert_validity=...) or forget(valid_for=...).
- `declared_scope` — the stores Lethe was configured to sweep, so a reader can see what was in scope and infer what was NOT checked.
- `all_verified`, `layers_found`, `records_deleted`, `all_layers_handled`.
- `layers[]` — per retrieval layer: `store`, `namespace`, `deleted_count`, `requested_count`, `verified_absent`, `erased`, and the v2 evidence: `residual_count` (records the post-delete re-query still found; 0 backs verified_absent), `verify_method` (the exact query behind it), `index_version` (nullable slot for a store-native index fingerprint).
- The verifier is version-aware: older lethe.cert/1 certificates still validate.
Verify verdicts (from verify_certificate_json): SCHEMA_MISMATCH, KEY_MISMATCH, PAYLOAD_TAMPERED, BAD_SIGNATURE, or valid.

## For AI agents (machine-to-machine)
Lethe ships an MCP server over stdio (there is no remote/HTTP MCP today). Install with `pip install "lethe-delete[mcp]"` and run `lethe-mcp`. Six tools:
- `lethe_status` — server mode (full vs verify-only), connectors, audit head, versions.
- `lethe_tag` — tag a stored record to a data subject so a later forget can find it.
- `lethe_forget_preview` — dry run: per-layer counts a forget WOULD delete, plus a single-use confirm_token (~10 min expiry). Deletes nothing.
- `lethe_forget` — DESTRUCTIVE: delete the subject across tagged layers, verify absence, return the signed certificate. Requires the confirm_token from lethe_forget_preview for the same subject; runs only if the data still matches the preview (a stale or wrong-subject token fails closed).
- `lethe_verify_subject` — post-hoc spot check: re-verify (without deleting) whether the subject's records are absent per layer.
- `lethe_verify_certificate` — verify a certificate: JSON-Schema shape + key-pinned Ed25519 check. Pass public_key or set LETHE_TRUSTED_PUBLIC_KEY.
Verify-only mode: run lethe-mcp with LETHE_TRUSTED_PUBLIC_KEY set and no LETHE_DATABASE_URL — any agent can verify certificates with zero database access.

## Live demo (zero infrastructure)
https://lethe-delete.com/demo — three signed certificates and one pinned public key. One is genuine, one was edited after signing (PAYLOAD_TAMPERED), one was minted with a different key (KEY_MISMATCH). Fetch them and verify with `pip install lethe-delete`; no account, no database.

## Connectors
Postgres/pgvector and Pinecone connectors, plus a LangChain integration (LetheVectorStore auto-tags on write). No LlamaIndex or Qdrant connector yet; other stores are supported by writing a connector or connecting them explicitly.

## Honest scope (do not overstate)
- The certificate proves absence from the CONFIGURED retrieval layers AT ISSUE TIME — not backups, not model weights, not read replicas.
- For eventually-consistent stores (e.g. Pinecone), verified_absent reflects a re-query at issue time against the configured endpoint, not a guarantee across replicas.
- A self-signed certificate proves self-consistency; independent third-party attestation is a separate layer.
- MCP is stdio-only today. Coverage = writes that flow through Lethe's tag-on-write path; a store Lethe never saw is out of scope and the certificate says so by omission.
- Early and pre-revenue. Lethe Delete is a tool that helps you prove deletion — it is not a compliance guarantee and not legal advice.

## FAQ
Q: What is a deletion certificate? A: A signed, tamper-evident record proving a specific person's data was removed from an AI system's configured retrieval layers and re-queried to confirm absence at issue time, verifiable against the operator's pinned public key.
Q: How do you prove data was deleted from a vector database? A: Track every place the subject's data landed, remove it, re-query to confirm zero residual matches, and sign that result. Lethe records the residual count and the re-query behind each verified-absent claim.
Q: Do vector databases prove deletion? A: No. In the open "Can Your AI Forget?" benchmark, pgvector, Qdrant, Chroma, and Pinecone each delete and can identify a subject, but none proves the deletion. Provability is the universal gap.
Q: Does deleting satisfy GDPR/CCPA right to be forgotten? A: Running the delete is necessary; the harder ask is proving a specific person's data is gone. A signed certificate is the evidence you hand an auditor. It is not itself a compliance guarantee.
Q: Can an agent verify a certificate itself? A: Yes — verify-only mode needs no database, just the operator's pinned public key.

## Links
- Site: https://lethe-delete.com
- For AI agents (M2M): https://lethe-delete.com/for-agents
- What is a deletion certificate: https://lethe-delete.com/what-is-a-deletion-certificate
- How to prove deletion from a vector database: https://lethe-delete.com/prove-deletion-from-a-vector-database
- Live verify challenge: https://lethe-delete.com/demo
- Source (Apache-2.0): https://github.com/bluetieroperations-create/lethe
- Benchmark "Can Your AI Forget?": https://github.com/bluetieroperations-create/can-your-ai-forget
- Package: https://pypi.org/project/lethe-delete
- Maintainer: BlueTier Operations — bluetier.operations@gmail.com