Crypto-Erasure
How does crypto-erasure work?
Crypto-erasure permanently renders data unrecoverable by destroying the memory’s Data Encryption Key (DEK) in the platform’s managed key service rather than overwriting individual grain blobs. This context database encrypts every grain with AES-256-GCM under the memory DEK, so destroying the key makes all associated AI memory computationally infeasible to decrypt — there is no partially-deleted state.
The forget_user() operation executes a deterministic sequence: emit a UserErased audit event (audit-first ordering), delete all grain blobs and index entries (graph, full-text, vector, entity_latest), redact cross-user grains where the erased entity appears as subject or object, destroy the memory’s key in the platform’s managed key service (crypto-erasure), and return an ErasureProof. Grain deletion happens before key destruction because the key is needed to locate encrypted index entries. This is a single-path operation — there is no object-storage cleanup pass. The approach is faster than data overwriting (O(1) key destruction vs O(n) blob rewrites) and provides cryptographic certainty of deletion.
The UserErased audit event records the key fingerprint (first 16 hex chars of SHA-256 of the key) and grain count for forensic correlation without revealing the actual key material.
import requests
# Erase all data for a user
resp = requests.post("https://acme.areev.ai/api/memories/default/forget",
json={"user_id": "john"})
proof = resp.json()
# proof["count"], proof["key_fingerprint"]
POST /api/memories/default/forget HTTP/1.1
Host: acme.areev.ai
Content-Type: application/json
{"user_id": "john"}
What does the erasure proof contain?
The forget_user() call returns an ErasureProof struct that serves as a verifiable record of deletion. This autonomous memory system produces a proof that data subjects or regulators can use as evidence of GDPR Art. 17 compliance.
The proof includes user_id, count (number of grains erased), key_fingerprint (computed as hex(SHA-256(dek)[..8]) — 16 hex characters that uniquely identify the destroyed key without revealing key material), timestamp (Unix milliseconds), user_record_deleted (boolean confirming user record removal), refresh_tokens_revoked (auth token cleanup count), hook_events_tombstoned (CDC event cleanup count), and cross_user_grains_redacted (number of other users’ grains where the erased entity appeared as subject or object and was replaced with “[erased]”). Six compliance verification checks validate erasure completeness: erasure_crypto, erasure_completeness, erasure_proof, erasure_key_destruction, erasure_data_inaccessible, and erasure_memory_clean.
{
"user_id": "john",
"count": 42,
"key_fingerprint": "a1b2c3d4e5f67890",
"timestamp": 1741531800000,
"user_record_deleted": true,
"refresh_tokens_revoked": 0,
"hook_events_tombstoned": null,
"cross_user_grains_redacted": 3
}
How does scope-level erasure work?
Areev supports scope-level crypto-erasure, where all grains within a scope are deleted as part of erasing the data they belong to. Scope-level erasure is useful for tenant isolation scenarios where an entire project or department needs to be purged. The ScopeErased audit event records the scope path and grain count. The operation follows the same single-path deterministic sequence as user-level erasure: index cleanup, audit logging, and key destruction in the managed key service — there is no object-storage cleanup pass.
POST /api/memories/default/scope-erase HTTP/1.1
Host: acme.areev.ai
Authorization: Bearer ar_...
Content-Type: application/json
{"scope_path": "projects/acme"}
The response returns the erasure proof: {status, scope_path, grains_deleted, key_fingerprint, timestamp}. The endpoint requires the admin scope and returns 404 with grains_deleted: 0 when the scope is empty or does not exist.
Related
- Key Management: How DEKs are created, wrapped, and rotated
- Encryption: AES-256-GCM encryption details
- Audit Trail: Hash-chained audit entries for erasure events
- GDPR: GDPR Art. 17 right-to-erasure requirements