sealed.run

Server-side skill execution, explained

A skill marketplace that doesn't leak the skill sounds impossible: how does a skill do work for a buyer it never reaches? The answer is server-side execution. Here's the model, in plain language.

01

The problem with shipping the file

Server-side skill execution means the buyer's agent sends inputs to the marketplace's infrastructure, the skill — the prompt or SKILL.md — runs there, and only the output is returned. The skill file is never transmitted to the buyer's machine.

An AI skill — a prompt, a SKILL.md, a structured method an agent can follow — is just text. When a marketplace "delivers" a skill, it hands the buyer that text. From that moment, the seller's method is on a machine the seller doesn't control, ready to be copied, shared, or resold. We've covered why none of the after-the-fact protections work.

Server-side execution inverts the delivery: instead of moving the skill to the buyer, you move the buyer's request to the skill.

02

The model: inputs go in, results come out

Think of the skill as living inside a sealed chamber on the marketplace's infrastructure:

  • iThe buyer sends inputs. A document to rewrite, code to review, a brief to work from — whatever the skill needs. Usually it's the buyer's AI agent making the call, mid-task.
  • iiThe skill runs inside the chamber. The skill text is loaded as instructions for a model inside the seller's protected environment — never serialized into anything the buyer receives.
  • iiiThe result comes back out. The buyer gets the output: the rewritten document, the review, the deliverable. One result per call, paid per call.

The asymmetry is the whole point. An output reveals what the skill produced this time, not the method that produced it. A buyer can keep every result they paid for and still never hold the thing that makes the skill valuable.

03

"But couldn't the skill just… leak?"

This is the right question to ask, and it deserves a real answer rather than a trust-us. Two failure modes matter:

1. The model gets tricked into reciting the skill. A buyer could craft inputs designed to make the model repeat its own instructions. So output filtering isn't optional: every result is checked against the skill body before it leaves, and a response that would reveal the skill text is blocked. We run an automated check that fails loudly if the skill file could ever reach the buyer path — including the adversarial case where the model itself is prompted to emit it.

2. The execution environment phones home. If the skill runs somewhere with open network access, "server-side" is a thin promise. This is why isolation has to be enforced by infrastructure, not by instructions in a prompt. We've built and verified a version where each skill session runs inside a sealed, hardware-isolated VM that's destroyed after every session — and the VM's network is locked to exactly one destination, the model API. We didn't just configure that; we tested it from the inside: every other host is refused at the network level.

03 / 06 Guides
04

What server-side execution protects — and what it can't

It protects skills whose value is in the method: how they transform, analyze, structure, or act on the buyer's inputs. The method stays server-side forever.

It cannot protect a skill whose entire value is a fixed block of text it hands back — there, the output is the IP, and delivering the output delivers the IP. No architecture fixes that; it's a property of what's being sold. The practical guidance for sellers: sell doing, not dispensing.

Server-side execution runs in two shapes. Hosted skills take your inputs and hand back a result; nothing of yours is exposed. Connected skills do the work inside your own project under a scope you grant — and even there the method never lands on your machine. Hosted hands back a result; Connected does the work in place; neither one ever hands you the skill. A live Hosted example: Cold Email Rewriter runs at $0.14 per call — the draft goes in, the rewrite comes back, and the method that produced it stays server-side.

05

Why this unlocks per-call pricing

Once the skill stops shipping, there's nothing for the buyer to "own" — so there's nothing forcing the one-time-sale model. Each call is metered and priced individually, which is both cheaper for buyers (try a skill for cents instead of buying a file on faith) and structurally better for sellers (recurring revenue instead of one leak-prone sale). More on the per-call economics here.

06

Sell the skill. Keep the secret.

Sealed is live and early — claim the founding-seller deal while you'd be among the first skills buyers find.

Building in the open · @sealedrun