Signed Skills: A Practical Standard for Safe, Open Agent Marketplaces

We are trying to fix the agent risk problem with app stores and terms-of-service. The risks are real; the remedy is misfit. Agents operate by composing skills. That is the layer we can sign, scope, and attest — without choking the open exchange of ideas.

Why Skills Need Signatures, Not Storefronts

The last year gave us a preview of life with agentic systems at scale. Platforms tightened gates. Verified-developer badges appeared. Marketplace policies stretched to cover a wave of small tools that can read inboxes, move money, and scrape internal wikis. It is understandable. Risk moves faster when software acts on your behalf.

But marketplaces are coarse tools. They are built to approve or reject apps as monoliths. Agents are not monoliths. An agent is a policy engine with a planner that calls into discrete skills. Those skills are code plus data plus protocol knowledge: a calendar connector, a vector search wrapper, a procurement workflow client, a PDF parser with OCR. Treating them as invisible details under a single app badge makes risk legibility worse, not better.

A signed agent skills model recognizes this structure. It asks developers to publish skills as bundles with a clear manifest and a cryptographic signature. It asks runtimes to attest which signed skill ran, under what capabilities, and with which model. It creates an auditable boundary between sentiment and fact: what a developer claims a skill does, and what it was actually allowed to do.

Why now? Because the policy instincts of large platforms are hardening, and the technical options are still open. If we wait, the answer to agent risk will calcify into proprietary plugin contracts and closed marketplaces with non-portable review cues. A neutral, technical standard can be the release valve. The right kind of friction — signing, capability scoping, runtime attestation — can convert anxious policy into enforceable guarantees while keeping the door open for research and small developers.

The alternative is not attractive: either unchecked side-loading with fragile trust, or centralized curation that collapses an agent skill marketplace into a branded shelf of approved tricks. Neither choice matches how software evolves.

What Goes In a Signed Skill Bundle

A signed skill bundle is a digestible unit of trust. It is not special packaging for its own sake. It is a way to bind identity, intention, and code into something a platform can reason about without peering into every file.

At minimum, a bundle should carry five kinds of information.

• Identity. Who signed this bundle? This could be linked to a domain, an organization certificate, or a decentralized identifier. Do not prescribe one identity system; let the signature include a pointer to an issuer and a chain the verifier accepts. Portability matters here. A university lab, a startup, and an enterprise subsidiary will not share a single trust root.

• Intention. A manifest that says what the skill claims to do. Inputs and outputs, external systems it intends to call, and classes of data it expects. This is not marketing copy; it is structured fields that a policy engine can compare against runtime behavior.

• Capability requests. Precise scopes for what the skill wants at runtime. Network domains and methods, file paths, environment variables, secrets, model classes it may invoke, cross-skill calls it may initiate, and resource budgets like time, memory, and token spend. The phrase to underline is runtime capability scoping. The skill does not get anything it did not ask for — and an operator can intersect that request with local policy.

• Provenance. Source commit digests, dependencies and their hashes, build metadata, reproducibility notes. Not every skill will be reproducibly built, but the bundle should say whether it is. A small footgun removed at the start is worth many hours of forensic work later.

• Lifecycle. Version, compatible API levels, release channel, deprecation window, and contact for security notices. It should be possible to say this skill will auto-update within a minor version, but must not cross a major boundary without explicit allow. Update semantics are part of safety, not an afterthought.

Keep the format boring. Human-readable, machine-parseable, and interchangeable across languages. JSON is fine if you accept its quirks. YAML can work if you are careful with tooling. A canonicalized serialization for signing is non-negotiable. That could be JSON Canonicalization Scheme or another well-defined method, as long as it is deterministic and widely implementable.

Signatures need a low bar to entry and a high bar for ambiguity. Do not require hardware tokens to publish a hobby skill. Do require that signatures include a clear algorithm identifier, the canonicalized manifest, and a timestamp. Support key rotation. Treat expired signatures as soft warnings for development use and hard errors for production policy, with override controls in the operator’s hands.

The code payload itself can vary. A Python wheel, a WebAssembly module, a container image, or a small TypeScript package that runs inside a sandboxed VM. Do not lock the world to one runtime. Do ask each runtime to surface how it maps requested capabilities to enforcement primitives. A WASI host can satisfy a files permission with a virtual filesystem; a container runtime can use read-only mounts; a serverless function can accept no local files at all and still comply.

All of this adds up to a bundle that a platform can ingest, inspect, and install with a clear contract. It is not about trusting a signature blindly. It is about making the contract legible and binding identity to the claims the developer wrote.

Runtime Attestation and Capability Scoping That Actually Bites

Static promises are comfortable. They are also not enough. A signed manifest is useful only when paired with a runtime that can say what actually happened. That is where skill bundle attestation comes in.

Attestation is a statement, issued by the runtime, that a specific signed skill bundle was loaded and executed under a specific policy and environment. The runtime has its own identity — separate from the developer — and signs these events. The result is a chain: developer signs intent, runtime signs execution, operator logs the junction.

There are layers to make this credible without asking everyone to deploy exotic hardware.

• Measurement. The runtime should compute and record the content hash of the bundle it executed. If the bundle includes a pointer to a container image or a WASM module, measure that too. If a build tool repacks the code, record both the original and the executed artifacts.

• Policy bind. Attach the effective capability policy at the moment of invocation. That includes the intersection of the skill’s requested scopes and the operator’s allowed scopes, plus any dynamic context like time-bounded tokens. If the skill asked for network access to api.example.com and your policy allowed only internal hosts, the attestation says network blocked. Not in vague language. As a resolved list.

• Environment claim. Capture stable environment facts that a verifier cares about: runtime version, OS baseline, key enforcement toggles, sandbox flavor. Do not pretend this is a secure enclave unless it is. If you are using TEEs, say which and include the TEE’s own attestation quote. If not, say so plainly. Honest claims keep trust rational.

• Linkage. Bind attestation to a specific request or session. Include an invocation ID, the time window, and any user consent scope. This prevents replay and lets an auditor follow the path from a user click, to agent plan, to skill call, to side effect.

• Output signoff. Optionally attach a digest of outputs for later cross-checking, with privacy controls. If the output is sensitive, log that hashing was skipped under policy. Do not leak secrets into logs in the name of provenance.

This may sound heavy. It is not when made routine. A decent runtime can emit these attestations as structured events to a transparency log. Think of Certificate Transparency, but for agent runs. Public registries might provide opt-in logs for open skills. Enterprises will keep internal logs and choose which vendors to trust for aggregation and alerting.

Attestation without enforcement is theater. So the other half is capability scoping that bites. You need real guardrails, not promises.

• Network egress. Resolve DNS inside the sandbox, enforce per-domain and per-method policies, and route through an egress proxy that can block and log. Wildcard hosts should be rare, not the default.

• Files and processes. Default no local file access. When granted, make it read-only and virtualized. No process spawning unless a policy says so, and then only to a narrow allowlist.

• Secrets. No ambient environment variables. Secrets are injected per invocation by the platform under short-lived tokens, namespaced to the skill’s identity and version. If the skill upgrades, old secrets do not automatically work.

• Model calls. Many skills will call an LLM or a vision model. Those calls should be first-class in the policy: which providers, which models or classes of models, which budget per invocation. Skills should not be able to daisy-chain indefinite tool calls to unbounded costs.

• Cross-skill calls. An agent planner may coordinate several skills. A skill should not be allowed to import or execute another skill’s code on its own. Cross-skill calls go through the runtime, which enforces the downstream skills’ scopes independently. No piggybacking.

Make the default profile harsh. Most skills do not need network or filesystem access. Grant by scope, not habit. The art here is in the developer experience — clear error messages when a policy denies a call, test harnesses that simulate production scopes locally, and templates that encourage minimal requests.

A short example grounds this. Imagine an expense-reporting agent using a corporate policy. It calls a receipt-parsing skill, a currency conversion skill, and an ERP posting skill. The parsing skill requests only image input and outputs structured JSON. No network. The conversion skill requests network to a single rates endpoint and a small token budget for a compact model call. The ERP skill requests network to a specific internal domain, a client certificate, and write access to a single API path. Each skill signs its bundle. The runtime attaches attestations for each call. If tomorrow a parsing skill update asks for network access to fetch templates, the request shows up at review with a bright flag. No guesswork.

That is how you cut risk without freezing innovation.

Updates, Revocation, and the Reality of Broken Code

No standard survives first contact with a zero-day unless it handles change. Update semantics and revocation are where good intentions go to die if left fuzzy.

Start with versions and channels. A skill should declare a version using a simple convention like semantic versioning and a release channel such as stable, beta, nightly. The manifest should state whether minor updates may auto-apply within the same channel. Operators should be able to pin a version, allow only security patches, or follow a channel with a delay window. In heavily regulated shops, a week’s quarantine before an update lands in production is not paranoia; it is culture.

Next, define how signatures relate to updates. A new bundle version is a new signed unit. Do not allow the same version number to be re-signed with different content unless a revocation record explains why. If a developer rotates keys, the bundle should include a link from old to new, signed by both keys where possible. The goal is traceability when something looks off.

Revocation needs machinery, not emails. Publish revocation lists and make them discoverable. A bundle’s manifest can include a URL for its status, but do not stop there. A shared transparency log can accept revocation entries that runtimes query on a schedule and cache. Enterprises can mirror these lists internally. For high-severity cases, allow a kill switch event that instructs runtimes to block a specific bundle hash immediately, subject to operator override for incident triage.

Consider what happens when a dependency breaks. If a bundle includes a dependency graph, a runtime can warn when a newly vulnerable library sits in the transitive tree. It may not be the skill author’s fault, but the operator needs signal. Here, an agent provenance standard can borrow from existing software supply chain practices: namespaced coordinates for dependencies, minimum metadata about licenses, and optional software bill of materials pointers that heavier shops can parse.

Now the hard case: a malicious or negligent skill author. Signing ties identity to behavior. It does not stop harm on its own. The mitigation is in scoping, review cues, and speed of reaction. Platforms can surface diffs between requested capability scopes across versions to reviewers. Researchers can spot patterns because the manifest is public. When a skill crosses a line and is revoked, the logs tell who ran it where. That is accountability with fewer guessing games.

Expect gray areas. Not every misuse is intended. A scraping skill may be fine when used on your own site but a policy violation elsewhere. A file converter might embed tracking beacons by default. The standard cannot replace judgment. It can localize damage and make conversation grounded in facts. That is worth a lot.

Governance Without Gatekeeping

Standards fail in two ways: by becoming a fig leaf for vendor policies, or by chasing theoretical purity with no path to deployment. The right course for signed agent skills is narrower. Specify the wire and the proof. Leave plenty of room for business choices and research.

A simple governance frame can work.

• The specification covers the manifest schema, canonicalization and signing rules, attestation event shape, and a small set of required capability categories. It includes a conformance test suite and sample bundles. It names a few common runtime enforcement approaches without blessing one.

• A registry of trust anchors exists, but optional. Platforms and enterprises can ship with their own lists. The registry’s job is to list who vouches for whom, not to approve skills. Think of it like a map of CAs, not an app store.

• Transparency logs are encouraged for public skills. Anyone can run one. A reference implementation is open. Runtimes can push attestation summaries to a public log when the operator opts in.

• Dispute protocols are procedural, not punitive. When a signature is misused, or a manifest is deceptive, the outcome is a published note, a revocation entry, and changes to trust lists. Keep politics out; keep artifacts in.

• Updates to the spec happen in the open with a time-boxed cadence. Add capability categories as new patterns appear. Do not rush to label every domain. The goal is interoperability, not exhaustive taxonomy.

The counter-argument is familiar: cryptographic signatures and attestations add friction that will drive small developers away and chill research. Some will say the open web of code survived with readme files and unverified packages. Why add ceremony?

Two answers. First, the default pathways can be light. Development keys with short lifetimes can be issued by platforms and rotated often. Local test harnesses can emulate attestation with a dev flag. The spec can carve out an explicit research mode where bundles are unsigned but quarantined to sandboxes with no network and synthetic data. Second, agents are not websites. They act in live systems. The harm model is closer to browser extensions and mobile permissions than to a static blog. We learned to accept signing and scoped permissions on phones because we wanted safety and portability. We can do the same here without repeating the part where stores became toll gates.

For regions betting heavily on applied AI — the Gulf is a clear example — a neutral standard also defuses a policy bind. Public agencies want to encourage research while insisting on traceability and safe integration into multi-entity environments. A focus on signed bundles and runtime proofs suits both aims: open pipelines for skills, hard requirements for provenance when those skills touch regulated data.

How Platforms, Libraries, and Enterprises Can Ship This Year

The point of a pragmatic standard is that you can implement it piecemeal and still get value. No one needs to wait for a perfect v1.0. Here is a path that keeps momentum without breaking compatibility later.

Platforms first. Start by accepting signed bundles with a bare-bones manifest. Validate the signature, display the developer identity, and expose requested capability scopes in the UI where users enable skills. Hook your existing sandboxing to a policy engine that translates scopes to enforcement rules. Emit attestation events to your internal logs with a field for future transparency log export. If you already host a plugin marketplace, allow developers to submit a signed skill in parallel with your current format, and show a small badge when attestation is enabled. Do not force developers to rewrite everything at once; offer adaptors that wrap today’s plugins as skill bundles with conservative scopes. When you assess submissions, diff requested scopes across versions and route riskier changes to deeper review.

Library authors next. Offer signing tools that are simple and safe by default. A command that initializes a manifest by inspecting imports and asking the developer a few pointed questions. A test runner that executes the skill with tight scopes and shows where it fails. A signer that stores keys in the system keystore or a developer’s cloud KMS, not in a dotfile. Hooks to CI so every release emits a signed bundle and a provenance record. Language ecosystems will vary, but a consistent surface helps: Python, JavaScript, Rust, and Go should each have a maintained library that speaks the same manifest and signature dialect. If you like to bet on common runtimes, WebAssembly is a good candidate for portability, but do not require it. Meet developers where they are and let pressure build toward more portable targets over time.

Enterprises last, because their needs tie everything together. Establish an internal signing authority for corporate skills. Issue developer certs with scoped privileges. Map capability categories to your risk taxonomy: unrestricted network equals high, domain-scoped network equals medium, no network equals low. Set default policies by environment: research sandboxes accept unsigned bundles with severe restrictions, integration environments accept signed bundles from known developers, production accepts only bundles with strong signatures and clean attestation histories. Tie attestation streams into your SIEM and incident response runbooks. Red-team against the policy: can a skill exfiltrate data through model prompts, DNS, or error channels? Treat those drills as part of onboarding a new agent team.

For regions like the UAE that often operate across multiple government entities and semi-public providers, the same discipline pays off at boundary points. One agency’s runtime attestation can be a ticket for another agency’s gateway, without leaking sensitive payloads. Skills built in one entity can travel to another with their provenance intact. That is how you keep a federated ecosystem open while respecting clear lines of responsibility.

There is also room for the messy middle where most developers live. A staff engineer maintaining a calendar sync skill can ship a signed bundle with minimal extra work and get crisper bug reports when a platform denies a scope. A researcher can publish a skill with a manifest flagged as experimental, and interested users can run it in a lab profile. An indie team can participate in multiple marketplaces without duplicating trust dances.

The economics may get healthier too. An agent skill marketplace built on a common standard is more portable. Platforms compete on ergonomics and reach, not lock-in. Developers build reputation tied to their signing identity and to real attestation trails, not just the star count of a repo. Security updates can flow faster because the wire format for revocation and update signals is common. None of this solves funding or moderation. It does give everyone better levers.

There are real trade-offs. Signing introduces ceremony. Attestation generates data that someone must store and protect. Policy engines can block legitimate novel uses when scopes are missing or poorly defined. These are engineering problems, not immovable walls. The standard’s job is to pick shapes that make the right choices easy: manifest fields that line up with real enforcement; a wire format that does not fight common logging tools; capable defaults that let newcomers publish small, safe skills without a heroic setup.

A final practical point: map what exists. Today’s agent plugins often describe their HTTP interfaces with OpenAPI, authenticate with OAuth, and rely on webhooks. Do not throw that away. A skill bundle can point to an OpenAPI document as part of its intention declaration. It can request OAuth scopes as part of its capability request, with a flag that says whether it accepts user-consent flows, server-to-server credentials, or both. Update semantics can align with existing release practices. All that changes is that the pieces sit under a signed manifest, and the runtime proves what it loaded and what it allowed.

The simplest viable v0 would specify: a manifest with identity, intention, capability scopes, provenance, and lifecycle; a canonical serialization and signature; a compact attestation event that binds bundle hash, effective scopes, runtime identity, and an invocation token; and a transparency log API that accepts signed entries and supports verifiable inclusion proofs. Everything else can be progressive seriousness. Start there. Make it boring and short. Run it in the wild for a quarter. Tighten what breaks.

We have seen this movie before. Package signing on Linux distributions. Code signing on mobile. Container image digests and admission controllers in cloud-native stacks. Certificate Transparency cooling the web’s PKI. Each succeeded where the practice anchored in developer tooling and runtime defaults, not in committees. Each stumbled where vendor control turned into rent-seeking.

The Take: Sign or Settle for Storefronts

Agentic systems will not slow down to match our comfort. We can keep pouring policy into app stores and private review queues, and watch as the real action spills into gray channels. Or we can put the signatures and the scopes at the layer where agents actually move: skills.

Signed agent skills are not a silver bullet. They are a lever that turns safety talk into enforceable, portable controls. Skill bundle attestation makes provenance something you can point to, not a faith statement. A neutral agent provenance standard keeps innovation open without asking enterprises to trust their luck.

That is the trade on the table. Either we sign skills and attest runs, or we drift into closed platforms and endless risk theater. The former feels like work worth doing. The latter is just more gates and less insight.