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.

The problem with shipping the file

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.

The model: inputs go in, results come out

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

1. The 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.
2. The 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.
3. The 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.

"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.

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.

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.