The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Vaultguard listing page.

🔐 vaultguard
Your Obsidian vault, guarded for your AI agents.
npx @ashishrao-4/vaultguard init · zero dependencies · pure Node · cross-platform
Your AI agents are powerful. They ship code, run commands, and one day they will ask: "give me the database URL."
You hand it over. Now that value lives in every transcript, log, checkpoint, and backup of your conversations. Rotate it a month later — a year later — and the old one is still out there.
The vault itself — Obsidian — is encrypted only if you make it so, and your agent reading your notes means your agent reading your secrets.
Secrets live in your Obsidian vault as AES-256-GCM ciphertext. Your agents get them by name over MCP — they run commands with the values injected into the environment and never see them, while every access is audited.

The simple version: your agent asks by name, vaultguard decrypts on demand, the value stays out of the conversation.
It asks for a passphrase — the key that encrypts and decrypts every block in this vault. Then it:
Secrets.md in your vault,~/.vaultguard/config.json — without the passphrase (you provide it via VAULTGUARD_PASSPHRASE).Restart Obsidian and enable the plugin: Settings → Community plugins → Inline Secret Block → Enable.
The passphrase is never written to disk by default. Prefer env vars:
VAULTGUARD_PASSPHRASE(orDOORMAN_PASSPHRASE). If you want it conveniently stored anyway — at the cost of weaker security — runvaultguard init --store-passphraseinstead (see Threat model).
In Obsidian, open Secrets.md and add a plaintext block:
Click Show — the plugin instantly replaces it with an encrypted secret-lock block. Your raw value is gone; what remains:
That's it. Same value, later, forever: click Show again.
No Obsidian? Use the CLI instead:
prints ready-made config for your harness:
opencode — in opencode.json (or globally via the app):
Claude Code:
Cursor: add the same server to your project's .cursor/mcp.json (or the MCP settings tab):
run_with_secret — secrets injected into the command's environment only.[REDACTED:NAME].get_secret — disabled by default so values never reach the agent; opt in with allowGetSecret: true in the config if a tool insists on the raw value.| Layer | What stops it |
|---|---|
| At rest | AES-256-GCM, PBKDF2-SHA-256 (250,000 iterations, 16-byte salt, fresh 12-byte IV per value). Byte-compatible with the Inline Secret Block plugin. |
| Approval gate | run_with_secret is denied by default unless you set requireApproval: false (or VAULTGUARD_REQUIRE_APPROVAL=0). |
| Secret access gate | get_secret is disabled by default — values never reach the agent; enable only via allowGetSecret: true. The intended path is run_with_secret (env injection, values never seen). |
| Host allowlist | Only named clients (from MCP clientInfo) may call tools. Empty list = allow all. |
| Command allowlist | Only command prefixes you list may run (e.g. ["psql", "node", "git"]). Empty = allow all. |
| Audit log | Every call — who (host), what, which secrets, outcome — appended to ~/.vaultguard/audit.jsonl. View with vaultguard audit. |
| Output scrubbing | Secret values and their first 8 chars are redacted from command output. |
Edit ~/.vaultguard/config.json:
The only way the passphrase lands in this file is vaultguard init --store-passphrase,
which sets "storePassphraseOnDisk": true and includes "passphrase". Everything else reads
the passphrase from the VAULTGUARD_PASSPHRASE env var or the CLI prompt.
| Env var | Overrides |
|---|---|
VAULTGUARD_VAULT_PATH / VAULT_PATH | vault path |
VAULTGUARD_PASSPHRASE / DOORMAN_PASSPHRASE | passphrase |
VAULTGUARD_HOME | config dir (default ~/.vaultguard) |
VAULTGUARD_REQUIRE_APPROVAL=0 | auto-approve |
VAULTGUARD_AUDIT=0 | disable audit |
VAULTGUARD_ALLOW_GET_SECRET=1 | enable get_secret (default: off) |
Passphrase hygiene: vaultguard never writes the passphrase to disk unless you opt in (
init --store-passphrase). SupplyVAULTGUARD_PASSPHRASEin each harness config (see step 4) and protect~/.vaultguardlike an SSH key. Changed passphrase?vaultguard rekeyre-encrypts every block, then update the env var wherever you set it.
| Command | What it does |
|---|---|
vaultguard init | Configure vault + passphrase, create Secrets.md, install plugin |
vaultguard add <NAME> | Encrypt + store a new secret (interactive or --value) |
vaultguard set <NAME> | Rotate a secret in place |
vaultguard rekey | Re-encrypt every block with a new passphrase (interactive, or --old-passphrase/--new-passphrase) |
vaultguard list | List secret names (no values) |
vaultguard audit [--lines n] | Tail the audit log |
vaultguard mcp | Print harness-specific MCP config |
vaultguard info | Show config + security posture |
vaultguard test | Crypto self-test |
vaultguard is a thin convenience layer, not a secrets manager. Its job is to keep secret values out of your AI-agent transcripts, logs, and checkpoints.
What it does NOT protect against:
vaultguard audit; don't grant access you wouldn't grant yourself.vaultguard init downloads the Inline Secret Block plugin from its GitHub
releases. A malicious plugin that knows your passphrase can decrypt everything — pin/verify it if
you care.Use it when: you want "agents run things with secrets without me pasting values into the chat" and the residual risks above are acceptable to you.
Don't use it when: you need real secrets-management guarantees — rotation policy, hardware-backed keys, no procedure that makes plaintext reachable to a native plugin — when your threat model includes a hostile agent on a shared or CI machine, or when the vault itself needs encryption at rest (Obsidian's own vault encryption, or an encrypted volume, is the answer there).
Is my vault git-safe? The encrypted blocks are plain markdown — safe to commit, sync, or put anywhere Obsidian works. Since the passphrase no longer lives in ~/.vaultguard/config.json by default, committing that file leaks your vault path and settings but not your key.
What if I forget the passphrase? The blocks are AES-256-GCM. It cannot be recovered — that's the point.
Which Obsidian plugin? Inline Secret Block — vaultguard init installs it for you.
Do I need a server? No. It's a local stdio MCP server (node src/server.mjs). Nothing listens on a port.
MIT © vaultguard contributors.
The bundle installs the Inline Secret Block plugin (also MIT), downloaded at init time from the plugin's official releases — it is not vendored into this package. This project uses Node.js built-ins only (crypto), so there are no dependency licenses to track.
Guard your vault. Let your agents work.