Prompt Licensing and Marketplaces, in depth: delivery models, threat model, machine-readable licences, fingerprints, canaries and intake review

Two delivery models

In text delivery the buyer receives the prompt and runs it on any model. The buyer can read and audit it, which protects them from hidden behaviour, but nothing technical stops them copying or reselling it; protection rests on the licence contract, the marketplace's terms and detection after the fact. In hosted execution the prompt stays on the server and the buyer sends inputs and receives outputs. The author keeps the text secret, but the buyer cannot see what instructions are processing their data, and the model itself becomes a channel through which the prompt can leak.

Hosted prompts leak more easily than authors expect. A system prompt is in the model's context, and the techniques in Prompt Stealing and System Prompt Leakage recover it with direct requests, role-play, translation or formatting tricks. Published studies of custom assistants on public stores have reported that many could be made to reveal their instructions and attached files. Treat a hosted prompt as confidential but not secret: something you protect with layered controls and monitor, not something whose value depends on nobody ever seeing it.

Threat model

Notice that half the rows harm the buyer, not the author. A marketplace that only thinks about piracy misses that a bought prompt is untrusted code in natural language: it runs with whatever tools, data and credentials the buyer's application gives the model.

What a licence can do, and a machine-readable manifest

A prompt licence is a contract, and its job is to make expectations explicit and violations provable. Useful terms are concrete: whether the buyer may modify the prompt, use it in commercial products, embed it in a product that other people use, or resell it; how many seats or deployments are covered; whether attribution is required; which model families it was tested on; and what the author warrants about its behaviour, usually very little. The general mechanics of software and model licences, and how they interact with AI outputs, are covered in AI Licences.

Make the licence machine-readable so systems can enforce it. A manifest shipped with every prompt lets the buyer's deployment check its terms and lets the marketplace match a leaked copy back to a licence:

{
  "prompt_id": "pm-7f3a2c",
  "version": "1.4.0",
  "sha256": "9b1e...c04d",
  "author": "author-1182",
  "licence": {
    "type": "commercial-single-product",
    "modify": true,
    "resell": false,
    "max_deployments": 1,
    "attribution": false
  },
  "tested_models": ["model-family-a", "model-family-b"],
  "tools_required": [],
  "data_access": "none",
  "issued_to": "buyer-55210",
  "fingerprint_id": "fp-91c7",
  "signature": "ed25519:..."
}

The signature covers the prompt hash and the licence block, so neither can be altered without detection. issued_to and fingerprint_id tie this copy to one buyer, which matters for the next section.

Fingerprints and canaries

Fingerprinting gives each buyer a slightly different copy so a leak identifies its source. For text delivery, the copies can differ in harmless choices: synonym selection, ordering of independent rules, punctuation, or a unique example value. The marketplace stores the variant map and, when a copy appears elsewhere, compares it with every issued variant. This survives verbatim copying and light edits; a determined paraphrase defeats it, which is why it is a detection tool, not a lock. The output-watermarking ideas in AI Watermarking are related but different: they mark generated text, not the instructions.

For hosted execution, canaries are the analogue. Put a unique, meaningless token in the system prompt and instruct the model never to output it; then scan every response and alert when it appears, because its presence means the prompt is being disclosed. Canaries do not stop a careful attacker who asks for a paraphrase, so pair them with similarity checks between responses and the prompt text.

import hashlib, hmac, re

def make_canary(secret: bytes, prompt_id: str, buyer: str) -> str:
    tag = hmac.new(secret, f"{prompt_id}:{buyer}".encode(), hashlib.sha256).hexdigest()[:12]
    return f"zx-{tag}"

def shingles(text: str, n: int = 6) -> set:
    words = re.findall(r"\w+", text.lower())
    return {" ".join(words[i:i + n]) for i in range(max(0, len(words) - n + 1))}

def leak_score(response: str, prompt: str, canary: str) -> float:
    if canary in response:
        return 1.0
    p, r = shingles(prompt), shingles(response)
    return len(p & r) / len(p) if p else 0.0

def guard_response(response, prompt, canary, threshold=0.15):
    score = leak_score(response, prompt, canary)
    if score >= threshold:
        return "I can't share my configuration.", score   # block and log
    return response, score

The six-word shingle overlap catches verbatim and near-verbatim disclosure; the threshold should be tuned on real traffic, because a prompt that quotes common phrases will overlap with ordinary answers. Log every block with the buyer, session and score, and rate-limit sessions that trigger repeatedly, since extraction attempts are usually iterative.

A marketplace intake pipeline

The marketplace's intake pipeline is where both sides can be protected. A reasonable sequence for every submission and every new version:

1. Normalise and hash. Strip invisible characters, normalise Unicode and record the hash. Hidden zero-width or tag characters are a known way to smuggle instructions past reviewers.
2. Duplicate and provenance check. Compare against the catalogue with exact hashes and semantic embeddings. A near-duplicate of an existing listing from a different seller goes to review, with the earlier timestamp as evidence.
3. Behaviour scan. Search for instructions to contact URLs, call tools not declared in the manifest, request credentials or personal data, encode output, or ignore the buyer's own system prompt. The scanners and classifiers used for prompt injection apply directly.
4. Sandboxed test runs. Execute the prompt against the declared models with benign and adversarial inputs, with tools stubbed and network egress logged. Undeclared egress is a rejection.
5. Sign and publish. Sign the manifest, assign a version, and record the change log against the previous version so buyers can see exactly what changed.

Running a purchased prompt safely

If you buy or install a third-party prompt, treat it as untrusted input to your system, not as trusted configuration. Read it, or require the marketplace to show you the behaviour report if it is hosted. Run it with least privilege: only the tools it declares, no access to secrets, and outputs that pass through the same filters as any user-influenced text. Pin a version and re-review on update, because a hosted prompt that changes silently is a supply-chain change in your product. Keep your own system prompt separate and higher in priority, as described in Prompt Isolation, so a purchased template cannot override your safety instructions.

Worked example. A support team buys a hosted refund-assistant prompt. The behaviour report shows it declares one tool, lookup_order, but in sandbox runs it also emits markdown image links to an external domain containing the order ID in the URL. Rendered by a chat client, those images would send customer order IDs to a third party on every reply. Intake should have rejected it on undeclared egress; the buyer's own output filter, which strips external image URLs, is the second line that catches it. The lesson is that both controls are needed, because either one alone fails the first time it has a gap.

Responding to a leak and measuring the programme

Leaks will happen, so decide the response before the first one. When a copy of a prompt turns up on another listing, a forum or a competitor's product, the sequence is: capture the evidence with a timestamp, match it against issued fingerprints to find the source licence, and compare it with the catalogue to see whether it is verbatim, lightly edited or a paraphrase. A fingerprint match gives the marketplace grounds to act on the licence that leaked it, by suspending the buyer, revoking hosted access or invoking contract terms. A paraphrase with no fingerprint usually leaves only the takedown process of the platform where it appeared, and its outcome is uncertain.

For hosted prompts, the response is mostly operational. Rotate the canary so future leaks are distinguishable from the old one, review the sessions that triggered leak scores to learn which technique worked, add that technique to the regression tests, and decide whether the prompt needs restructuring, for example moving sensitive logic into tool code the model cannot recite. Instructions that encode real business rules, pricing logic or proprietary data are better kept outside the prompt altogether, because anything in the context window can eventually be repeated; Confidential Prompts covers that design pattern in more detail.

Track a few numbers so the programme can be judged: leak-filter blocks per thousand sessions, the share of blocks confirmed as real extraction attempts on review, intake rejection rates by reason, time from leak report to action, and the number of listings removed as duplicates. A rising block rate on one prompt is an early warning that an extraction technique is spreading; a high false-positive share means the threshold is hurting ordinary users and needs retuning.

Failure modes

• Relying on secrecy of hosted prompts. Extraction is routine. Value should come from quality, updates and integration, with secrecy as one layer.
• Licences without technical hooks. Terms nobody can check are rarely enforced. Ship manifests, signatures and fingerprints.
• Canary false confidence. A paraphrased leak never contains the canary. Add similarity scoring.
• Over-aggressive leak filters. Blocking every answer that shares phrases with the prompt breaks legitimate help. Tune thresholds on real traffic and review blocks.
• Trusting reviewed prompts forever. Review applies to one version. Re-scan every update.
• Ignoring the buyer's risk. A marketplace that scans only for piracy ships hidden instructions and exfiltration to its customers.

Trade-offs

What to do next

1. Decide per product whether you deliver text or host execution, and write down which party bears which risk.
2. Define a machine-readable licence manifest and sign it with the prompt hash.
3. Add a canary and a shingle-overlap leak check to every hosted prompt's response path.
4. Build intake checks for invisible characters, near-duplicates, undeclared tools and egress.
5. As a buyer, run purchased prompts with declared tools only, pinned versions and your normal output filters.
6. Review the extraction techniques against your own hosted prompts quarterly and record which ones work.