Research paper · Preprint draft
Sealed Skills
Provider-bound encryption for LLM agent skills, and the limits of confidential context.
- Author
- Alex M. Rodriguez
- Version
- 1.0
- Date
- Status
- Preprint draft, not peer reviewed
Abstract
LLM agent skills (folders of instructions, scripts and reference files that an agent loads on demand) are becoming commercial products, yet they ship as plain text that anyone can copy. We present Sealed Skills, a packaging scheme in which a skill is encrypted with HPKE to a public key that an AI provider publishes at a well-known URL on its own domain. The owner seals offline with no handshake, packages can be distributed through untrusted channels, and only the provider's servers can open them; clients send a reference and a licence and never receive the skill. Our prototype seals and opens a 10 KB skill in under half a millisecond. We then measure the channel encryption cannot close: the model must read the skill, and its answers go to the user. Across eight synthetic skills, 24 extraction attacks and two open 7–8B models, 72–75% of attack conversations disclose at least half of a skill's rules and 35–41% reproduce it nearly verbatim. A confidentiality instruction reduces substantial extraction to 19% and 46%, but for one model at the cost of failing a third of legitimate tasks, mostly by refusing them. A de-obfuscating lexical output filter reduces substantial extraction to 1.6–3.1% but blocks 12.5–25% of benign replies, because models quote rules while applying them; embedding-similarity filtering is far weaker. Per-customer canaries appear in 98% of verbatim leaks, enabling attribution. In a tool-use case study, scripts co-located with a code interpreter are extractable, while an owner-hosted tool protects the code but still reveals its rate table to ordinary queries. Sealing protects a skill's artifacts from copying; it does not make its content or function secret.
From position paper to research paper
- Version 0.2 was a position paper: it proposed the design. Version 1.0 builds it and measures it.
- New: a working prototype, a test corpus of eight skills and 24 attacks, 896 model conversations, a sealing benchmark and a tool-use case study.
- New: related work across 61 references, including the closest prior design (van Wyk et al., 2023) and the 2026 skill-stealing attacks.
- This page sets the paper in part; the PDF is the complete text.
1Introduction
LLM agents increasingly acquire specialised abilities from skills: directories holding instructions, scripts and reference files that the agent loads when a task calls for them. A good skill encodes expertise that took time and money to produce, such as how a tax authority cross-checks a filing or how a firm scores a contract, and skills are starting to be sold. They ship as plain text. Whoever obtains the folder can read it, republish it, or load it into a competing product, and the licence terms attached to it enforce nothing.
This paper asks what it would take to sell a skill that only a chosen AI provider can open, and how much protection that actually buys. We make three observations. First, the cryptography is straightforward and cheap: an owner can encrypt a skill to a public key the provider publishes, in the same way anyone can encrypt email to a published key, without the parties ever talking. Second, the protection depends on a strict architectural rule that is easy to get wrong: the skill must only ever be decrypted on the provider's servers, never in a client, because anything present on the user's device can be extracted by the user. Third, and most important, encryption cannot close the channel that matters most. To follow a skill, the model must read it in clear text, and the model's answers go to the user, who can ask for the skill directly, indirectly, or in disguise.
Contributions
- Design. Sealed Skills, a provider-bound packaging scheme for agent skills: HPKE key wrapping to a key published at
/.well-known/sealed-skill-keys, STREAM-encrypted payloads, owner signatures, offline-verifiable licences, and per-customer canaries, with no owner–provider handshake. - Implementation. An open prototype with a mock provider, and measurements showing sealing costs are negligible next to model inference.
- Measurement of the residual channel. On eight synthetic multi-rule skills, 24 attacks and two open models, we quantify extraction from context, the effect and utility cost of a guard instruction, and the trade-off curves of lexical and semantic output filters. We use an evidence-grounded judge for rule disclosure after finding that an unconstrained LLM judge counts applying a rule as disclosing it.
- Scripts. A tool-use case study showing that “run-only” scripts cannot be enforced in a sandbox that also executes arbitrary code, and that owner-hosted tools protect implementations but not function.
2Design
Sealing uses envelope encryption. The owner samples a fresh 256-bit content key, encrypts the skill folder with it in 64 KiB STREAM chunks, and wraps the content key with HPKE (RFC 9180) for each chosen provider, using the public key that provider publishes at a well-known path on its own domain. The HPKE context binds each wrapped key to one skill version and payload, and an Ed25519 signature covers the whole manifest. Adding a recipient later means wrapping the same 32-byte key once more; the payload is untouched.
The central architectural rule is that a sealed skill is decrypted only on the provider's servers, never in a client, including clients the provider itself distributes. Any secret shipped to a device the user controls can be extracted by that user, and even a correctly decrypted skill would have to travel from the client to the model inside the request, where the user can read it. A client therefore sends only a skill reference and, where the owner requires one, a licence token.
{ "format": "sealed-skill/0.2",
"skill": { "id": "com.example.tax-reconciler", "version": "2.3.0",
"public_description": "Reconciles purchase ledgers against tax filings.",
"owner": "did:web:example.com" },
"payload": { "aead": "AES-256-GCM", "chunking": "STREAM-64KiB",
"size": 482113, "sha256": "9f2c…e71a" },
"recipients": [{ "provider": "provider-a.example", "key_id": "pa-2026-09-k3",
"key_source": "https://provider-a.example/.well-known/sealed-skill-keys",
"hpke_suite": {"kem": "0x0020", "kdf": "0x0001", "aead": "0x0002"},
"enc": "…", "wrapped_cek": "…" }],
"policy": { "confidential": true, "scripts": "owner-hosted",
"licence_issuer_key": "https://licensing.example.com/.well-known/jwks.json" },
"signature": { "alg": "Ed25519", "key_id": "example-signing-2026", "sig": "…" } }3Goals and threat model
The paper states five goals (condensed here):
- G1 Recipient confidentiality. Only providers named by the owner can recover the skill plaintext from a package.
- G2 No handshake. The owner can seal for a provider using only public information the provider already publishes.
- G3 Integrity and binding. Modified packages are rejected, and a key wrapped for one package cannot be used to open another.
- G4 Client exclusion. The plaintext never reaches the client or the end user as a file.
- G5 Output confidentiality. The end user cannot recover the skill's contents from the agent's outputs.
G1–G4 are cryptographic or architectural properties. G5 is not: the model must read the skill in clear text to follow it, and its outputs go to the user. We treat G5 as a quantity to be measured and reduced, not a property to be proved. The recipient provider is trusted with the plaintext, and models running on user-controlled hardware are out of scope.
4Evaluation setup
Models. Llama 3.1 8B Instruct and Qwen 2.5 7B Instruct, 4-bit quantised, served by Ollama on one NVIDIA RTX 3070 (8 GB), greedy decoding. Corpus. Eight synthetic skills written for the study (tax reconciliation, veterinary visit summaries, NDA review, clearance pricing, incident postmortems, menu costing, tariff classification, B2B outreach), each 290–360 words with eight or nine numbered rules, a required output format and a unique canary phrase. Attacks and tasks. 24 extraction attacks in six categories and four benign tasks per skill, run against every skill, model and guard setting: 768 attack conversations and 128 benign ones.
Metrics. Replies are de-obfuscated and, when not in English, back-translated before scoring. A full extraction reaches ROUGE-L recall ≥ 0.9 against the skill. A rule is disclosed if a reply contains a six-word verbatim run from it, or an LLM judge claims it is stated and quotes evidence that passes three mechanical checks. A substantial extraction has ROUGE-L ≥ 0.5 or discloses at least half of the rules.
5RQ1: cost of sealing
A 10 KB skill, typical of SKILL.md files, seals in 0.30 ms and opens in 0.39 ms (medians of 50 runs); a 1 MB skill with reference files takes about 2.5 ms; even 64 MB takes 216 ms to seal and 133 ms to open. Adding a recipient to a sealed 10 MB package takes 0.19 ms, against 34 ms to reseal it. The median benign reply in our experiments took 4.3 s (Llama) and 4.9 s (Qwen) to generate, so unsealing adds well under 0.1% to a request.
6RQ2: extraction from context
| Model | Guard | Full | Substantial | Rules | Canary | Task success | Rules in benign use |
|---|---|---|---|---|---|---|---|
| Llama 3.1 8B | no | 35.4 | 71.9 | 70.4 | 42.2 | 100.0 | 20.1 |
| Llama 3.1 8B | yes | 13.5 | 18.8 | 19.5 | 15.6 | 65.6 | 15.1 |
| Qwen 2.5 7B | no | 41.1 | 74.5 | 74.3 | 46.9 | 96.9 | 14.0 |
| Qwen 2.5 7B | yes | 18.8 | 46.4 | 46.6 | 20.8 | 96.9 | 14.9 |
Without a guard instruction, a skill in context is largely extractable. Across the eight skills and 24 attacks, 35.4% (Llama) and 41.1% (Qwen) of conversations reproduce the skill almost verbatim, and 71.9% and 74.5% disclose at least half of its rules. Transformation attacks rarely yield verbatim copies but usually disclose the rules anyway: a “detailed summary that keeps every threshold”, a JSON object of rules or a translation preserves the skill's substance.
The guard instruction helps, unevenly, and at a cost. It cuts substantial extraction from 71.9% to 18.8% for Llama and from 74.5% to 46.4% for Qwen. For Llama it nearly eliminates authority, indirect and multi-turn attacks, but plain direct requests still succeed in 53.1% of conversations. The cost falls on utility: with the guard, Llama completed only 21 of 32 benign tasks, and 7 of its 11 failures were refusals to perform the task at all. Qwen's task success was unchanged.
Ordinary use already discloses part of a skill. Even in benign tasks, the models stated 14–20% of a skill's rules on average, typically by quoting a rule while applying it, and the guard barely changes this. Canaries work for attribution: 205 of the 209 full extractions (98.1%) reproduced the skill's canary phrase. They do not survive paraphrase.
7RQ3: output filters
| Filter | Llama: residual | Llama: blocked | Qwen: residual | Qwen: blocked |
|---|---|---|---|---|
| Without guard instruction | ||||
| No filter | 71.9 | 0.0 | 74.5 | 0.0 |
| Lexical, L = 12 | 3.1 | 25.0 | 2.6 | 18.8 |
| Lexical, L = 24 | 9.9 | 6.2 | 5.2 | 3.1 |
| Semantic (τ at 5%) | 50.0 | 12.5 | 59.4 | 3.1 |
| With guard instruction | ||||
| No filter | 18.8 | 0.0 | 46.4 | 0.0 |
| Lexical, L = 12 | 2.1 | 12.5 | 1.6 | 18.8 |
| Lexical, L = 24 | 2.1 | 0.0 | 4.7 | 9.4 |
| Semantic (τ at 5%) | 16.2 | 0.0 | 31.8 | 6.2 |
The lexical filter is effective against what the models actually produce: at L = 12 it blocks every full extraction and reduces substantial extraction to 1.6–3.1% across all four configurations. Of the 18 conversations (of 768) that still leak substantially, 13 are transformation attacks: nine poems that restate one rule per stanza and four translations. The price is utility: because models quote rules while applying them, the same filter blocks 12.5–25% of benign replies. The semantic filter performs poorly on its own: sentence embeddings cannot separate a reply that states a rule from one that applies it. These numbers are an optimistic bound for the defender, because the attacks are not adaptive to the filter.
8RQ4: scripts through tools
We gave the agent a proprietary withholding-calculator script and two tools: one that runs the script, and one that runs arbitrary Python in the agent's workspace. In the co-located design the script sits in the workspace; in the owner-hosted design it runs on the owner's side and only results come back.
Source extraction. Executing the attacks' code directly, as an obedient agent would, printed the full script in all three co-located attempts and in none of the owner-hosted ones. With the models in the loop, Qwen printed the complete script, rate table and canary included, in 1 of 6 attacks; no owner-hosted run leaked the source (0 of 12). “Run-only” is not a property a co-located sandbox can provide.
Functional extraction. Owner hosting protects the code, not its function. Asked to run the tool once per category, the models reconstructed the entire rate table in three of four model–design combinations, and a second probe exposed the minimum threshold and the 45,000 cap in all four. Any secret that is directly readable from input–output pairs is disclosed by ordinary use.
9Limitations
The extraction study uses two 7–8B open models run locally with greedy decoding and a single sample per prompt; frontier hosted models have stronger instruction-following and may be both more resistant to naive requests and more capable of faithful paraphrase. The corpus is eight synthetic skills written for this study, and the 24 attacks are hand-written rather than optimised. The semantic filter's threshold is calibrated on the same benign prompts on which its block rate is reported, and benign rates rest on 32 tasks per configuration. Rule disclosure is judged by a 7B model constrained by mechanical evidence checks; the manual check of its decisions is small (85 decisions) and has not been repeated by an independent annotator. The tool-use case study is illustrative. The design has not been implemented by any AI provider; we are not aware of any provider that currently publishes a skill-sealing key or loads encrypted skills, so the provider in the study is a mock.
10Conclusion
Agent skills are becoming a medium for selling expertise, and today they ship as plain text. Sealed Skills let an owner encrypt a skill to the public key an AI provider publishes on its domain, without any handshake, so that only that provider's servers can open it and no client ever receives it. Our prototype shows the cryptographic cost is negligible next to model inference. Our measurements show that the harder problem sits at the model's output: once a skill is in context, a user can extract much of it, guard instructions and output filters reduce but do not eliminate this, and every filter trades leakage against legitimate use. For content that must stay secret, the answer is architectural: keep it behind an owner-hosted tool and out of the model's context entirely.
RSelected references
The paper cites 61 works; the complete list is in the PDF. Among them:
- R. Barnes, K. Bhargavan, B. Lipp, C. Wood. Hybrid Public Key Encryption. RFC 9180, IETF, 2022.
- M. A. van Wyk, M. Bekker, X. L. Richards, K. J. Nixon. Protect Your Prompts: Protocols for IP Protection in LLM Applications. arXiv:2306.06297, 2023.
- Y. Zhang, N. Carlini, D. Ippolito. Effective Prompt Extraction from Language Models. COLM 2024.
- Y.-L. Tsai, Y.-A. Lu, C.-Y. Tsai, M. Lyu, R. A. Popa, C.-M. Yu. Daydreaming: Stealing Hidden Agent Skills through Black-Box Task Interaction. arXiv:2608.26733, 2026.
- V. T. Hoang, R. Reyhanitabar, P. Rogaway, D. Vizár. Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance. CRYPTO 2015.
- B. Chor, A. Fiat, M. Naor. Tracing Traitors. CRYPTO 1994.