Data residency
Sovereign data lives in the enclave that owns it and never transits the controlplane. Residency is a property of where the enclave runs and where its keys live — both inside the customer's boundary.
The enclave owns its data
Each enclave owns its own database, physically separate from the controlplane
and from every other enclave. The separation is by distinct DSN, not by schema:
the controlplane database never holds sovereign data, and an enclave database
holds only its own tenant’s data and is never read by the controlplane
(internal/database). An enclave serves exactly one org, so its data set is that
one org’s data.
Data at rest is sealed with envelope encryption (internal/kms): a per-value data
encryption key (DEK) encrypts the plaintext locally with AES-256-GCM, and the key
encryption key (KEK) in the KMS only wraps the DEK — the KMS never sees
plaintext. An AAD binds each ciphertext to its logical identity (org, agent, secret), so a stolen (ciphertext, key_ref) pair cannot be replayed onto another
row. Decrypt is fail-closed.
Offboarding
Offboarding is by crypto-shred. Keys are partitioned per org by key name
(org-{id}-secrets) inside the one provider the enclave owns. Destroy that key
and the org’s rows become unreadable — the sealed data is unrecoverable. This is a
clean erasure story for GDPR and end-of-contract offboarding.
The controlplane never has to be involved, because it never held the sovereign data or the keys in the first place. There is no central ciphertext to compel and no key to compel. Tearing down the enclave and destroying its KMS keys leaves nothing recoverable behind.