Get started

Key ideas

The handful of words Seal uses: secrets, blobs, sessions, tenants, apps, admins and enclaves, and how they fit together.

Secrets and blobs#

You seal a secret, like an API key or database password, to get a blob. Click each part below.

....

Tenant

The tenant that sealed it. Only acme's enclaves can open this blob. Another tenant's enclave, even one running the same code, can't.

FigureClick any part of the blob. Everything but the key is plain text, so you can check what a blob allows without opening it.

The blob's policy says where the secret may go and which apps may use it. Anyone can read the policy. Only the key is encrypted. Store the blob anywhere; Seal keeps no copy. See Sealing a secret.

Sessions#

A session lets your app use a blob without opening it. The SDK proves which app it is and gets a local URL and a stand-in key. The enclave adds the real secret on the way to the upstream. The stand-in key works only on that process's connection. See Using a blob.

Tenants and admins#

A tenant is one set of sealed secrets with its own admins and settings. Its root id fingerprints its first admin keys, so the SDK refuses a look-alike tenant with the same name.

Only admin keys sign the tenant's settings: passkeys or key files, optionally two of three. Console workspace roles never sign anything.

Narrowing changes apply at once. Widening changes wait in public for the pending window, and any admin can cancel them. See Admins and changes.

Apps and identities#

A blob sealed for checkout opens only in sessions started by checkout. A grant says how a running copy proves it's checkout: a cloud identity, a GitHub Actions workflow, or an app key file. Adding a server means a new grant, not resealing. See Apps and identities.

Enclaves and the guardian#

The enclave runs in a hardware TEE, a part of the processor whose memory the host can't read. It's the only place a blob opens. Seal can run a replica of it, you can run your own, and the SDK fails over between them.

The SDK checks the chip's attestation, a signed report of which code runs, before sending anything. Replicas get keys from Seal's key guardian, which serves only released builds that are public in the log first. See Enclaves and attestation and Releases and the log.

Who holds what#

Thing	Who holds it	Gets the secret?
The blob	Your app, your config	No. Only the enclave opens it.
Stand-in key	Your app's process	No. Works only on that connection.
App identity	Your server or cloud	No, but it can use the secret through the enclave as that app until you remove the grant.
Admin keys	Your admins	No. They change who may use it. Widening waits in public.
Workspace roles	Your team, in the console	No. They never sign changes.
Enclave keys	The enclave, from the guardian	Only inside the enclave, for your tenant.

The blob

Who holds itYour app, your config

Gets the secret?No. Only the enclave opens it.

Stand-in key

Who holds itYour app's process

Gets the secret?No. Works only on that connection.

App identity

Who holds itYour server or cloud

Gets the secret?No, but it can use the secret through the enclave as that app until you remove the grant.

Admin keys

Who holds itYour admins

Gets the secret?No. They change who may use it. Widening waits in public.

Workspace roles

Who holds itYour team, in the console

Gets the secret?No. They never sign changes.

Enclave keys

Who holds itThe enclave, from the guardian

Gets the secret?Only inside the enclave, for your tenant.

Root on your app's server can use the secret through the enclave while the app's identity is granted. It can never take the secret away. See What an attacker gets.