# What an attacker gets

Pick an attacker, from someone with root on your server to Seal itself, and see what they can and can't do.

Source: https://seal.zone/docs/threat-model

Only the enclave holds your key in readable form, and only uses it on the sealed destination. An attacker can still use the key through the enclave, deny service or see metadata.

## Root on your app server

Someone takes over your app's machine. Seal is built for this.

**Can**

- Read the blob and your app's identity.
- Make requests as your app, doing anything the key allows at the upstream.
- Use copied credentials elsewhere until they expire, unless a network rule blocks them.

**Can't**

- Get the key. The enclave masks it in responses.
- Send it anywhere but its sealed destination.
- Keep going within about 30 seconds of you removing the grant.

**What to do.** Limit the key's permissions upstream, seal with `--deny`, and on a breach run `seal revoke app`.

## Root on the enclave's host

Whoever controls the cloud account a replica runs on, Seal's or yours.

**Can**

- Stop or delete the replica.
- See who connects, when and how much.
- Control its network, so network rules don't stop them.

**Can't**

- Read the enclave's memory.
- Open a shell or attach a debugger.
- Find a key on disk. There's none.

**What to do.** Run several replicas, each listed in `SEAL_ENDPOINT`.

## Seal's servers or staff

Seal itself, someone who broke into Seal, or Seal's cloud admins.

**Can**

- Withhold your state until replicas fail closed, or replay an old one within the freshness window.
- Read your telemetry, unless you set telemetry readers.
- Create a look-alike tenant. It opens none of your blobs.

**Can't**

- Read your keys, or forge your state or telemetry.
- Grant anyone access.
- Ship a leaky enclave without it sitting in the public log first.

**What to do.** Set [telemetry readers](https://seal.zone/docs/telemetry) and run `seal status --log` now and then. See [Releases and the log](https://seal.zone/docs/releases).

## Your console account

Someone signs in as you, copies your `seal login` token, or Seal serves a malicious console page.

**Can**

- See what you see and propose changes.
- Stop Seal's replica, as an owner or manager.
- With a malicious page, show you one change and get your passkey to sign another.

**Can't**

- Sign a change. The console holds no admin keys.
- Apply a widening change before the pending window ends.
- Hide a change from the log or the CLI watching it.

**A window of 0 means trusting the console.**

New Developer tenants have no pending window, so a malicious page's change applies before anyone sees it. Set one before production.

**What to do.** Set a pending window and run `seal changes --watch` yourself.

## A stolen admin key

Someone copies a key file or takes over a passkey's account.

**Can**

- Submit changes alone, with a threshold of 1.
- Narrow access at once, such as removing your apps.
- With a threshold of 1, propose an admin list your other admins can't cancel.

**Can't**

- Apply a widening change before the pending window ends.
- Submit anything alone with a threshold of 2.
- Read a sealed key.

**What to do.** Keep two admin keys on different devices, with a threshold of 2.

## Hardening checklist

- Give each key the smallest upstream permissions, and seal with `--deny` for key-management paths.
- Use cloud identities with `seal grant network` rules.
- Keep two admin keys and a threshold of 2.
- Set a pending window.
- Run `seal changes --watch`.
- Seal with `--expires`.
- Set telemetry readers.
- Seal with the CLI, not the console.