01 Checks and results
Sealed sessions execute inside a Firecracker microVM (via Vercel Sandbox), not a shared process.
The single allowed destination — the model API — is reachable from inside the VM (positive control).
Deny-all networking holds for non-allowlisted destinations (negative control).
The VM is destroyed when the session ends; nothing inside it persists between runs.
Buyers receive results, never the skill file. A standing leak-gate check fails loudly if the boundary could be crossed.
02 What this report does not claim
The verified environment is built and live-tested. Which executions route through it is an operational setting; we say “verified,” not “every call runs here,” until that's permanently true.
This report covers the sealed session — VM, network policy, teardown, and the buyer path. Billing, the website, and other surfaces are covered by our broader security practices, not by this report.
Checks are re-run as the infrastructure evolves, and this page carries the date of the most recent pass. A report that never updates is a screenshot, not a property.
03 Questions or findings
Security researchers: if you believe any result above is wrong, write to security@sealed.run — see the disclosure process in Security & data handling. Buyers and sellers with questions about what this means for your data: How containment works covers it in plain language.