Cryptographic Erasure
Disposal you can prove. Retention you can keep.
GDPR Art. 17 and CCPA erasure rights pull in one direction. SOX, SEC Rule 17a-4, FINRA 4511, and HIPAA record-retention pull in the other. For an organization's data, Bolt and Aeira use a single cryptographic construction that satisfies both, by destroying the tenant's key while preserving the ciphertext and an independently verifiable receipt. The key is per organization, so one person's request is handled by a per-person erasure instead.
The construction
Four primitives, composed.
The mechanism has four pieces. The novelty is in the composition: each piece is a well-understood cryptographic primitive; combined, they deliver erasure-with-retention without sacrificing either obligation.
-
Per-tenant Customer Master Key
Each tenant's indexed document content and PII-vault entries are encrypted at rest with envelope encryption: a fresh AES-256 data-encryption key per value (AES-256-GCM), wrapped by a tenant-specific Customer Master Key (CMK). The wrapped data-encryption keys live alongside the ciphertext. With AWS KMS or Vault the CMK never leaves the KMS; with the default local backend it is derived on your host from a host master plus a per-tenant secret, and destroying that secret is what disposes of it.
-
WORM ciphertext retention
The encrypted bytes remain in their write-once-read-many store after erasure. Regulators that require retention (SOX, SEC, HIPAA record-keeping) see the ciphertext on the shelf; nobody can read it. The same physical bytes satisfy both the retention duty and the erasure right.
-
Cryptographic disposal of the CMK
When an organization's data is to be disposed of (offboarding, contract end, or a disposal order), its tenant CMK is destroyed inside the KMS. Every wrapped data-encryption key that depended on it becomes mathematically unrecoverable. The ciphertext is now indistinguishable from random noise to every party, including Sparcle, the operator, and any future court order.
-
Tamper-evident audit receipt
The disposal event is recorded as a signed receipt under the operator-root key, a key distinct from the disposed tenant CMK. The receipt is verifiable after the tenant key is gone. The receipt is appended to the BoltAuditSink Merkle chain so it cannot be removed or backdated.
Why this satisfies both obligations
The single primitive that closes the gap.
Disposal satisfied
When an organization's data must cease to be available, destroying the only key capable of decrypting it delivers that result without depending on every downstream backup, replica, or archive cooperating with a row-level delete. This is per organization: one person's Art. 17 request takes the per-person path described below.
Retention duty preserved
SOX, SEC Rule 17a-4, FINRA 4511, HIPAA record-retention, and equivalent obligations require that records persist for defined windows. The encrypted bytes remain. The retention auditor sees the artifact; only the readability has been revoked. This is the construction's central design point: both obligations satisfied by the same primitive.
Receipt independently verifiable
The signing key for the receipt is the operator-root key, kept under separate KMS isolation from the tenant CMK. Destruction of the tenant CMK does not affect the receipt's signature. A future auditor can verify the receipt long after the tenant key is gone.
Chain integrity preserved
The receipt is added to the BoltAuditSink Merkle chain. Removing or modifying the receipt would break the chain hash for every later event. The receipt is therefore as durable as the audit chain itself.
One person's request
Art. 17 for an individual is a per-person erasure.
Crypto-shred is per organization. There is one CMK per tenant and no per-person key, so destroying a key cannot erase one data subject while leaving everyone else readable.
An individual's request runs a per-person erasure, started by the user (with a 30-day grace period they can cancel) or by an administrator or DPO (grace period or immediate). It revokes the person's upstream OAuth grants, then deletes their account, sessions, sign-in and connector credentials, pseudonym bindings, devices and notifications. A receipt (signed when a KMS is configured) is stored and a record of the erasure is sealed into the audit chain.
What it does not remove today:
- Sealed audit records, which keep the person's user id so the chain still verifies.
- Chat history on the immediate administrator path. The grace-period path deletes it; otherwise it ages out under the retention window (90 days by default).
- PII-vault pseudonym entries, which neither path reaches yet.
- Recall memory, which the user can delete in the app and which otherwise ages out on its own timer.
- Documents about the person in the Aeira index. Aeira's document delete removes a document's keyword and vector index copies; for someone who is not a Bolt user, that is the path.
- Backups, which are the operator's to handle.
KMS backends
Where the key lives is your choice.
The construction is backend-agnostic; the trait-level abstraction lets each customer pick the KMS that fits their custody bar. The trait surface is identical, so swapping backends never changes the security model.
| Backend | Status |
|---|---|
| LocalKms | File-backed, production-tested. Used in pilots, development, and air-gapped deployments where customer policy forbids cloud KMS. |
| AwsKms | Reference implementation in the aeira-rs trait library. Cloud-service integration testing in flight. |
| VaultKms | Reference implementation against HashiCorp Vault Transit. Cloud-service integration testing in flight. |
| PKCS#11 HSM | Reference implementation on the roadmap for buyers with HSM-mandated key custody (defense, federal, FFI). |
| Azure Key Vault, GCP KMS | On the roadmap. Track this page or contact [email protected] for target dates. |
What an auditor receives
The packet your DPO or external auditor uses.
When a tenant disposal is processed, the customer's compliance officer can extract, for that request:
- The signed disposal receipt, with the operator-root public key needed to verify it.
- The Merkle inclusion proof showing the receipt is sealed in the audit chain at a specific position, with the chain hash before and after.
- A timestamped record of which tenant CMK was destroyed, which ciphertext objects were dependent on it, and which retention policy applied to each.
- A reference to the KMS audit log entry recording the destruction, signed by the KMS itself.
Customers running a SOC 2 or HIPAA audit feed this packet directly to their auditor. For a Supervisory-Authority response about that disposal, the packet provides the verifiable statement of completion that data-protection regulators look for.
What this page does not claim
Where the construction's edges sit.
The construction is precise about what it delivers. It is equally precise about what it does not. This section names the limits buyers and auditors should understand before relying on the receipt.
- The construction is auditor-acceptable, not auditor-asserted. Sparcle does not claim a third-party cryptographer has certified this implementation. A customer whose external auditor or regulator requires an independent attestation should treat that as a separate engagement; reference materials and a threat model are available under NDA for that work.
- The construction covers what the CMK encrypts: indexed document content and PII-vault entries. Document titles and embedding vectors stay readable so they can be searched, and audit records are signed rather than encrypted, so disposing of the CMK does not make those unreadable and they need a deletion step of their own.
- The construction protects ciphertext at rest. Plaintext that has already been delivered to a downstream system the customer controls (a SIEM, a data warehouse, an external archive) is outside Sparcle's reach. The customer's erasure runbook needs to address those surfaces directly.
- The construction does not erase the audit-receipt itself. The receipt records that the tenant's data was disposed of; the receipt is durable by design, as audit-retention obligations require.
- Quantum-resistance is not a property of the construction today. The CMK destruction guarantees readability removal under classical assumptions. A migration path to post-quantum KMS backends is on the roadmap; the construction is backend-agnostic.
Related controls
How this primitive sits next to the rest of the trust posture.
Cryptographic erasure is one control in a broader compliance architecture. The pages below cover the surrounding pieces:
- Controls evidence map: where this primitive maps in SOC 2, HIPAA, GDPR, and ISO 27001 control matrices.
- Where the model runs: how PII never reaches the LLM in plaintext, so the erasure surface stays small.
- Sub-processor disclosure: why the customer's KMS, not Sparcle, holds the keys this construction destroys.
- Security questionnaire: pre-filled answers covering encryption posture, key custody, and audit chain integrity.
Want the threat model and the formal write-up?
The full construction document (threat model, formal definitions, KMS-backend conformance test, and integration test report) is available under a mutual NDA during pilot evaluation.