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 they deploy.
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 capabilities and permissions, and signs with a personal key.
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 the caller-specific view.
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.
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, mirrored, or proposed by an agent at runtime, runs through these stages in order. Counts shown are from the public vault as of v0.4.1.
Gate v0.4.1 · last 30 days3,118 submissions · 11.4% rejected
STAGE / 01
YAML auto-repair
Trailing commas, mixed indentation, and unquoted special chars are fixed before the strict schema check.
passed clean2,640
repaired478
rejected0
STAGE / 02
Security denylist
Known-bad patterns: credential stealers, fork bombs, and exfiltration paths.
clean3,066
flagged52
STAGE / 03
Capability vs. behavior
Mismatch between declared tools and observed behavior is rejected.
aligned2,718
over-declared220
under-declared128
STAGE / 04
Dedup
Text similarity in V1 and embedding-space matching in V2 preview stop duplicate explosions at the door.
unique2,762
near-duplicate176
STAGE / 05
Ed25519 sign
If AutoVault admits it, AutoVault signs it and records the chain back to the author key.
signed2,762
key error0
Denylist inspector
Public, auditable, signed.
The denylist is itself a signed, versioned artifact. You can mirror it, audit it, and propose additions through public review.
SeverityIDPatternSourceAge8 of 343
Provenance chain
Every skill carries its isnad.
An isnad is a chain of transmission: who said what, who heard it, who passed it on. Each link is its own Ed25519 signature; tampering with any link breaks the chain.
LINK / 01 · author
@autoworks-ai
2026-04-28 12:14Z
LINK / 02 · gate
vault.autoworks-ai
2026-04-28 12:18Z
LINK / 03 · publish
0x9af4…2c81
2026-04-28 14:21Z
LINK / 04 · mirror
cdn.autovault.dev
2026-04-28 14:22Z
LINK / 05 · install
your machine
on demand
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 advisory, and patch-first response.
Report a vulnerability
If you found a vulnerability in the gate, CLI, renderer, or a denylist bypass, report it before public disclosure.
Emailsecurity@autoworks-aiPGP0xC4F9 7E10 A2C8 1B3DBountycase-by-case · max $5kWindow90-day coordinated disclosure
Audit & transparency
The CLI is Apache-2.0 and self-buildable from a tagged commit. The denylist is public and signed. The gate is reproducible from the same skill bytes.