Adapter Contract Specification §7.1

Right to Erasure

How CCL is designed to make erasure verifiable across distributed systems and AI agents.

The Distributed Erasure Problem

When a user or subject submits an erasure request under GDPR Art. 17, CCPA, or a comparable regulation, their contextual data has typically propagated to dozens of downstream systems: CRM platforms, analytics pipelines, data warehouses, AI agents, recommendation engines, and custom APIs. Each downstream system received a copy of the context at propagation time.

Traditional erasure processes rely on sending deletion instructions to each downstream system individually and trusting that each system executed the deletion completely. There is no shared key, no unified proof mechanism, and no technical way to confirm that an AI agent's embedded context, a cached analytics record, or a replicated CRM field was actually destroyed — not merely flagged.

As AI systems multiply the number of downstream consumers for any given context — including vector embeddings, model fine-tuning datasets, and agent memory stores — the gap between "we sent a deletion request" and "we can prove it is gone" widens substantially. CCL is architected to close that gap through cryptographic key destruction rather than coordinated deletion requests.

How CCL Is Designed to Implement Erasure

STACCR's erasure architecture is built on a three-tier key hierarchy: a tenant-scoped Key Encryption Key (KEK), held in the customer's own KMS and never destroyed, wraps a per-subject User Encryption Key (UEK), which in turn wraps each per-context Data Encryption Key (DEK). Context payloads are encrypted under a DEK — a per-context AES-256-GCM key. Each DEK is wrapped under the subject's UEK — an AES-KW key held in a dedicated erasure-key store. That store must be capable of immediate, attestable key destruction: Vault Transit, CloudHSM, Azure Managed HSM, or an equivalent external key store deployed in customer tenancy. Cloud KMS services that enforce a mandatory deletion waiting period on service-generated key material do not qualify for the UEK tier, because that waiting period would leave erasure reversible for weeks. STACCR is architected to never hold any of these keys.

Wrapped DEK blobs — not plaintext DEKs — are the only key material stored alongside ciphertext. Every DEK version ever issued for a subject is wrapped under the same UEK, including blobs in cold storage and backups.

Key Destruction

When an erasure request is authorized, STACCR is designed to trigger the destruction of the subject's UEK within the erasure-key store. Because the UEK wraps every DEK version ever issued for that subject — and DEKs exist only as wrapped blobs — destroying the UEK makes all DEK versions permanently unwrappable by construction. No ciphertext can be decrypted; no historical copy of the wrapped blob can be recovered. The mechanism does not require STACCR to locate and delete individual ciphertext copies across downstream systems.

The result is that erasure becomes a property of the cryptographic architecture, not a coordination problem. Once the UEK is destroyed, no version of the payload can be recovered regardless of how many copies of the ciphertext or wrapped DEK exist in how many systems.

Adapter Contract Confirmation

Every adapter participating in the STACCR ecosystem is designed to operate under a CE Adapter Contract — a binding technical and legal obligation that includes acknowledging erasure events with an Ed25519-signed confirmation receipt. When a key destruction event is issued, each adapter is designed to receive a signed notification and return a confirmation that it has invalidated any cached tokens, purged any locally held context references, and acknowledged that the payload is no longer recoverable.

These per-adapter acknowledgments are the building blocks of the Verifiable Erasure Certificate. No certificate is designed to be issued until all registered adapters for the subject have confirmed.

Audit Trail Integrity

The audit ledger is designed to record the key destruction event and all per-adapter acknowledgments as immutable, Ed25519-signed entries. Unlike the context payload itself — which becomes inaccessible after key destruction — the audit record is retained. This is intentional: the audit trail is the cryptographic evidence that erasure occurred, even though the erased content can no longer be read. The ledger is architected to satisfy regulatory evidence requirements without requiring the payload to remain accessible.

Target Erasure SLOs

A test decryption is attempted against destroyed key material as part of the standard erasure lifecycle. Failure is the expected and required outcome — any successful decryption after UEK destruction constitutes a SEV-1 security incident. The test decryption applies to platform-internal verification; adapter-level confirmation is governed separately by the adapter acknowledgment SLO.

What Is Retained After Erasure and Why

After the erasure lifecycle is complete, STACCR is designed to retain the following categories of data:

• The audit trail record of the erasure event — retained as cryptographic evidence that erasure occurred and available for regulatory inspection. Retention of the audit record does not constitute retention of the erased payload.
• The Verifiable Erasure Certificate — retained as the signed, regulator-ready artifact produced by the erasure process.
• Per-adapter acknowledgment receipts — retained as per-adapter confirmation that the erasure event was received and executed.
• Aggregate or anonymized analytics — retained only where not linked to the subject identifier and not within scope of the erasure request.

The context payload, consent records linked to the subject, and any subject-linked contextual state are designed to be rendered permanently inaccessible through key destruction. STACCR is designed to hold no recoverable copy of the erased payload.

Regulatory Alignment

The following table describes how CCL's cryptographic erasure architecture is designed to address each regulatory requirement. This is an architectural mapping, not a compliance certification. Organizations should conduct their own legal assessment for their specific jurisdiction and use case.

The Erasure Certificate

When the erasure lifecycle is complete — key destruction confirmed, all adapter acknowledgments received — STACCR is designed to issue a Verifiable Erasure Certificate: a signed, machine-readable document that captures the erasure event, confirms that each connected adapter acknowledged it, and establishes the cryptographic basis for the certificate's claims.

The certificate is architected to serve as regulatory evidence: an auditor or regulator is designed to be able to verify that erasure was cryptographically enforced — not merely administratively asserted. The certificate is designed to be signed with Ed25519, with ES256 (ECDSA P-256) as the mandatory alternative, with verification keys published at a well-known JWKS endpoint and a Merkle transparency log inclusion proof so verification requires zero trust in the issuer. The certificate includes the certificate identifier, subject reference (redacted), the DestructionAttestation (UEK destruction event covering all DEK versions by construction), per-adapter Ed25519-signed acknowledgments, test decryption result confirming inaccessibility, issuance timestamp, and issuer attribution.

{
  "certificate_id": "cert_01HXYZ9Q2...",
  "subject_id": "[REDACTED]",
  "destruction_attestation": {
    "uek_destroyed": true,
    "dek_versions_covered": ["v1", "v2", "v3"],
    "destruction_timestamp": "2026-06-11T17:41:57Z",
    "hsm_attestation": "Production architecture — pre-GA: FIPS 140-3 L1 (Vault Enterprise FIPS Inside, Leidos attestation, BoringCrypto CMVP cert #4735, verified 5 Aug 2026) — L3: validated Marvell modules — AWS CloudHSM (hsm2m.medium), LS2 HSM Family, CMVP #4703; Azure Key Vault Managed HSM, NITROXIII CNN35XX-NFBE HSM Family, CMVP #4700. See the detailed platform surface for Security Policy, approved-mode, and source requirements (ADR-002)"
  },
  "test_decryption_result":
    "FAILED — token unrecoverable",
  "adapter_acknowledgments": [
    { "adapter_id": "adp_crm_01...", "status": "ACKNOWLEDGED", "ed25519": true },
    { "adapter_id": "adp_analytics_02...", "status": "ACKNOWLEDGED", "ed25519": true },
    { "adapter_id": "adp_ai_agent_03...", "status": "ACKNOWLEDGED", "ed25519": true }
  ],
  "issued_at": "2026-06-11T17:42:09Z",
  "issuer": "STACCR™ / Context Layer Systems",
  "certificate_signature": "ed25519:...",
  "jwks_url": "https://keys.contextcontinuitylayer.org/.well-known/jwks.json",
  "transparency_log": {
    "leaf_hash": "sha256:...",
    "leaf_index": 0,
    "audit_path": [
      { "side": "right", "hash": "sha256:..." }
    ],
    "tree_size": 5,
    "signed_tree_head": {
      "version": 1,
      "hash_algorithm": "SHA-256",
      "tree_size": 5,
      "root_hash": "sha256:...",
      "timestamp": "...",
      "alg": "EdDSA",
      "kid": "<production-log-key-id>",
      "signature": "ed25519:..."
    },
    "note": "Production design: append-only transparency-log inclusion proof."
  }
}

Sample certificate — redacted, pre-GA format. Not a production certificate.