# Key ideas

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

Source: https://seal.zone/docs/concepts

## Secrets and blobs

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

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](https://seal.zone/docs/sealing).

## 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](https://seal.zone/docs/sessions).

## 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](https://seal.zone/docs/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](https://seal.zone/docs/apps).

## 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](https://seal.zone/docs/attestation) and [Releases and the log](https://seal.zone/docs/releases).

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

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](https://seal.zone/docs/threat-model).