The life of a prompt.
From your keyboard to the enclave and back, then to the burn — with the failure mode written next to every step. Read it adversarially; that is what it was written for.
You type. Nothing has left.
The composer writes straight into an encrypted vault on your own disk, under a key derived from your passphrase with Argon2id that never leaves the session.
If you never press send, it never existed anywhere else.
- 01You type. Nothing has left.
The composer writes straight into an encrypted vault on your own disk, under a key derived from your passphrase with Argon2id that never leaves the session.
- 02The hardware is checked before it is trusted.
Your app fetches the enclave's Intel TDX quote and verifies it here: the DCAP chain is checked to the Intel root, and report_data must bind a nonce generated for this fetch.
- 03Only then is the prompt encrypted.
Sealed on your machine to an X25519 key published inside that quote-bound keyset — so it can only be opened by the exact enclave you just verified.
- 04It comes back saying where it was served.
The response carries a signed envelope naming the host that produced it. The Signed badge opens into the raw quote, the measurement, and the model that actually answered.
- 05The key dies and the receipt is signed.
Destroying the data-encryption key turns the remaining ciphertext into noise. An Ed25519 signature over the hash of what was destroyed goes into a file you keep.
Each stage, with its failure mode.
- 01
You type. Nothing has left.
The composer writes into an encrypted vault on your disk — SQLCipher underneath, with a key that came from your passphrase through Argon2id and never leaves the session. If you never press send, nothing ever existed outside this machine.
- 02
The app checks the hardware before it trusts it.
It fetches the inference enclave's attestation and verifies it here, on your device: the Intel TDX quote is parsed, its DCAP chain checked to the Intel root, and its report_data must bind a fresh nonce we generated for this fetch. A replayed recording of a valid older quote therefore fails.
- 03
Only then is the prompt encrypted — to that specific enclave.
Sealed on your machine to an X25519 key published inside the quote-bound keyset. An endpoint that is not that enclave receives ciphertext it cannot open, which is what turns a mis-route from a leak into a failure.
- 04
If it cannot be verified, nothing is sent.
There is no send-anyway path and no silent downgrade. A turn carrying something we cannot encrypt is refused. Every product like this has one decision that reveals whose interests it actually serves; this is ours.
- 05
The answer comes back saying where it was served.
Each response carries a signed envelope naming the host that produced it, and the Signed badge in the app expands into the raw quote and measurement behind it. Proving a gateway is attested is easy; proving where your particular response was served is the part that matters, and it is the part we surface.
- 06
When you burn it, the key dies and the receipt is signed.
The data-encryption key for that item is destroyed and the ciphertext becomes noise. An Ed25519 signature over the hash of what was destroyed is written to a receipt file you keep — counter-signed, where reachable, by an attested proxy running in its own enclave, and degrading honestly to a device-only receipt when it is not.
What a receipt actually contains.
A burn receipt is a small JSON file you keep. It names nothing it should not, and every field in it is checkable by someone who has never met you.
Which item was destroyed. Not its contents — those are already gone.
When the key was zeroed, in UTC.
Ed25519 over the canonical JSON payload, from your own signing key.
A second, independent signature over the same canonical bytes, from an attested proxy — so the burn was witnessed by something other than the device claiming it.
SHA-256 of the enclave's attestation quote. Fetch the original and re-hash it; you should get this.
A hash committing to the ordered per-response envelopes in the conversation. Pending ones are counted honestly rather than dropped to make the number look neater.
A hash over the ordered digests of the tools the agent invoked. The inputs and results burned with everything else; the commitment survives.
Silent burn. Zero footprint.
A signed receipt is evidence that something was destroyed, at a stated time, by you. There are situations where that artefact is precisely the thing you cannot afford to be holding — so burnbox can also burn without leaving one. The duress path is device-only and emits nothing at all, with no network round-trip, because a round-trip under coercion is itself a signal. The in-place shredder deliberately never signs either: a signed “destroyed” for the one operation that cannot be guaranteed would be worse than no signature.
Zero footprint is a mode you choose, not a gap we forgot to fill.
Designed to be run by someone who does not trust us.
Sync, drops and messaging pass through a relay that holds only ciphertext and opaque tokens. It decrypts nothing, stores no request logs, and keeps no IPs, paths or timings.
That is only true rather than aspirational if you do not have to use ours. So the relay is one command to stand up, its build reproduces from source byte for byte, and nothing about the product degrades when you point it at your own.
cd selfhost
BURNBOX_RELAY_DOMAIN=relay.example.com \
docker compose up -dThen verify the published image really came from that source by building it yourself and comparing the binary hash — not the image id, which carries timestamps that differ between builds.
Where the proof stops — and what we do about it.
Every claim has an edge somewhere. Most privacy products keep theirs in an internal document, which asks you to trust precisely the thing they say you should not have to. Here are ours, each one measured rather than estimated, with what it actually costs you and what is being done about it.
Encryption ends inside the enclave, not at the model weights.
Your prompt is decrypted only inside a confidential-computing enclave whose measurement your own app verified before it sent anything — Intel TDX quote parsed, DCAP chain checked to the Intel root, report_data bound to a nonce generated for that fetch.
Why it holdsWhat people mean by end-to-end is “nobody in the middle can read it”, and that holds: the middle is sealed silicon with encrypted memory, the host operator is outside the boundary, and its identity is re-checked cryptographically on every turn. What we will not do is stretch the phrase far enough to imply the weights themselves hold the key.
What we are doingPrompts are already sealed to the quote-bound key on the way in, and responses are encrypted on the way back. The remaining fields are being pushed the same way.
The CPU side is verified end to end. The GPU side is not yet.
The gateway asserts a GPU architecture but returns an empty attestation evidence list for it on every model we have probed, so the GPU claim cannot currently be verified by anyone.
Why it holdsThe boundary you are actually relying on is the CPU one — encrypted memory, measured boot, host operator excluded — and that verifies completely, all the way to the Intel root. GPU attestation would be additional assurance on top, not the load-bearing part of the seal.
What we are doingWe measured it rather than rounding it up, and we are raising it upstream. The client is already written to verify the evidence the day it starts appearing.
Tool-call arguments are the last unsealed field.
The gateway's response-encryption spec lists which fields a service must encrypt, and tool calls are not among them — so on an agentic turn, the model's tool arguments come back unsealed.
Why it holdsIt is bounded and it is visible. This is the return path only: your prompt went in sealed. And every tool call is itemised in the egress ledger, so you can see exactly what was called and where it went, rather than having to take our word for the scope.
What we are doingWe track the spec, and the moment tool calls are covered upstream they are covered here. Until then, per-task tool scoping lets you run an agent that cannot call the tool at all.
A relay you do not run can see who talks to whom.
Content is ciphertext it cannot open, and it stores no request logs, no IPs, no paths and no timings. But any relay, ours included, observes correspondents and timing.
Why it holdsWhich is exactly why the product is built so you never have to trust ours. The relay is one command to stand up, its build reproduces from source byte for byte so you can prove the image is the code, and nothing about burnbox degrades when you point it at your own. A relay nobody has to trust is a stronger property than a relay we promise is trustworthy.
What we are doingOnion routing and traffic padding are the next rung, for people whose threat model is the correspondence graph itself rather than its contents.
Files outside the vault can only be shredded best-effort.
On an SSD with copy-on-write and wear levelling, nobody can guarantee that an overwritten file is unrecoverable — not us, and not any other tool that says otherwise.
Why it holdsWhich is what the vault is for. Anything inside it is destroyed by zeroing its key, and that is absolute rather than best-effort: the ciphertext left behind is noise. The shredder cleans traces that were never in the vault — a bonus pass, not the mechanism.
What we are doingIt deliberately emits no receipt, because a signed “destroyed” we could not stand behind would be worse than no signature. The recommended path is one click: pull the folder into the vault, where destruction is provable.
If a measurement changes, this page changes with it. And if you ever find one quietly softened without the underlying number moving, that is your signal to stop believing the rest of the site.
Now the good news.
Everything above is what burnbox refuses to overstate. Everything it does state, you can check yourself — starting with a receipt, in your own browser, right now.