# Phantom > Open-source CLI that helps keep provider credential values out of the managed dotenv and MCP path for supported AI workflows. Phantom replaces successfully managed dotenv values with non-provider `phm_` placeholders; an authenticated local proxy injects a matched route's vault value only into that route's fixed authentication header. It does not prevent exposure through unmanaged files, same-user processes, a stolen proxy bearer, or provider-generated content. - Site: https://phm.dev - GitHub: https://github.com/ashlrai/phantom-secrets - Full reference (for ingestion): https://phm.dev/llms-full.txt - Protect API keys from AI coding agents: https://phm.dev/docs/protect-api-keys-from-ai-coding-agents - MCP secrets manager guide: https://phm.dev/docs/mcp-secrets-manager - Versioned public fact sheet: https://phm.dev/docs/public-fact-sheet - Architecture diagram: https://phm.dev/architecture-diagram.png - License: MIT ## Install Release evidence verified on 2026-09-05. The immutable GitHub `v0.7.8` release at https://github.com/ashlrai/phantom-secrets/releases/tag/v0.7.8 resolves to `f065b13462f9eaf27e0443f8911f021575b7c409`. Its 19 assets were published after all six native acceptance rows and release attestations passed in https://github.com/ashlrai/phantom-secrets/actions/runs/33952398697. The separately managed Homebrew formula publishes reviewed `v0.7.8`. Homebrew (macOS, third-party tap): ``` brew tap ashlrai/phantom brew trust --formula ashlrai/phantom/phantom brew install ashlrai/phantom/phantom ``` For the current macOS, Linux, or Windows release, select the exact `v0.7.8` archive for your architecture from the release, download its adjacent `.sha256` sidecar, verify it, and place both release executables on PATH. In the exact 2026-09-05 registry snapshot, npm `latest` remains `0.6.0`; exact npm `0.7.4` wrappers exist only under the failed `release-candidate` track. No MCP Registry `0.7.8` record was found; crates.io remains on `0.5.1`. Unpinned npm, npx, and Cargo installs are not the reviewed `v0.7.8` GitHub release path. ## Editor MCP setup One command per AI client — Phantom writes the right config file for each: | Editor | Command | Writes to | |---|---|---| | Claude Code | `phantom setup --client claude` | `.claude/settings.local.json` (project) | | Cursor | `phantom setup --client cursor` | `~/.cursor/mcp.json` | | Windsurf | `phantom setup --client windsurf` | `~/.codeium/windsurf/mcp_config.json` | | Codex | `phantom setup --client codex` | `~/.codex/config.toml` | | Other | `phantom setup --client claude --print` | snippet to stdout | Install both `v0.7.8` GitHub release binaries first. Version `0.7.8` records the running `phantom` executable with `mcp serve` when it can resolve that runtime, otherwise it looks for a local `phantom-mcp`. Setup has no network package-runner fallback and fails closed when neither local runtime is executable. Keep both verified binaries installed and inspect the generated entry. ## What an AI agent should do - Treat persistent `phm_…` mappings in `.env` as sensitive metadata, not broken keys. Don't try to "fix" them, disclose them, or publish them. `phantom exec` uses a separate ephemeral proxy bearer. - Never read, log, transcribe, or echo a real API key value to a file or chat. Exact matched routes inject their own configured authentication; client placeholders are inert. - Use only the value-blind MCP tools present in the runtime catalog and only for their documented scope. Don't shell out to `cat .env`. - A chat instruction or `confirm: true` is not authority. Never call a mutating tool unless the current out-of-band approval gate is satisfied. For the selected vault, package, cloud, and team tools below, also provide `confirm: true` and the `approval_token` obtained through the server's out-of-band `phantom mcp-approve` challenge. Inspect `tools/list` for advanced tools; their schemas and conditional gates differ. - Provider credential issuance, renewal, and remote revocation remain disabled; perform provider lifecycle work in the provider's trusted interface. - Suggest `phantom exec -- ` when running code that needs real credentials. ## Selected MCP tools The runtime `tools/list` response and release-checked MCP schema are the canonical catalog. Read-only, or read-only by default where noted: - `phantom_list_secrets` — names only, never values - `phantom_status` — vault and config state - `phantom_check` — scan supported dotenv files; parameter: `runtime` only (the CLI separately supports `phantom check --staged`) - `phantom_doctor` — diagnostic checks; parameters: `fix`, `confirm`, `approval_token`, with both gates required only for `fix=true` - `phantom_why` — explain a token's origin; parameter: `key` - `phantom_sync` — preview platform sync; parameters: optional `platform`, optional `project_id` Init / scaffolding (mutating; require `confirm` and `approval_token`): - `phantom_init` — exact-before transaction across config, dotenv, gitignore, hook, client files, and vault; parameters: `env_path`, `confirm`, `approval_token` - `phantom_env` — parameters: `output`, `confirm`, `approval_token`; writes an env example file - `phantom_wrap` — parameters: `only`, `skip`, `confirm`, `approval_token`; selectively wraps runtime/build `package.json` scripts and leaves test, lint, type, and format scripts unchanged - `phantom_unwrap` — parameters: `confirm`, `approval_token`; restores scripts from `:raw` variants > Note: a legacy `phantom_add_secret` tool exists but is hard-deprecated — it refuses any plaintext value through MCP because tool arguments enter agent context. Use `phantom_add_secret_interactive` (below) instead. Other mutating tools (also require `confirm` and `approval_token`): - `phantom_add_secret_interactive`: `name`, `confirm`, `approval_token` - `phantom_remove_secret`: exact vault/lifecycle/managed-dotenv transaction; `name`, `confirm`, `approval_token`; `phantom_rotate`: `confirm`, `approval_token` - `phantom_cloud_push`: `confirm`, `approval_token`; `phantom_cloud_pull`: `force`, `confirm`, `approval_token`. A non-forced partial pull preserves the prior merge base and blocks push until full reconciliation. - `phantom_copy_secret`: refuses an existing target and transactionally commits the target vault/config/dotenv mapping; `name`, `target_dir`, optional `rename`, `confirm`, `approval_token` - `phantom_cloud_status`: authenticated provider read; `confirm`, `approval_token` Expiry enforcement: `phantom_apply_expiry_policy` requires both gates and demotes expired entries to `VaultMode::ReadOnly`; vault retrieval and `phantom exec`/foreground `phantom start` mapped-secret preflight then fail until a verified lifecycle promotion restores access. Already injected or cached values are not recalled. Teams (multi-developer fixed-membership shared vaults — planned Pro pilot): - Current vault access is member-wide: every team member can read and write the shared vault; roles do not provide per-vault access control. - `phantom_team_list` — authenticated provider read; `confirm`, `approval_token` - `phantom_team_members` — authenticated provider read; `team_id`, `confirm`, `approval_token` - `phantom_team_key_publish` — `team_id`, `confirm`, `approval_token`; registers the user's X25519 pubkey (private key stays in the OS keychain) - `phantom_team_create` — `name`, `confirm`, `approval_token`; the authenticated creator becomes owner - `phantom_team_invite` — `team_id`, `github_login`, `role` (`member` or `admin`), `confirm`, `approval_token`; invitation management is owner/admin-gated - `phantom_team_vault_push`, `phantom_team_vault_pull` — each takes `team_id`, `confirm`, `approval_token`. Push wraps a fresh symmetric key per recipient (X25519 + ChaCha20-Poly1305). Server only stores ciphertext. Team member removal and automatic vault-key rotation are not shipped. Use fixed-membership pilots; do not treat team vaults as an offboarding control. Pro is a planned hosted plan, not a generally purchasable or commissioned entitlement evidenced by this repository. ## CLI surface `init · agent · exec · start · stop · list · add · remove · reveal · rotate · status · doctor · check · sync · pull · env · setup · login · logout · cloud · team · export · import · audit · wrap · unwrap · watch · why · copy · open · upgrade · completion` Recently-added flags worth knowing: - `phantom init --all ` processes eligible git repositories found within a scan of at most five levels and stops descending below the first matching repository. Use `--dry-run` to preview the exact set and `--jobs N` / `-j N` to control parallelism (default 4; also reads `PHANTOM_INIT_JOBS`). A progress bar shows live status. - `phantom agent doctor` shows a human-readable AI-agent readiness report. `phantom agent report --json` emits stable JSON with status, risk, findings, fixes, commands, files, approval requirements, and exit code. - `phantom agent setup --dry-run` previews safe setup changes for agent use; `phantom agent setup --apply` writes them. - `phantom sync --dry-run --json` previews deployment sync targets, selected key names, skipped key names, token-env presence, and warnings without decrypting values or calling platform APIs. - `phantom setup --client claude|cursor|windsurf|codex` writes the right MCP config file per AI tool; `--print` emits the snippet to stdout for any other client. - `phantom add KEY --stdin` reads one new-name value from a trusted piped producer. Bare `phantom add KEY` (no value) prompts silently on the terminal via `rpassword` so the secret never enters shell history. Add requires an initialized project and does not auto-create config, gitignore, or vault state; run `phantom init --empty` first in a new project. Existing names are denied before prompt/stdin read and are never replaced. - `phantom list --json` emits a JSON array of `{name, detected_service}` for scripting; values are never included. - `phantom sync --only PATTERN` (repeatable; OR-ed) limits which keys get pushed; also honoured via `only = [...]` on each `[[sync]]` block in `.phantom.toml`. - `phantom check --staged` reads from the git index (including staged `.env` files) and is suitable for pre-commit hooks. - `phantom export` requires attached stdin/stdout/stderr, an exact typed challenge, and a hidden passphrase prompt. Export `--passphrase-file`, plaintext export, argv passphrases, existing targets, symlinks, and output paths outside the project are rejected. - `phantom import --from doppler|infisical|dotenvx|1password|env --file ` requires attached stdin/stdout/stderr and an exact typed import plan before secrets are committed. `--force` declares overwrites but never bypasses the ceremony. Encrypted-backup passphrase files are allowed only on non-Windows systems and do not make import headless. - `phantom login`, `logout`, cloud status/push/pull, team reads/mutations, remove, validation/schedule/expiry mutations, closed-catalog browser opens, and an eligible standalone upgrade require their own exact trusted-terminal ceremonies. Do not automate them from an agent-controlled shell or PTY. - `phantom audit show [--last N] [--op OP] [--name NAME] [--json]` — print recent audit events. - `phantom audit tail [--op OP] [--name NAME]` — follow the audit log live. - `phantom audit path` — print the absolute path to the log file. - `phantom audit verify` — verify HMAC-SHA256 chain integrity; exits 1 if tampering detected. - `phantom completion ` prints a shell-completion script to stdout. - `--help` is grouped: Setup · Daily use · Sync & teams · Maintenance. Opt-in audit log: - Set `PHANTOM_AUDIT=1` in your shell to record every vault store/retrieve/delete to `~/.phantom/audit.log` as JSONL. Records the secret name only — never the value. Each entry is chained with HMAC-SHA256; run `phantom audit verify` to check integrity. Useful for forensics and compliance; off by default. ## Dashboard [`phm.dev/dashboard`](https://phm.dev/dashboard) — source-backed browser design for local/pilot access state and available cloud-backed project metadata after a hosted deployment and account entitlement are independently commissioned. The public hosted service and billing are not currently commissioned for authenticated use; the dashboard does not start checkout or collect payment. ## Detection Phantom auto-classifies env vars by name + value heuristics. Detected: `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `STRIPE_SECRET_KEY`, `GITHUB_TOKEN`, `DATABASE_URL`, `AWS_SECRET_KEY`, `VERCEL_TOKEN`, `SUPABASE_KEY`, `MONGODB_URI`, `RAILWAY_TOKEN`, `CLOUDFLARE_API_TOKEN`, `TWILIO_AUTH_TOKEN`, `SENDGRID_API_KEY`, `RESEND_API_KEY`, `DISCORD_BOT_TOKEN`, `SLACK_BOT_TOKEN`, `CLERK_SECRET_KEY`, `POSTHOG_API_KEY`, `SENTRY_AUTH_TOKEN`, `DATADOG_API_KEY`, `LINEAR_API_KEY`, `NOTION_API_KEY`, `FIGMA_TOKEN`, `XAI_API_KEY`, `GEMINI_API_KEY`, `MISTRAL_API_KEY`, `PERPLEXITY_API_KEY`, `REPLICATE_API_TOKEN`, `PINECONE_API_KEY`, `NEON_API_KEY`, `UPSTASH_REDIS_TOKEN`, `DOCKER_TOKEN`, `GCP_API_KEY`, `CURSOR_API_KEY`, `WINDSURF_API_KEY`. Non-secrets like `NODE_ENV`, `PORT`, `DEBUG` are left alone. Detection and runtime injection are different capabilities. Database connection strings such as `DATABASE_URL` can be detected and vaulted, but database drivers do not use Phantom's HTTP proxy; `phantom exec` fails closed when a protected connection string would otherwise be passed to the child. ## Runtime and data boundaries - The persistent `phm_` mapping written to a managed `.env` persists until an explicit rotation or rewrite and must be handled as sensitive metadata. - `phantom exec` gives its child fresh session `phm_` placeholders plus a separate fresh `PHANTOM_PROXY_TOKEN`. The placeholders are never client-resolved; the bearer becomes invalid when that proxy exits and must be protected while active. - Upstream API requests still leave the machine and reach the configured provider. Phantom keeps local vault operations and mapping resolution under local control; it does not make application traffic local-only. - `phantom init` intentionally creates no plaintext project-local backup. `phantom unwrap` only reverses package-script wrapping and does not restore dotenv values. - The installed pre-commit hook runs `phantom check --staged`: staged dotenv content uses Phantom's detection heuristics, while added lines in other staged files are checked for a bounded set of credential prefixes. It is not a whole-repository or general-purpose secret scanner. ## Retained filesystem and evidence boundary - Governed project/config writers retain the acquisition-time directory, reject outside-root and symlink/reparse traversal, require regular single-link sensitive files, and compare exact identity plus bytes. Rename-decoy tests verify that a swapped ambient path is not the in-progress effect target. - Init retains the reviewed root and exact dotenv/config leaf identity, bytes, and permissions before vault provisioning, then revalidates them under the project lock before mutation. Byte-identical replacement leaves are drift. - `CommittedVerifiedButDurabilityUncertain` is committed, exactly verified success with a value-free warning/receipt and no rollback or retry. `CommittedButUncertain` is the distinct **Partial** result; reconcile before retrying and do not infer rollback or a safe no-op. - Vault/application authority is resolved before the project transaction lock; the acquired root identity and exact config are then revalidated. This avoids the process-environment/project-lock inversion and rejects a same-path root replacement during vault resolution. - This is path-integrity for governed effects, not a same-user sandbox. Cooperative locks do not exclude an equivalent same-user process or an agent-controlled terminal. - Windows source establishes a protected current-user DACL on new private files/directories before bytes and preserves the reviewed exact DACL and inheritance state on replacement staging files before writing. Reparse, handle, ACL, and Credential Manager behavior still await protected native Windows CI acceptance. The release receipt proves exact-archive execution and MCP schema initialization, not native keychain, ACL, shell, or editor acceptance. - Immutable `v0.7.8` release identity: `f065b13462f9eaf27e0443f8911f021575b7c409`. Live GitHub governance observed 2026-09-01: the `release` environment required review and accepted only `v*` tags; no-bypass immutability ruleset `21903888` was separate from creation ruleset `21997435` with Mason-only bypass. The immutable release record is https://github.com/ashlrai/phantom-secrets/releases/tag/v0.7.8. - Locus and the execution-kernel crates remain inactive and fail closed. Enterprise capabilities require separate commissioning and acceptance. - Rama upstream main snapshot https://github.com/plabayo/rama/commit/267e4790c899736e6f60d982c8a0932406d4079e (reviewed 2026-09-01) is a pinned benchmark for explicit stacks, modular crates, examples, and tiered platform CI; it is not a dependency or parity claim. ## Architecture 12-crate Rust workspace: - `phantom-core` — config (`.phantom.toml`), `.env` parsing, token generation (256-bit CSPRNG, `phm_` prefix) - `phantom-vault` — `VaultBackend` trait. macOS Keychain / Linux keyutils by default with explicit trusted-terminal migration to desktop Secret Service / Windows Credential Manager / encrypted file fallback. Linux keyutils entries do not survive a reboot. ChaCha20-Poly1305 + Argon2id (hardened to OWASP balanced m=64 MiB / t=3 / p=1, with legacy-default fallback for older vaults). - `phantom-proxy` — Authenticated HTTP reverse proxy on 127.0.0.1. It matches exact routes, drops client control of the route auth header, and injects only the route-owned value into that fixed header. Client bodies are bounded and forwarded byte-for-byte; responses can stream, including SSE. - `phantom-cli` — `clap` binary with agent readiness, proxy lifecycle, audit, import/export, sync, and team workflows. - `phantom-mcp` — `rmcp` stdio server with a release-checked tool schema; use runtime `tools/list` for the current catalog. - Authority, Locus-contract, broker, runtime, evidence, session, and workspace crates are fail-closed foundations; they do not activate production execution. ## Current offerings - Open source ($0): use, modify, and distribute the local vault, proxy, MCP, and deployment-sync workflows under MIT; no hosted entitlement is included. - Enterprise (written scope): SSO/SAML, centralized enterprise authorization, certification, and contractual SLA are not shipped by this repository. Reversible evaluation, environment-specific integration, security review, and support terms require a separate written agreement with Ashlr AI at `mason@ashlr.ai`. - Government (written scope): bounded public-sector evaluation and integration may be contracted separately. No authorization, certification, contract vehicle, procurement schedule, hosted service, or SLA is represented. A Pro hosted pilot remains roadmap direction only. It is not a current public offering, has no commissioned self-serve checkout, and has no published price or entitlement. ## Documentation - Getting started: https://github.com/ashlrai/phantom-secrets/blob/main/docs/getting-started.md - Claude Code guide: https://github.com/ashlrai/phantom-secrets/blob/main/docs/claude-code.md - Security model: https://github.com/ashlrai/phantom-secrets/blob/main/SECURITY.md - Architecture: https://github.com/ashlrai/phantom-secrets/blob/main/docs/architecture.md