What Sovereign Mode can prove.

Ember has no designed path to workload content.

The workload runs inside an attested TEE. Platform log and system-info routes are off in the measured manifest, and no Ember credential reads enclave memory — an absence, not a policy.
Check: the measured compose on any deployment’s trust page.

An unapproved workload does not get the keys.

Sealed keys are released only to a compose whose hash is on your organization’s allowlist. The first hash is allowlisted as the contract is created under your organization’s ownership; every later one takes your owner account’s signature. Ember holds no signer.
Check: the approval contract and its transactions, linked from every trust page.

The workload reaches only declared hosts.

The egress allow-list is inlined in the measured compose and enforced default-deny; a zero-egress render carries no exit at all. Widening the list is a new measurement — a new approval.
Check: the boundary section of any trust page reads the list out of the live document.

Sealed secrets have no read-back path.

Secret values are encrypted to the enclave key at deploy. Neither the vendor nor Ember can read them back.

What Ember retains.

• Account records: organization, work emails, security-key and agent-key identifiers.
• Deployment and ceremony records: image digest, egress list, ports, contract and owner addresses, compose hashes.
• Platform status and edge-traffic metadata: a deployment is serving, when, roughly how much.
• Support correspondence you choose to send.

Nothing derived from workload content is on this list — the measured manifest gives it no way to exist.

What process served on Ember can reach.

The records above — account, deployment, platform status, traffic metadata, support mail — and the machines: Ember can be made to stop a VM. The deployment’s trust page then reports NOT RUNNING.

What it cannot produce.

Workload plaintext — no Ember-held key decrypts it — and approvals: extending an allowlist takes your owner account’s signature. Compulsion can make Ember relay a proposal; it cannot produce the approval.
Check: every approval transaction names its signing account, linked from every trust page.

A break in the TEE hardware.

Researchers have demonstrated physical-access attacks on TEE platforms, including the TDX class this runs on (tee.fail). The floor is the silicon.

Approved destinations.

A host on the measured egress list receives whatever the application sends it. The evidence proves which hostnames exist — not what a destination does with content.

Traffic shape and side channels.

Infrastructure can observe timing, volume, and that a deployment is serving.

The application itself.

Measurement identifies the approved application; it does not establish that the application is safe. The vendor’s frontend in your users’ browsers is part of the product, not of the measured workload.

Secrets in the public half of the configuration.

Plain settings are baked into the measured manifest, and the image must be pullable without credentials — both are public. Secret values belong in the sealed channel: names public, values sealed at deploy. A secret you can read on a trust page is a secret disclosed.

An egress list wider than the job.

Review every in-measure hostname. A general-purpose destination — the vendor’s own storage, say — is an approved disclosure path, and every widening takes your signature.