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 doctor · simulated
Click Verify to simulate the provenance walk. Sample output — run the real check locally.
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.
AutoVault is not a credential vault. Skill bundles can declare required secret names and signed setup actions, but secret values stay in SSH agent, Keychain, 1Password, provider CLIs, or deployment secrets.
A .env file or private key inside a skill bundle is content, not protected secret storage.
The gate, in detail
What each of the five stages actually checks.
Every skill installed, imported, proposed by an agent, or handed over through autovault add runs through these stages in order. The source implementation keeps the denylist extensible and currently documents 12 active patterns.
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 patterns12
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.
IDPatternWhat it catches12 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.
LINK / 01 · author
@autoworks-ai
2026-04-28 12:14Z
LINK / 02 · gate
vault.autoworks-ai
2026-04-28 12:18Z
LINK / 03 · admit
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 doctor <skill> · reports every broken link, doesn't block on its own
Disclosure
Found something? Tell us.
Coordinated disclosure through GitHub Security Advisories. We work with you on the fix and credit you in the release notes if you want it.
Report a vulnerability
If you've found a vulnerability in the gate, CLI, renderer, remote OAuth flow, or a denylist bypass, report it privately rather than opening a public issue.
ReportGitHub Security AdvisoriesResponsewithin 3 business daysSupportedlatest minor · pre-1.0Disclosurecoordinated · credited
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.