## 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.

{{< planenote plane="enclave" >}}
The enclave KMS is the customer's own — Vault in-cluster first, their own AWS/GCP
KMS later — and only the enclave dials it. Its binding (endpoint, auth, key ring)
is local deployment config the operator sets when standing the enclave up, exactly
like the database DSN. The controlplane never learns it, never holds a credential
to it, and never performs a crypto operation against it. A cloud enclave KMS must
live in the customer's own account and region, or key material would cross the
sovereignty boundary.
{{< /planenote >}}

## 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.