# The pieces

Every part of Seal, who runs it, and what each one can and can't see.

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

Only two pieces can open a blob, the enclave and the key guardian. Both run in hardware TEEs, and you can check their code. Everything else carries encrypted or signed data that those two check.

Click a piece to see what it does.

## How a secret gets sealed

`seal secret` checks the enclave's attestation first. Then it encrypts your key on your machine, to a key only that enclave holds. The enclave sends back a blob, and you store it wherever you like. Seal doesn't store blobs. See [Sealing a secret](https://seal.zone/docs/sealing).

## How a request flows

`session(blob)` checks the enclave, then proves your app's identity, such as its Azure managed identity. The enclave checks it against your grants.

Your code calls the SDK's local URL with a stand-in key. The enclave swaps in the real key, calls the upstream and masks the key in the response. See [Using a blob](https://seal.zone/docs/sessions).

## How replicas stay current

A replica keeps nothing on disk. While it runs:

- **At boot** it proves its build to the key guardian and gets your tenant's keys.
- **Every 30 seconds** it fetches your tenant's signed state and checks it. A removed grant cuts open sessions within about 30 seconds.
- **Every 5 seconds** it signs and ships a batch of [telemetry](https://seal.zone/docs/telemetry).

If it can't get a fresh state for 24 hours (the default), it stops serving. Every call then fails with `Unavailable`.

## Who runs it, and do you trust it

| Piece | Who runs it | Trust it? |
|---|---|---|
| Your app and the SDK | You | It's yours. Seal assumes it can be taken over. |
| Enclave replica | Seal, or you in your Azure network | Its code, which your SDK checks. Not its host. |
| Front door | Seal | No. It sees only encrypted traffic. |
| Key guardian | Seal | Its released code, and Microsoft's Key Vault. |
| Control plane | Seal | No. Everything it serves is signed. |
| Transparency log and witnesses | Seal runs the log. Witnesses are meant to be independent. | No. You check the signatures. |
| Registrar | Seal | Only to create your tenant. A look-alike tenant opens none of your blobs. |
| Console | Seal | No. It holds no admin keys. |
| CLI | You | It checks everything with keys built into it. |
| Upstream | Your provider, or you | As much as before Seal. |

## What you trust

- **The hardware.** AMD SEV-SNP chips in Azure confidential containers, and their attestation. See [Enclaves and attestation](https://seal.zone/docs/attestation).
- **The released code.** Each enclave and guardian release builds reproducibly, needs two of three release keys and waits in the public log first. See [Releases and the log](https://seal.zone/docs/releases).
- **Microsoft's Key Vault.** It releases the guardian's master key only to the guardian's exact build.

The rest can stop things working, for example by switching off a replica. None of it can read your key or grant access. See [What an attacker gets](https://seal.zone/docs/threat-model).