Security & data handling

Your data, your card, your keys.

The sealed VM is the headline — it has its own page. This one covers everything around it: what we keep, what we never keep, and how to reach us when something looks wrong.

01 Buyer inputs & outputs

Encrypted in transit, isolated in use

Inputs travel over TLS and are decrypted only inside the sealed execution environment — never parked on shared storage.

Discarded on teardown

Sealed sessions end with the VM destroyed; your inputs and intermediate state go with it. What persists is your account's usage ledger — skill, time, amount — so your receipts exist.

Never used for training, never shared with the publisher

We don't train models on your inputs or outputs, and the seller of a skill never sees what you ran through it.

02 Seller skill bodies

Encrypted at rest, structurally absent from the API

The skill body is sealed on upload and decrypted only by the execution runtime. No API response contains it — not the catalog, not the seller's own console. The public listing is built from an explicit allow-list of metadata fields.

Leak-gate on the buyer path

An automated check fails loudly if the body ever could cross to a buyer — adversarially exercised, including a prompt-injected leak attempt that was blocked. See the verification report.

Safety-screened before listing

Seller submissions are screened before publication for credential theft, malware, destructive actions, unauthorized access, network abuse, fraud, manipulative/social-scoring AI abuse, sanctions/export evasion, financial crime, document fraud, illegal-goods trafficking, weapons/explosives/CBRN abuse, sexual exploitation, privacy/surveillance abuse, safety bypasses, and physical-harm instructions. Every decision leaves a metadata-only audit event; rejections return category codes only — never the skill body. Read the prohibited-skill policy.

Never used for training

Seller bodies train nothing. They execute; that's all they do.

03 Accounts & API keys

No passwords to breach

Sign-in is a single-use emailed link that expires in 15 minutes. The sign-in form answers identically whether or not an account exists, so addresses can't be fished from it.

Keys shown once, stored hashed

Your API key is displayed exactly once when minted. After that we hold only a hash and a display prefix — we cannot show it to you again, and neither can anyone who breaches us. Rotate or revoke any time; revocation is immediate in every mode.

Abuse brakes on by default

Per-IP limits on sign-in, per-account limits on runs and checkout, and a rolling daily spend cap that pauses runs before a runaway loop empties a wallet. Errors name the cap and when it resets.

04 Payments

All card handling happens on Stripe-hosted checkout (PCI-DSS Level 1). Card numbers never touch our servers and we never store them. Wallet credits are applied by signed webhook — a request that isn't signed by Stripe is rejected. Eligible unused cash balance can be requested back under the refund & dispute policy; promotional credits are spend-only.

05 Reporting a security finding

Write to security@sealed.run with what you found and how to reproduce it. We commit to: acknowledging within 2 business days, not pursuing good-faith research, and crediting you (if you want) when the fix ships. Please don't access other users' data while demonstrating an issue — a description is enough.