What “VERIFIED” means here.
Anyone can stamp their own page with a green badge. So we hold ours to a rule: a VERIFIED chip may only appear next to a claim backed by a test that actually ran against live infrastructure — and every chip links back to the evidence. If we can't test it, we don't stamp it.
The rule behind the chip
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.
How the tests run
- Live session on the real microVM
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.
- Egress probes from inside the VM
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.
- Teardown checks
Session end is verified to destroy the VM. Per-session destroy is part of the lifecycle under test, not an assumed cleanup.
- Adversarial leak-gate checks
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.
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.