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.
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.
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.
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.
AutoVault Cloud moves a signed catalog from your machine to the machines you admit. That is the whole job. The trust boundary does not move when a vault becomes hosted: the gate still ran on your workstation, the release was still signed by a key that stayed there, and Cloud stores the result without being able to produce one.
Sync artifacts: signed catalog and bundle objects byte for byte, enrolled device public keys with their status and hostname, and live pairing codes until they expire.
Account records: the email, name and avatar your identity provider returns, your Stripe customer and subscription ids, and the reserved namespace.
Skill drafts you submit: a draft posted from the dashboard is stored whole, body text included, and nothing reads it back yet.
No signing key, in any of them. That is the one thing Cloud is built never to hold.
A release signing key. There is no upload API and no publish button, because either one would need Cloud to hold the thing that makes a release trustworthy. Objects are placed by hand from the machine that signed them.
A device proves who it is with an Ed25519 keypair it generates locally. The private half never leaves that machine, and there is no API key to leak in its place. Every request under /v/ carries a detached signature over <METHOD>\n<pathname>\n<unix-seconds>, and a timestamp more than 300 seconds out is refused, so a captured request stops working in five minutes. Admission is a person in the browser, not a token exchange. An enrolled key that nobody has admitted reads the catalog and its own status, never a bundle: it needs the catalog to pin the publisher key before anyone has decided about it, and bundles are where skill content actually lives.
Rotating the catalog key breaks every enrolled device. A device pins catalog.public_key the first time it reads the catalog, which is what stops a compromised Cloud from swapping in releases of its own. The cost of that guarantee is real: there is no rotation path in beta, and changing the key means re-enrolling every machine.
Revoking a device is immediate for catalog and bundle reads. It does not reach back onto that machine. Skills it already pulled are files on a disk you no longer control.
Coordinated disclosure through GitHub Security Advisories. We work with you on the fix and credit you in the release notes if you want it.
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.
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.