Svault

The secret manager that knows an AI is asking.

Svault is an AI-aware secret access layer written in Rust. It sits between AI agents and your credentials — enforcing structured requests, detecting suspicious patterns, and making sure an agent has a real reason before it touches anything sensitive.

Why Svault? Every existing secret manager (1Password, Infisical, HashiCorp Vault) treats an AI agent the same as a human or a script. Svault doesn't. It knows the difference.

flowchart LR
    H["Human"] -->|"svault secret get<br/>(passphrase)"| V["Svault"]
    A["AI Agent"] -->|"svault get<br/>scope + reason"| P["Policy engine"]
    P -->|"allow / deny + audit"| V
    V --> E["vault.enc<br/>AES-256-GCM"]

Documentation

Quick start

# Install
cargo install svault-ai

# 1. Create an encrypted vault (interactive: storage, name, agents, auto-lock, passphrase…)
svault create

# 2. Add secrets
svault secret add DB_URL
svault secret add API_KEY

# 3. Unlock for your session (passphrase cached, not prompted again)
svault unlock

# 4. Use secrets without re-entering the passphrase
svault secret get DB_URL
svault secret list

# 5. Lock when done
svault lock

Or just run svault with no arguments for the interactive TUI.

⭐ Star us if you like the project!

Run svault with no subcommand to open the full-screen terminal UI:

svault

Browse all vaults (with live lock state), c create, u unlock / l lock, s edit settings, and — once a vault is unlocked — a add, view, and d delete secrets. The TUI reuses the cached session passphrase, so an unlocked vault is never re-prompted. Every subcommand still works for scripting.

Full keybindings → docs/tui.md

svault secret get is the human path — passphrase, no questions asked. svault get is the agent path: a structured request that an AI must justify.

svault get DB_URL --scope database --reason "run nightly migration" --caller claude-code

flowchart TD
    REQ["svault get"] --> ID["Identify caller"]
    ID --> RSN{"Reason valid?"}
    RSN -->|no| DENY["Deny + audit"]
    RSN -->|yes| CAP{"Caller holds scope<br/>& matches secret?"}
    CAP -->|no| DENY
    CAP -->|yes| TIER{"Sensitivity tier?"}
    TIER -->|high| DENY
    TIER -->|low / medium| RATE{"Within rate limit<br/>& no burst?"}
    RATE -->|no| DENY
    RATE -->|yes| ALLOW["Return value + audit"]

Policy lives in a committable svault.policy.yaml (no secrets inside). high-tier secrets are never handed to an agent.

Full pipeline, YAML schema, tiers → docs/policy-engine.md

The chosen backend is recorded in meta.yaml and shown as a storage:name prefix everywhere a vault is listed. Vault names must be unique.

Details → docs/storage-backends.md

The passphrase is the only key.

Threat model + on-disk layout → docs/security.md

flowchart TD
    U["AI Agent / User"] -->|"svault_get_secret(name, scope, reason)"| D["Svault"]
    D --> AUTH["Multi-factor auth<br/>Passphrase · YubiKey · TOTP · Touch ID"]
    AUTH --> POL["Policy checks<br/>reason → capability → rate limit<br/>burst detection · audit log"]
    POL --> TIER["Sensitivity tier enforcement"]
    TIER --> ENC["(.svault/&lt;vault&gt;/vault.enc<br/>AES-256-GCM encrypted)"]

Auth methods, full layout → docs/architecture.md

Roadmap

Full roadmap → docs/roadmap.md

Tests

cargo test

34 tests covering: roundtrip encryption, wrong-key rejection, bit-flip authentication failure, distinct salts → distinct keys, vault create/open, wrong passphrase, add/get/list/remove, persistence across reopen, tampered vault.enc rejected, tampered meta.yaml rejected, session unlock/lock/lock-all, passphrase strength checks, audit record/read, rate-limit parsing, the policy engine (capability, tiers, rate limit, burst, unknown caller, fallback mode), and storage-backend metadata roundtrip.

CI runs the suite on Ubuntu, Fedora, macOS, and Windows on every push and pull request.

License

Apache 2.0 — see LICENSE.

Built by Soluzy.