Skip to main content

Skill Vault

A signed, scanned, content-addressed registry for every SKILL.md your agents load.

Agents are increasingly shipping with SKILL.md files — task-specific instructions, tool examples, and domain knowledge that gets injected into context when a matching task arrives. That's a powerful pattern. It's also a supply-chain problem waiting to happen: a malicious or compromised skill can inject prompts, leak secrets, or steer the agent toward unapproved tools. The Skill Vault is how you stop trusting skills and start verifying them.

The Signing Lifecycle​

Skill Lifecycle — Signed, Scanned, Revocable

AUTHORSKILL.md + assetsstep 1SCANsecrets · prompts · syscallsstep 2SIGNcontent hash + org keystep 3PUBLISHVault registrystep 4CONSUMEagent loads signed skillstep 5REVOKEblocklist hash · cascadestep 6content_hash = sha256(SKILL.md || asset_tree); signature = sign(content_hash, org_private_key)

Every skill passes through six stages:

  1. Author — someone writes SKILL.md and its supporting assets.
  2. Scan — the vault scans for hard-coded secrets, prompt-injection patterns, suspicious shell invocations, dependency footprint, and known-bad templates.
  3. Sign — a passing skill is content-addressed (sha256(SKILL.md || asset_tree)) and signed with the organization's private key.
  4. Publish — the signed skill is registered in the vault. A unique skill_id + version identifies it.
  5. Consume — agents load skills through GET /v1/skills/:id which returns the signed bundle; the agent verifies the signature before injecting into context.
  6. Revoke — if a vulnerability is found later, the content hash is blocklisted. Every agent currently loading that skill is notified on the next load attempt.

Nothing unsigned reaches an agent. Nothing whose signature fails verification reaches an agent. Nothing whose hash is blocklisted reaches an agent.

The Scan Surface​

The scanner catches:

ClassExamples
Hard-coded secretsOpenAI / Anthropic / AWS / Stripe API keys, JWT tokens, database URLs with embedded credentials
Prompt injection\"Ignore previous instructions…\", role-break markers, system-prompt override patterns
Shell payloadSuspicious sh -c, `curl
Tool escalationSkill examples that call tools outside the agent's normal scope without justification
Data exfiltrationSkills that route output to external hosts, write to unexpected paths, or exfil via DNS
Template abuseKnown-bad skill patterns from the Trinitite threat feed

A skill that fails any class goes to quarantine, not publication.

The Quarantine Path​

Quarantine Lifecycle — When a Scan Fails

SUBMITTEDscan queuedSCANNINGpatterns · prompts · depsQUARANTINEDcritical finding detectedTRIAGEoperator review + remediateCLEAREDremediated · rescan passedPURGEDunremediable · hash blocklistedRevocation cascades — every agent currently loading the revoked skill is notified and blocked on next load.

A quarantined skill doesn't silently disappear. It enters a triage queue: operators review the finding, decide whether it's a false positive or remediable, and either clear it back to the signing path or purge it permanently with the hash added to the organization's blocklist.

A purged skill's content hash remains blocklisted forever. If the same content is ever re-submitted — under a different filename, from a different author, via a different integration — the scanner recognizes the hash and blocks it at intake.

Consumption Is Verifiable​

When an agent loads a skill, the response contains the signature envelope:

{
  "skill_id":     "skl_…",
  "version":      "2026.05.01",
  "content":      "…",
  "assets":       [{"path":"example.sh","hash":"sha256:…"}],
  "content_hash": "sha256:…",
  "signature": {
    "kid":   "org-key-2026-q2",
    "alg":   "Ed25519",
    "value": "base64:…"
  },
  "scan_record":  "scn_…",
  "ledger_block": "blk_…"
}

The agent SDK verifies:

  1. The signature matches the content hash under the signing key (published at the public JWKS endpoint — see Identity & RBAC).
  2. The content hash is not on the revocation blocklist.
  3. The skill's tier/scope matches the agent's authorized surface.

If any check fails, the skill is refused with a specific error code. Agents never load skills without cryptographic provenance.

Revocation Cascades​

When an operator revokes a skill:

  • The content hash enters the revocation list.
  • The revocation list is published at an unauthenticated endpoint for third-party verification.
  • Every agent that has loaded the skill in the last TTL is marked to re-verify on next load.
  • Ledger entries for past usages remain — revocation doesn't rewrite history.
  • Related alert fires to the configured incident pipeline.

This is supply-chain revocation that actually reaches the consumer, not just a registry flag that nobody watches.

What You Get​

CapabilityUnsigned skill shippingSkill Vault
Intake hygieneManual review (or none)Automated scan for 6+ threat classes
Tamper detectionNoneContent-addressed hashing
AuthenticityTrust source folderOrg-signed with public verification
RevocationDeploy removal (agents cached)Cascade to live agents on next load
ProvenanceFilename / pathskill_id + version + content_hash + scan_record
AuditScatteredEvery load event in the ledger

Next Steps​

→ CLI Firewall — the sister surface for governing commands skills may tell agents to run.

→ Glass Box Ledger — where every scan, signature, consumption, and revocation is anchored.

→ Identity & RBAC — the signing key publication and public verification story.

Last updated on