01 The rule behind the chip
This chip is a citation, not a decoration. It means: the claim beside it was exercised as a real test against the live containment infrastructure, the test passed, and the result is recorded in the verification report with its date and scope.
Two kinds of evidence count. Positive controls — show the thing works (a session runs, the allowed host answers). Negative controls — show the boundary holds when something tries to cross it (a forbidden host is refused, an injected attempt to leak the skill body is blocked). A claim only gets the chip when both sides exist for it; a security property you've never attacked is a hope, not a property.
02 How the tests run
A complete sealed session runs end-to-end on the actual Firecracker infrastructure (via Vercel Sandbox) — created, exercised, and destroyed. Not a simulator, not a staging stub.
The probe runs inside a live VM and tries the network both ways: the allowlisted model API host (must connect — the positive control) and other ordinary hosts (must be refused at the network level — the negative control). The denial happens before any data could move.
Session end is verified to destroy the VM. Per-session destroy is part of the lifecycle under test, not an assumed cleanup.
An automated gate watches the buyer path and fails loudly if the skill body ever could cross it. We attack it ourselves: a deliberately prompt-injected attempt to make the model emit the body was made — and blocked. The gate runs as a standing check, not a one-off audit.
03 Found something? Tell us.
If you believe you've found a way across any boundary we stamp, we want to know more than you want to tell us. Write to security@sealed.run — see Security & data handling for our disclosure process. We don't pursue good-faith researchers; we thank them.