Security & provenance

Signing isn't the same as safe.

A signature proves who said what, when. It does not prove the thing they said is correct or harmless. AutoVault's security model rests on three pillars: what we sign, what we don't sign, and where the trust boundary actually lives. This page is for staff engineers and security teams who want to inspect that model before local or remote MCP deployment.

autovault verify · interactive
Click Verify to walk the provenance chain for any skill in the public vault.
Trust model

Three actors. Three responsibilities. No overlap.

AutoVault explicitly does not claim to make untrusted code safe. Instead, the system splits the job into three roles. Each role has a narrow, well-defined responsibility, and we never blur the lines between them.

role / 01

The author

Writes the SKILL.md, declares its capabilities and permissions, signs it with a personal key. Owns what the skill claims to do.

SKILL.md
+ frontmatter, transformations
RESPONSIBLE FOR
  • Honest capability declarations
  • Tightest reasonable permission scope
  • Keeping the signing key private
role / 02

The vault

Validates, signs, indexes, and delivers per caller. Owns what the skill looks like when it leaves the vault.

vault sig
+ gate run record
RESPONSIBLE FOR
  • Running the five-stage gate
  • Producing a verifiable provenance chain
  • Filtering by four-axis scope
role / 03

The agent

Loads, interprets, and executes the skill within its own sandbox and tool-call boundary. Owns what the skill actually does at runtime.

runtime
+ caller sandbox
RESPONSIBLE FOR
  • Enforcing declared permission boundaries
  • Sandboxing tool invocations
  • User-facing approval prompts
AutoVault never runs skills. It serves them. The agent on your machine executes locally, with its own tools, in its own sandbox.
The gate, in detail

What each of the five stages actually checks.

Every skill installed, imported, proposed by an agent, or handed over through add-local runs through these stages in order. The source implementation keeps the denylist extensible and currently documents 8 active patterns.

Gate v0.2.0 · source syncschema · denylist · capability · dedup · sign
STAGE / 01

YAML auto-repair

Frontmatter is the most common source of breakage. Trailing commas, mixed indentation, and unquoted special chars are normalized before the strict schema check.

frontmatter parsedrequired
schema checkedzod
invalid yamlblocked
STAGE / 02

Security denylist

Known-bad patterns include credential reads, pipe-to-shell installs, decoded shell execution, setuid chmod, and insecure transport flags.

strict modeblocks
non-strict modewarns
active patterns8
STAGE / 03

Capability vs. behavior

Does the skill actually do what its frontmatter claims? Mismatch between declared capabilities and observed behavior is rejected.

network false + curlblocked
readonly + writeblocked
declared tools alignpassed
STAGE / 04

Dedup

Three tiers catch exact content matches, near-exact similarity, and functional overlap warnings before the vault fills with clones.

exact hashduplicate
near exact>=0.9
functional overlap>=0.75
STAGE / 05

Ed25519 sign

If AutoVault admits a skill, it writes a detached signature sidecar and records source metadata for drift checks.

stored skillsigned
source sidecarhash
tamper checkwarns
Denylist inspector

Public, auditable, signed.

The denylist is an auditable, versioned artifact under the same trust model. You can mirror it, audit it, and propose additions through public review.

SeverityIDPatternSourceAge8 shown
Provenance chain

Every skill carries its isnad.

An "isnad" is a chain of transmission — who said what, who heard it, who passed it on. Every signed skill in AutoVault carries one. Each link is its own ed25519 signature; tampering with any link breaks the chain.

autovault verify --chain · any link broken = full rejection
Disclosure

Found something? Tell us.

We treat skill-ecosystem vulnerabilities the way mature infrastructure projects do. Coordinated disclosure, public CVE assignment, advisory published with the patch.

Report a vulnerability

If you've found a vulnerability in the gate, CLI, renderer, remote OAuth flow, or a denylist bypass, please report it before public disclosure. We respond within 48 hours and ship critical fixes within 7 days.

Emailsecurity@autoworks-aiPGP0xC4F9 7E10 A2C8 1B3DBountycase-by-case · max $5kWindow90-day coordinated disclosure

Audit & transparency

The CLI is MIT licensed and self-buildable from a tagged commit. The denylist is public and versioned. The gate is reproducible: given the same skill bytes you should always get the same verdict.

LicenseMITReproducibleyes · gate v0.2+External auditscheduled · Q3 2026SBOMCycloneDX · per release