# AutoVault Security And Provenance

AutoVault does not execute skills. It validates, stores, signs, scopes, and serves skill content. The host agent executes locally inside its own tool and sandbox model.

## Trust boundary

- Authors own what the skill claims to do.
- The vault owns validation, signing, indexing, transforms, and filtered delivery.
- The agent owns runtime execution, approval prompts, and enforcement of declared permissions.
- Secret values stay outside the vault in SSH agent, Keychain, 1Password, provider CLIs, or deployment secrets. AutoVault stores skill content and secret names, not credential values.

## Validation pipeline

Every install or proposal runs through frontmatter parsing, schema validation, security scanning, capability/behavior checks, deduplication, and Ed25519 signing. Strict mode blocks denylist hits; non-strict mode can report warnings.

## Secret handling

Use requires-secrets to document required variable or credential names. Use signed bin setup actions when a skill needs interactive setup. Do not bundle .env files, SSH private keys, API tokens, or copied dashboard secrets in SKILL.md, resources, transforms, or the vault directory.

## Remote mode

Remote AutoVault serves Streamable HTTP MCP at /mcp. It uses OAuth for client registration, login, token issuance, and protected-resource metadata, then filters skill visibility for non-owner roles.

## Hosted sync

AutoVault Cloud moves a signed catalog from the owner's machine to the machines the owner admits. The trust boundary does not move when a vault becomes hosted.

- Cloud holds 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.
- It also holds account records: the email, name and avatar the identity provider returns, Stripe customer and subscription ids, and the reserved namespace.
- A skill 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.
- Cloud never holds a release signing key. There is no upload API and no publish button, because either would require Cloud to hold the thing that makes a release trustworthy. Signed objects are placed by hand from the machine that signed them.
- A device proves identity with an Ed25519 keypair generated on that machine. The private half never leaves it and there is no API key in its place.
- Every request under /v/ carries a detached signature over `<METHOD>\n<pathname>\n<unix-seconds>`. 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 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.
- Device responses are no-store and private, because they are authorized per device rather than per URL.

Two costs worth knowing before adopting hosted sync:

- A device pins catalog.public_key the first time it reads the catalog, which is what stops a compromised Cloud substituting releases of its own. There is no rotation path in beta, so changing that 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 the owner no longer controls.

## Provenance and drift

Installed skills store source sidecars and signed manifests. check_updates compares installed content against upstream sources and reports drift, including transform base drift through transform_reviews.

## License

AutoVault is MIT licensed and self-buildable from the public source repository.