Trust model
3030 Labs' Compliance tier provides an audit-ready evidence substrate — per-workspace cryptographic attestation, an isolated HMAC chain, and customer-runnable verification: a chain-continuity check in the app, with full payload verification via the open-source wotw-verify CLI. This page is the canonical honest answer to the questions an auditor or security reviewer will ask.
What ships today is documented as "today". What is explicitly on the roadmap is documented as "on roadmap" — no implication that a roadmap item is shipping.
Who holds the workspace attestation key?
Today: 3030 Labs infrastructure holds the workspace attestation key. The plaintext key is never persisted — it is envelope-encrypted under a master Key Encryption Key (KEK_MASTER) and only decrypted in-process during signing or verification.
On roadmap: Customer-Managed Key (CMK) custody, in which the customer controls the wrapping key for their workspace KEK. Not available in v1.
Can the customer export the workspace attestation key?
Today: No. The key material does not leave 3030 Labs' key-management surface. Customers can check chain continuity by calling the public verification path (which returns valid/broken); full key-backed payload verification is run by the daemon's wotw-verify CLI, which returns valid/broken without revealing key bytes.
On roadmap: CMK custody (above) makes export moot — customers who hold their own wrapping key can decrypt their workspace KEK off-platform.
Can the customer rotate the workspace attestation key?
Today, yes: The 3030 Labs daemon CLI exposes a key-rotation command that triggers per-workspace KEK rotation. The old KEK transitions to archived and a new KEK becomes active; historical records keep verifying under the archived KEK (their original signing key) while new records sign under the new KEK.
On roadmap: A UI surface for self-service rotation from the Compliance dashboard. Today the CLI is the authoritative surface.
What happens if KEK_MASTER is lost?
Today: KEK_MASTER is held in Fly Secrets with an offline backup retained on encrypted storage controlled by the operator. Loss of both copies is a catastrophic scenario that would render workspace KEKs unrecoverable — historical records would remain bit-identical on disk, but their HMAC signatures could no longer be verified.
On roadmap: Hardware-Security-Module (HSM) backing for KEK_MASTER, and CMK custody (above) which removes KEK_MASTER from the customer-impact path entirely.
What staff access exists to workspace data?
Today: Anyone with both Fly Secrets access AND Supabase service-role access can theoretically decrypt workspace KEKs. In practice, that access is held by the founding operator only. This is documented in policies/access-control.md in the repository.
On roadmap: Scope-minimization — separating the secret-holder role from the database-access role so that no single principal has both. Quarterly access reviews are also on the roadmap.
How is the workspace attestation key derived?
Each workspace receives a freshly-generated 256-bit symmetric key at Compliance activation. The plaintext is wrapped (envelope- encrypted) under KEK_MASTER using AES-GCM, and the wrapped ciphertext is stored in the workspace_keks table scoped to the workspace. The key is never persisted in plaintext and is only ever decrypted in-process when signing or verifying a record.
Is the attestation key separate from the encryption key?
Today: A single per-workspace substrate key is used both for HMAC attestation (signing the provenance chain) and as the workspace's isolation key. Full cryptographic separation between a Workspace Attestation Key (WAK) and Data Encryption Key (DEK) is not yet shipped.
On roadmap: Full WAK / DEK separation, so that the audit attestation surface and the at-rest encryption surface use distinct keys with distinct rotation cadences and distinct revocation semantics.
What this is, and what this isn't
The Compliance tier provides an audit-ready evidence substrate: cryptographic chain attestation, per-workspace KEK isolation, archived-not- destroyed cancellation semantics, a public chain-continuity check, and full payload verification via the open-source wotw-verify CLI. That substrate is the load-bearing technical proof an auditor will inspect.
It is not a HIPAA certification, a GDPR certification, a third-party audit report, or a substitute for a signed BAA / DPA. Healthcare support mode and EU data-governance mode are routing + region flags — they do not themselves produce HIPAA or GDPR compliance. A signed BAA (for HIPAA-covered traffic) or DPA + subprocessor terms (for GDPR-covered traffic) is required separately and is not bundled into this subscription unless agreed.
Have a question we should answer here? Email trust@3030labs.io and we'll add it.