Where your run actually happens.

Enforced by the infrastructure, not by instructions.

Sealed asks you to do two unusual things: put a card on file, and send your inputs into someone else's execution environment. This page explains, plainly, what that environment is — and what physically can't happen inside it. It describes a Connected run, where the skill works on files in your project under a scope you grant. A Hosted run — you send inputs, you get output back — doesn't spin up this VM; there the body runs server-side and the output is leak-scanned before it reaches you. Neither mode ever hands the buyer the file.

01

The Connected sealed VM, in one minute

When a Connected run executes, the skill and your inputs meet inside a real, hardware-isolated micro virtual machine (Firecracker, via Vercel Sandbox) — not a shared process, not a container pretending to be one. The VM is created for the session, and when the session ends, it is destroyed. Nothing inside it persists.

While it lives, the VM's network is deny-all with exactly one allowed destination: the model API. Not a firewall rule someone remembered to set — a network policy applied at VM creation. We didn't just configure that; we tested it from the inside. From within a live VM, the allowed host answers, and every other host is refused at the network level.

That's the difference we mean by our one-line summary: many products promise containment in a prompt — text asking a model to behave. Ours is enforced by the infrastructure, not by instructions. A microVM with one network exit doesn't have opinions about exfiltration; it has a routing table.

02

The four claims, each one tested

Hardware-isolated microVM VERIFIED Sealed Connected sessions execute inside a Firecracker microVM via Vercel Sandbox. We've run full sessions on this infrastructure live and verified the boundary.

Egress locked to exactly one host VERIFIED Deny-all networking with a single allowlisted destination — the model API. Tested from inside a live VM: the allowed host completes a connection; every other host we probed is refused at the network level, before any data could move.

Destroyed after every session VERIFIED Teardown is part of the session lifecycle, not a cleanup job. When your Connected run ends the VM is destroyed — your inputs, intermediate files, and any state go with it.

The skill file never reaches the buyer VERIFIED The skill body never enters the buyer path — buyers get results, never the file. An automated leak-gate check runs against this boundary and fails loudly if it ever could cross. It has caught and blocked a deliberately prompt-injected attempt to make the model emit the body.

03

What this means for your data

Encrypted in transit, isolated in use
For a Connected run, your inputs travel over TLS and are decrypted only inside the sealed VM — never on shared storage.
Discarded on teardown
Connected per-session destroy means your contract, your query, your archive — gone with the VM when the run ends.
Never used for training, never shared with the publisher
We don't train on your inputs or outputs, and the seller never sees what you ran. Full detail in Security & data handling.

04

And for sellers

The same boundary protects the other side of the marketplace. Your skill body is encrypted at rest and decrypted only by the execution runtime. It never appears in any API response — buyers get results, you get earnings, and the file itself stays sealed. That's the product: the result, never the file.