The author
Writes the SKILL.md, declares its capabilities and permissions, signs it with a personal key. Owns what the skill claims to do.
- Honest capability declarations
- Tightest reasonable permission scope
- Keeping the signing key private
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 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.
Writes the SKILL.md, declares its capabilities and permissions, signs it with a personal key. Owns what the skill claims to do.
Validates, signs, indexes, and delivers per caller. Owns what the skill looks like when it leaves the vault.
Loads, interprets, and executes the skill within its own sandbox and tool-call boundary. Owns what the skill actually does at runtime.
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.
Frontmatter is the most common source of breakage. Trailing commas, mixed indentation, and unquoted special chars are normalized before the strict schema check.
Known-bad patterns include credential reads, pipe-to-shell installs, decoded shell execution, setuid chmod, and insecure transport flags.
Does the skill actually do what its frontmatter claims? Mismatch between declared capabilities and observed behavior is rejected.
Three tiers catch exact content matches, near-exact similarity, and functional overlap warnings before the vault fills with clones.
If AutoVault admits a skill, it writes a detached signature sidecar and records source metadata for drift checks.
The denylist is an auditable, versioned artifact under the same trust model. You can mirror it, audit it, and propose additions through public review.
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.
We treat skill-ecosystem vulnerabilities the way mature infrastructure projects do. Coordinated disclosure, public CVE assignment, advisory published with the patch.
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.
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.