Secret manager · for the age of AI agents

Your AI uses your secrets — by name, not by value.

You gave an AI assistant access to your machine. Phantom Vault runs your commands through your secrets — calling them by name, showing the value as [REDACTED] instead of returning it. Early, open source, and under active security audit.

Free & open source · Apache 2.0 · v0.1.0 · early
AES-256-GCM at restvault_run — by nameMCP for Claude Code
phantom-vault — secrets by name, value redacted
The new threat model

Old vaults guard the door. You invited the threat inside.

Every secret manager was built to stop outsiders. But you handed an AI agent the power to read your files, run your commands, and watch the output. The threat isn't at the door anymore.

Without Phantom Vault

The AI reads everything

Grant an assistant shell access and it can see your .env, echo your keys, and pipe them anywhere. One leaked key is a drained account at 3am.

  • Keys sit in plaintext env vars
  • Prompt injection can exfiltrate them
  • Secrets land in logs, output, history
With Phantom Vault

The AI works through the vault

Secrets are injected into a subprocess by name; the AI uses the secret without the raw string sitting in a plaintext env file it can read.

  • Runs in a Landlock filesystem sandbox — proven to block writing the secret to a file
  • phantom get refuses scripted (non-TTY) raw reads
  • Encrypted at rest (AES-256-GCM + Argon2id)
How it's designed to work

What happens when a secret is needed.

verified
01 · inject

Slip the key in

The secret is placed into the subprocess environment for that one command — not printed, not echoed.

verified
02 · jail

Wall it off

The command runs under a Landlock filesystem sandbox — a proven block on writing the secret out to a file (file-sink exfil).

under audit
03 · sanitize

Scrub the output

An output sanitizer to strip the value and its encoded variants (base64, hex, URL) and a network-egress jail are in the codebase but not yet independently verified — treat as planned.

verified
04 · audit

Record the access

Every access is written to the audit log, and canary honeypot secrets can be planted to flag misuse.

Steps marked verified are enforced in the code today. The end-to-end guarantee — that an AI can never exfiltrate a secret — is not yet claimed: it is under an independent containment gate (Magnus) and won't be stated as final until it passes.

What's proven, and what's not

The honest security status.

It's open source under Apache 2.0 — read every line. The items tagged verified are enforced in the code today. The ones tagged under audit exist in the codebase but are not yet independently verified — the output sanitizer, the network-egress jail, and the top-line promise that an AI can never exfiltrate a secret (under Magnus's containment gate). We label them as planned rather than claim them. For a security tool, understating beats overstating.

verified

Encrypted at rest

AES-256-GCM with an Argon2id-derived master key. Keys are zeroized in memory after use.

verified

mlock memory protection

Secret material is pinned with mlock so it can't be swapped to disk.

verified

Anti-exfil read guard

phantom get refuses to return a raw value to a non-TTY (scripted) caller — an AI can't pipe the plaintext out of the CLI.

verified

Canary honeypots & audit log

Decoy canary secrets can be planted so touching one flags misuse, and every access is written to the audit log.

under audit

Output sanitizer & egress jail

Designed to strip the secret (and encoded variants) from output and to run commands in a fail-closed network jail — in the codebase, not yet independently verified.

verified

Filesystem jail (Landlock)

Landlock closes the disk path — the command can't write your secret to a file.

Free forever · a gift to the community

Install it in one line.

No account, no credit card, no telemetry. Riscent built this and gave it away.

$ curl -fsSL https://phantomvault.riscent.com/install | bash
Or build from source: cargo build --release -p phantom-cli -p vault-mcp Verify: phantom --version
Then, four commands
  1. 1
    Create your vault (encrypted, on your machine). On a machine that already has one, this says "Vault already exists" and leaves it untouched — it never overwrites.
    phantom init
  2. 2
    Add a secret — you're prompted for the value, it's never echoed
    phantom add STRIPE_KEY
  3. 3
    Run any command with the secret injected into its environment for that one process
    phantom run -s STRIPE_KEY -- ./deploy.sh
  4. 4
    Wire the vault-mcp server into your AI assistant (Claude Code)
    phantom mcp install

There are 21 commands in all — add, list, get, edit (bulk-edit the vault in $EDITOR), rotate, guardrail, and more. See the full Command Reference.

Or let your AI do it

Paste this into Claude Code, Cursor, or any AI CLI.

It installs Phantom Vault, wires up the MCP server, and shows you how to use it — the AI-native way to onboard a tool built for AI.

Set up Phantom Vault for me — the free, open-source vault that lets you
use my API keys and secrets without ever seeing them.

1. Install it: run
     curl -fsSL https://phantomvault.riscent.com/install | bash
   (this installs the `phantom` CLI and the `vault-mcp` server to
   /usr/local/bin), then confirm with `phantom --version`.
2. Initialize my vault: `phantom init`. If a vault already exists, leave it —
   don't create a new one.
3. Register Phantom Vault's MCP server with this assistant so you can run
   commands that use my secrets through `vault_run`. Wire it up with
   `phantom mcp install`.
4. Show me how to add a secret with `phantom add <NAME>`, then prove
   it works: store a test secret, run a command that uses it, and confirm
   the value never appears in your output.
5. Give me a 3-line cheat sheet for day-to-day use.

Never print my secret values. Docs: https://github.com/r-db/phantom-vault
Secrets by name, not by value

Let the assistant work. Keep your secrets phantom.

Free, open, and auditable — early software (v0.1.0) you can read line by line. We'd rather you trust the code than the copy.