STACCR™ · Cryptographic Erasure Engine
Provable destruction,
not promised deletion.
When a key is destroyed, every ciphertext it ever protected becomes permanently unrecoverable — across every backup, replica, and AI context store — without touching any of them. That's the proof. Not a log entry saying a job ran.
Pre-GA: STACCR's erasure engine is architected and under active design-partner engagement. This page demonstrates the designed mechanism — not a shipping product.
The Problem
Deletion tells systems to forget. It can't prove they did.
Distributed copies
When context propagates — to a CRM, a data warehouse, an AI agent's memory — each system received a copy. Deletion must reach all of them. Most can't confirm it did.
Append-only stores
Backups, audit logs, WORM archives, and vector databases are structurally resistant to deletion. You can't overwrite what you're forbidden from overwriting.
No shared proof
There is no cryptographic primitive behind a deletion API call. Every 'DELETE' is a promise. The requesting party has no way to verify the promise was kept.
AI context leakage
AI agents embed context into model state, fine-tuning sets, and memory stores. No deletion API exists for embedded context — but a key can govern all of it.
How It Works
One key governs every copy. Destroy the key, invalidate all of them.
Every context token is encrypted with a User Encryption Key (UEK) that never leaves the KMS. Downstream adapters — CRMs, warehouses, AI agents — receive only ciphertext. The key is what unlocks access. When erasure is requested, the key is destroyed. The ciphertext remains, but it becomes permanently meaningless. No downstream system needs to cooperate.
Step through the erasure sequence
Key Lifecycle State
Active
Scheduled
Destroying
Deleted
Verified
Destruction Sequence
Generate erasure request
Revoke decrypt access via KMS ACL
Destroy UEK key material
Notify adapters via propagation registry
Issue cryptographic erasure certificate
The Proof
Every erasure produces a verifiable certificate.
After UEK destruction and adapter acknowledgment collection, STACCR issues a cryptographic erasure certificate — a signed, structured record containing the DestructionAttestation (UEK destruction event covering all DEK versions by construction), all adapter acknowledgments, and a regulation mapping. The certificate is Ed25519-signed and JWKS-verifiable, stored in an immutable audit ledger, and can be exported for regulatory submission.
Today the STACCR Developer Sandbox exposes a published JWKS and a real session-scoped Merkle inclusion proof under the published verification specification, so any party can verify the certificate signature and its inclusion in that session tree. The sandbox proof is not the production append-only transparency log. The production architecture is designed to use that log; the operational production service remains on the pre-GA roadmap. See the platform explanation for the sandbox boundary and the published verification specification for the contract.
Regulatory Coverage
Designed to satisfy erasure obligations across major frameworks.
The following mapping reflects how STACCR's erasure architecture is designed to address each regulation's specific requirements. All language uses "designed to" framing — STACCR is pre-GA and makes no present-tense compliance certification.
Art. 17
Right to erasure ('right to be forgotten'): controller must erase personal data without undue delay.
Cryptographic key destruction renders all copies computationally inaccessible simultaneously, with verifiable proof.
§1798.105
Consumers may request deletion of personal information collected by a business or service provider.
Erasure certificate with adapter acknowledgments provides documented evidence of purge across all connected systems.
§164.312(a)(2)(iv)
Encryption and decryption: implement mechanism to encrypt and decrypt ePHI. Destruction must render data unreadable.
AES-256-GCM key material destruction following NIST SP 800-57 Part 1 key management guidelines. Designed to provide (production architecture — pre-GA): FIPS 140-3 L1 attestation via Vault Enterprise ≥1.19.4 FIPS Inside (Leidos attestation, BoringCrypto CMVP cert #4735, verified 5 Aug 2026). Level 3 uses validated Marvell modules — AWS CloudHSM (hsm2m.medium), LS2 HSM Family under CMVP #4703; Azure Key Vault Managed HSM, NITROXIII CNN35XX-NFBE HSM Family under CMVP #4700. See the detailed platform surface for Security Policy, approved-mode, and source requirements (ADR-002).
Art. 18 VI
Data subjects have the right to deletion of unnecessary or excessive personal data.
Key destruction propagates across all registered adapters; signed certificate is issued per request.
Art. 10(5)
Where necessary, providers shall ensure training data can be erased and verified erased from deployed models.
CCL context tokens in AI agent memory stores are governed by the same key — destruction revokes all copies including embedded context.
Open Hard Problem
What cryptographic erasure does — and doesn't — reach.
Destroying the UEK makes every tokenized context copy computationally inaccessible — across every adapter, backup, and replica that received an encrypted token reference. That claim is precise and verifiable.
There is an adjacent problem this architecture does not yet solve, and intellectual honesty requires saying so clearly: derived artifacts. When a subject's data was used to train a model fine-tune, build a vector store index, generate an embedding, or seed a caching layer, destroying the source UEK does not reach those derivatives. The ciphertext is gone; the learned pattern may not be.
Model fine-tunes
If a subject's context was used to fine-tune an LLM, destroying the context token does not remove the gradient influence from the model weights. This is an open research problem across the industry — not specific to CCL.
Vector store indices
Semantic embeddings derived from a subject's data may survive source deletion. STACCR's roadmap includes adapter-level erasure contracts that require downstream systems to purge their derived representations.
Inference-based re-identification
EDPB draft Guidelines 02/2026 on Anonymisation (adopted 7 July 2026, consultation open until 30 October 2026) add a fourth criterion addressing inference-based re-identification. Key destruction addresses data access, not inference from aggregate patterns.
Cached summaries & analytics
Aggregated rows, pre-computed statistics, and cached analytical results derived from a subject's data require explicit adapter-level purge contracts, which STACCR's propagation registry is architected to enforce — but which require adapter cooperation to complete.
STACCR's roadmap position on ghost vectors
The CE Adapter Contract (Phase 2) requires registered adapters to attest that derived representations — embeddings, fine-tune datasets, cached summaries — have been purged alongside the primary ciphertext. Attestation is enforced through signed adapter acknowledgments, not on-trust assertions. Ghost vector purge across model weights is a known open research problem; STACCR's Phase 3 roadmap addresses it through integration with model auditing frameworks. We believe honesty about the boundary of the proof is itself a form of credibility — and that narrowing that boundary over time, verifiably, is the work.
Design Partners
We're co-designing the implementation with security-first teams.
If your team is responsible for demonstrable erasure across AI systems, distributed data pipelines, or multi-tenant SaaS — and you want to shape what the certificate format, adapter contract, and audit export look like — we'd like to work with you.
Pre-GASTACCR™ capability statements on this site use designed to and architected for language deliberately. Language transitions to present tense for each capability as it ships and is independently tested.