llms-full.txt

# Phantom — Delegate Supported Secret Workflows to AI

Phantom is an open-source CLI that helps keep provider credential values out of the managed dotenv and MCP path for supported AI workflows. It replaces heuristically detected, managed dotenv values with random `phm_` placeholders and uses an authenticated local proxy for reviewed HTTP API routes. It reduces one credential-exposure path; it does not eliminate risk from unmanaged files, same-user processes, proxy-bearer theft, provider endpoints, arbitrary tools, or unsupported protocols.

Website: https://phm.dev
GitHub: https://github.com/ashlrai/phantom-secrets
License: MIT
Language: Rust
Release evidence was 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 verified after all six native acceptance rows and release attestations passed in https://github.com/ashlrai/phantom-secrets/actions/runs/33952398697.
Install: use the exact checksum-verified `v0.7.8` GitHub assets below on macOS, Linux, and Windows. The separately managed Homebrew formula publishes reviewed `v0.7.8`.
MCP: after installing both release binaries, run `phantom setup --client claude|cursor|windsurf|codex`.

## The Problem

AI coding tools with dotenv filesystem access can put API keys into the LLM context window. They can leak via:
- Session logs and transcripts
- Prompt injection attacks
- Malicious MCP servers
- Training data
- Code generation (AI writes keys into files)

GitGuardian reports 28.65M new hardcoded secrets in public GitHub commits in
2025, a 34% year-over-year increase.
AI-service secrets separately increased 81% year over year; that category-specific figure does not apply to all secrets. Primary source:
https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/

## How Phantom Works

1. `phantom init` reads your .env, stores detected real secrets in an OS credential store or ChaCha20-Poly1305 encrypted-file fallback, and rewrites managed values with `phm_` placeholders. It does not create a plaintext project backup. `phantom unwrap` restores package scripts changed by `phantom wrap`; it does not recover secret values.
2. `phantom exec -- claude` validates reviewed proxy routes, generates fresh child-process `phm_` placeholders plus a fresh PHANTOM_PROXY_TOKEN, starts a local HTTP reverse proxy on 127.0.0.1, sets implemented SDK BASE_URL variables (e.g., OPENAI_BASE_URL=http://127.0.0.1:PORT/openai/_phantom/TOKEN/), and launches the command. Project dotenv tokens persist until rotation; client placeholders are always inert, while the bearer becomes invalid when that exec proxy exits.
3. When code makes an API call, the proxy authenticates the local session, removes its local auth token, matches an exact route, discards client control of that route's authentication header, and injects only the route-owned vault value into that fixed header before forwarding over TLS. Client headers and bodies never resolve phantom tokens. Full response streaming/SSE support remains available.
4. Authenticated proxy sessions: each proxy run generates a fresh PHANTOM_PROXY_TOKEN. Header-aware clients can set PHANTOM_PROXY_HEADER_AUTH_ONLY=1 and send it as x-phantom-proxy-token instead of using path-authenticated local SDK URLs.

Connection strings such as DATABASE_URL can be detected, vaulted, and replaced in dotenv, but `phantom exec` refuses to launch with them. Direct environment injection is disabled until a protocol-aware database broker exists.

## CLI Commands

- `phantom init` — Import .env secrets into vault and rewrite managed values. `--all <DIR>` processes eligible repositories found within a five-level scan, stops below the first matching repository, and supports `--dry-run` plus `--jobs N` / `-j N` (default 4).
- `phantom agent report --json` — Read-only AI-agent readiness report with status, risk_level, findings, fixes, commands, files, requires_approval, and exit_code.
- `phantom agent doctor` — Human-readable view of the same readiness policy. Status values: unsafe, protected, verified, team-ready, compliance-ready. `compliance-ready` is a local readiness label meaning its configured predicates passed; it is not regulatory compliance, certification, centralized retention, or an independent audit.
- `phantom agent setup --dry-run|--apply` — Preview or apply safe defaults for agent use, including MCP wiring and .env.example generation.
- `phantom exec -- <cmd>` — Start an authenticated proxy, run command, shut down proxy on exit.
- `phantom login` — After separate hosted commissioning and entitlement, from attached stdin/stdout/stderr approve an exact network plan, then separately approve browser opening/polling and OS-keychain persistence for the GitHub device flow. The public hosted service is not currently commissioned for authenticated use.
- `phantom logout` — From attached stdin/stdout/stderr, approve the exact deletion of persistent cloud authorization from the OS keychain.
- `phantom cloud push` — After separate hosted commissioning and entitlement plus exact trusted-terminal consent, push a client-encrypted vault. Remote success followed by local reconciliation failure is partial success and must not be retried automatically.
- `phantom cloud pull` — After separate hosted commissioning and entitlement plus exact trusted-terminal consent, restore on the machine holding the original cloud key. With `force=false`, skipped entries preserve the prior merge base and block later push until full reconciliation.
- `phantom cloud status` — After separate hosted commissioning and entitlement, request cloud auth and sync status.
- `phantom export --output <file>` — Requires attached stdin/stdout/stderr, an exact value-blind typed challenge, and a hidden terminal passphrase before vault-value access. Export passphrase files, plaintext, argv passphrases, existing targets, symlinks, and paths outside the project are rejected.
- `phantom import <file>` — Requires attached stdin/stdout/stderr and exact typed consent bound to source identity/digest, target project/vault, destination names, and overwrite set. `--force` selects that reviewed overwrite set but never bypasses consent. A bounded private passphrase file is accepted only for non-Windows import and remains terminal-gated.
- `phantom audit show [--last N] [--op OP] [--name NAME] [--json]` — Print recent audit events. Requires `PHANTOM_AUDIT=1`.
- `phantom audit tail` — Follow the audit log live.
- `phantom audit path` — Print the absolute path to the audit log file.
- `phantom audit verify` — Verify HMAC-SHA256 chain integrity; exits 1 if tampering detected.
- `phantom start` — Run a foreground proxy only when stdin/stdout/stderr are terminals; keep the trusted owning terminal open and press Ctrl-C there to stop. `--daemon` and current external control fail closed; `phantom stop` authenticates legacy v0.7.3 state only to report manual migration guidance and never kills or deletes.
- `phantom list` — Show secret names stored in vault (never shows values). Add `--json` to emit a machine-readable array of `{name, detected_service}` for scripting; values are still excluded.
- `phantom add <KEY>` — Transactionally create a new secret name in an initialized project through a hidden terminal prompt. It does not auto-create config, gitignore, or vault state; run `phantom init --empty` first in a new project. Positional values are rejected; for a trusted piped producer, pass `--stdin` and provide one line. Existing names are denied before prompt/stdin read and are never replaced.
- `phantom remove <KEY>` — After exact trusted-terminal consent, transactionally remove the vault value, lifecycle config, and exact managed-dotenv mapping.
- `phantom reveal <KEY>` — View a secret value only from attached terminals after exact typed confirmation; there is no non-interactive bypass.
- `phantom rotate` — After an exact attached-terminal challenge bound to the canonical project, config, dotenv, and sorted-name digest, regenerate all local phantom mappings without changing provider credentials. Headless use is denied before vault access or mutation, and drift aborts the write. `--sync` is rejected for a local-only remap; rotate at the provider, store the successor from a trusted terminal, then run a separately reviewed sync.
- `phantom status` — Show project ID, vault backend, secret count, service mappings.
- `phantom doctor` — Health check: config, vault, .env, .gitignore, Claude Code MCP, cloud auth.
- `phantom check` — Heuristically scans supported `.env` files for unprotected real secrets. Exit code 1 if found. `--staged` reads dotenv content from the index and checks a bounded set of hardcoded-key prefixes on added lines. `--runtime` detects phantom tokens in selected environment variables when the proxy is not running. It is not a complete repository secret scanner.
- `phantom sync --platform vercel --project <id>` — Push secrets to Vercel or Railway. Use `--dry-run --json` to preview targets, selected key names, skipped key names, token-env presence, and warnings without decrypting values or calling platform APIs. Use `--only PATTERN` (glob, repeatable, OR-ed) to limit which keys get pushed; the same filter is also honoured via `only = ["PATTERN", ...]` on each `[[sync]]` block in `.phantom.toml`.
- `phantom pull --from vercel --project <id>` — Pull secrets from platforms into vault.
- `phantom env` — Generate .env.example with secret values masked.
- `phantom setup` — Configure Claude Code MCP server and permissions automatically.
- `phantom watch` — Watch managed dotenv files and report newly added unprotected secrets. The compatibility `--auto` flag hard-denies before mutation in 0.7.8; review the file and run transactional `phantom init` from a trusted terminal.
- `phantom why <KEY>` — Explain whether a key is classified as Secret, PublicKey, or NotSecret, and which heuristic matched.
- `phantom copy <KEY> --to <DIR> [--rename NEW]` — After exact trusted-terminal confirmation, copy a secret from this initialized project to an initialized target without printing the value. Optional rename in the target project. It refuses an existing target vault entry, config ownership, or managed-dotenv key rather than overwriting it.
- `phantom wrap [--only A,B] [--skip X,Y]` — Wrap `package.json` scripts with `phantom exec` so npm scripts get real credentials at runtime. Originals are preserved as `script:raw` variants.
- `phantom unwrap` — Reverse `phantom wrap`, restoring originals from `:raw` variants.
- `phantom cloud status` / `phantom team list` / `phantom team members` — Authenticated CLI provider reads that require attached terminals and an exact typed challenge before stored-bearer or network access. MCP equivalents require `confirm` plus out-of-band approval.
- Team mutations require an attached trusted terminal and an exact typed challenge before credential, keypair, vault-value, or network access.
- `phantom team create / invite / key-publish / vault-push / vault-pull / rotate-vault` — Source-backed fixed-membership pilot effects; invite roles are only `member` or `admin`. Push wraps a fresh symmetric key per registered recipient and stores ciphertext remotely.
- `phantom validate` / `--watch` — Live provider checks require attached terminals and exact consent before credential retrieval. Schedule status/history are read-only; schedule updates and expiry-policy writes require their own exact terminal challenges.
- `phantom open [target]` — From an attached trusted terminal, open only the closed aliases `dashboard`, `billing`, `team`, `docs`, `pricing`, `github`, `issues`, or `site`; unknown words, paths, and arbitrary URLs are rejected before browser access.
- `phantom upgrade [--check-only]` — Managed installs route to their owner and ambiguous installs fail closed. An eligible standalone replacement requires attached terminals and two exact challenges; `--force` is rejected.
- `phantom completion <bash|zsh|fish|powershell|elvish>` — Print a shell-completion script to stdout.

## Installation

### Homebrew (macOS, reviewed v0.7.8)
```
brew tap ashlrai/phantom
brew trust --formula ashlrai/phantom/phantom
brew install ashlrai/phantom/phantom
```

### Exact v0.7.8 GitHub assets
macOS Apple Silicon: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-aarch64-apple-darwin.tar.gz
macOS Intel: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-x86_64-apple-darwin.tar.gz
Linux x86_64: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-x86_64-unknown-linux-gnu.tar.gz
Linux ARM64: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-aarch64-unknown-linux-gnu.tar.gz
Windows x64: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-x86_64-pc-windows-msvc.zip
Windows ARM64: https://github.com/ashlrai/phantom-secrets/releases/download/v0.7.8/phantom-aarch64-pc-windows-msvc.zip
Download the adjacent `.sha256` sidecar for the selected archive, verify it,
then extract both release executables and place them on PATH.

### Exact source build
```
git clone https://github.com/ashlrai/phantom-secrets.git
cd phantom-secrets
git checkout f065b13462f9eaf27e0443f8911f021575b7c409
cargo build --release --locked --bin phantom --bin phantom-mcp
```

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 install` commands are not the reviewed v0.7.8 GitHub release path.

### MCP setup

Run `phantom setup --client claude|cursor|windsurf|codex` after installing both
`v0.7.8` GitHub release binaries. Ask the client to propose protection and review affected
files and confirmation-gated steps. Keep secret entry in the trusted terminal
and deployment/provider authority separate.

Released `v0.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 `v0.7.8` binaries installed and
inspect the generated entry.

## MCP Server — Multi-IDE Support

Phantom includes a native MCP server (`phantom-secrets-mcp`) with 54 tools enforced by the release schema smoke test.

### Setup by IDE

**Claude Code:**
```
phantom setup --client claude
```

**Cursor:** `phantom setup --client cursor`

**Windsurf:** `phantom setup --client windsurf`

**GitHub Copilot:** Uses `.github/copilot-instructions.md` for project-level instructions. MCP via VS Code settings.

**OpenAI Codex:** `phantom setup --client codex`

### MCP Tools

The runtime `tools/list` schema is canonical. Effectful MCP calls are disabled
by default. They can reach the `confirm: true` and one-use `approval_token`
gates only when `PHANTOM_MCP_EFFECTS=trusted-terminal` is configured outside
agent authority. `phantom mcp-approve` requires attached stdin/stderr, displays
the value-blind effect and exact parameters, and requires a fresh typed
challenge. A same-user shell or controllable PTY can defeat this ceremony, so
leave effects disabled unless the approval command and approval storage are
outside agent authority. The token is never a substitute for explicit user
consent. Advanced audit, validation, rotation, and expiry tools have
distinct schemas and conditional gates; inspect `tools/list` rather than
extrapolating this selected catalog.

`phantom_rotate_with_candidate` and `phantom_rotate_promote` are deprecated
hard denials retained for schema compatibility. They create or promote nothing;
`phantom_rotate_provider` is also a hard denial in 0.7.8; no MCP approval can
activate live provider issuance.

`phantom_apply_expiry_policy` demotes expired entries to `VaultMode::ReadOnly`.
Vault backends refuse value retrieval while that mode is set, and
`phantom exec`/foreground `phantom start` fail their mapped-secret preflight
instead of injecting the expired value. A later verified lifecycle promotion
restores read access. Demotion does not recall a value already injected into or
cached by a running process.

**Secret Management:**
- `phantom_init` — Exact-before transaction: read a safe project-local dotenv, compare-and-swap vault entries, persist config, and rewrite the dotenv last. Concurrent drift aborts. Params: env_path (default `.env`), confirm, approval_token.
- `phantom_list_secrets` — List secret names with service mappings (never values).
- `phantom_status` — Show vault and config status (project ID, backend, secret count).
- `phantom_add_secret_interactive` — Return a command that prompts for a new value in a trusted terminal, outside MCP. Params: name, confirm, approval_token.
- `phantom_add_secret` — Deprecated compatibility tool; refuses plaintext values passed through MCP. Params: name, confirm, approval_token.
- `phantom_remove_secret` — Transactionally remove the vault value, lifecycle config, and exact managed-dotenv mapping. Params: name, confirm, approval_token.
- `phantom_rotate` — Regenerate all phantom tokens in .env. Params: confirm, approval_token.

**Personal Cloud Backup:**
The protocol source requires a separately commissioned hosted deployment and entitled account; the public hosted service is not currently commissioned for authenticated use.
- `phantom_cloud_push` — After commissioning, push a client-encrypted ChaCha20-Poly1305 vault payload. Params: confirm, approval_token. The configured vault API receives ciphertext rather than decrypted secret values; client, account, endpoint, and deployment security remain in scope.
- `phantom_cloud_pull` — After commissioning, pull a vault snapshot. Params: force, confirm, approval_token. With `force=false`, skipped existing entries retain the prior merge base and block push until full reconciliation.
- `phantom_cloud_status` — After commissioning, make a dual-gated authenticated provider request for cloud auth status, plan, and last sync version. Params: confirm, approval_token.

**Diagnostics & Cross-Project:**
- `phantom_doctor` — Health checks: config validity, vault access, .env protection, .gitignore, .env.example, pre-commit hook. Params: fix, confirm, approval_token. `confirm` and `approval_token` are required only when `fix=true`.
- `phantom_why` — Explain whether a key is classified as Secret / PublicKey / NotSecret and which heuristic matched. Params: key.
- `phantom_check` — Run Phantom's bounded detector. Params: runtime. With `runtime=true`, checks selected environment variables for phantom tokens without a proxy; otherwise it scans supported dotenv files in the working tree. The CLI, separately, supports `phantom check --staged` for index-aware checks.
- `phantom_env` — Generate a .env.example file from .env. Params: output (default `.env.example`), confirm, approval_token. Secrets become descriptive placeholders; non-secret config values are preserved.
- `phantom_sync` — Show sync configuration and what secrets would be pushed to deployment platforms (Vercel, Railway). Params: platform (optional), project_id (optional). Informational; it does not execute a sync.
- `phantom_copy_secret` — Exact-before target transaction that refuses existing vault/config/dotenv ownership and creates the vault entry plus managed-dotenv mapping without returning the value. Params: name, target_dir, rename (optional), confirm, approval_token.

**Package.json wrapping:**
- `phantom_wrap` — Wrap `package.json` scripts with the installed local `phantom exec --` runtime so secrets are injected via the proxy. Originals are saved as `script:raw` variants. Heuristically picks dev/start/build/serve/deploy scripts and skips lint/test/format scripts. Params: only, skip, confirm, approval_token.
- `phantom_unwrap` — Reverse `phantom_wrap`: restore original scripts from `:raw` variants and remove the `:raw` entries. Params: confirm, approval_token.

**Teams (source-backed fixed-membership pilot; hosted Pro commissioning required):**
- `phantom_team_list` — Dual-gated authenticated provider request listing the teams the user belongs to. Params: confirm, approval_token.
- `phantom_team_members` — Dual-gated authenticated provider request listing members. Params: team_id, confirm, approval_token.
- `phantom_team_key_publish` — Register this device's X25519 public key with the team. Params: team_id, confirm, approval_token. Pubkey only — the private key stays in the OS keychain.
- `phantom_team_create` — Create a new team. The authenticated user becomes the owner. Params: name, confirm, approval_token.
- `phantom_team_invite` — Invite someone to a team by GitHub username. The caller must be owner/admin; the assigned role is `member` or `admin` only. Ownership transfer is not exposed. Params: team_id, github_login, role, confirm, approval_token.
- `phantom_team_vault_push` — Push this project's secrets to the shared team vault, encrypted client-side for each member with a registered key. Params: team_id, confirm, approval_token.
- `phantom_team_vault_pull` — Download and decrypt the team vault for this project into the local vault. Params: team_id, confirm, approval_token. This overwrites local secrets; use it instead of phantom_cloud_pull for team-shared secrets.

Owner/admin roles gate invitations, but current vault read/write access is member-wide. Member removal and atomic offboarding key rotation are not shipped; do not treat this pilot as enterprise RBAC or an offboarding control.

### How AI Agents Should Use Phantom

When an AI agent detects a `.env` file with real API keys (sk-*, ghp_*, etc.):
1. Suggest running `phantom_init` to protect secrets
2. After init, managed dotenv secrets are phm_ tokens rather than provider credentials; keep dotenv reads denied because unmanaged values and token mappings still matter
3. Use `phantom_add_secret_interactive` to add new keys; the user types values only into the trusted terminal prompt
4. Use `phantom_cloud_push` to back up the vault
5. Never attempt to read real secret values — use `phantom_list_secrets` to see what's available

## Personal Cloud Backup Architecture

Phantom Cloud's implemented client encrypts vault payloads before upload:
- **Encrypted vault payload**: The cloud vault API stores ciphertext rather than decrypted secret values; client, endpoint, account, and OS-keychain security remain in the trust boundary.
- **Client-side encryption**: ChaCha20-Poly1305 with Argon2id key derivation. A random passphrase is stored only in the user's OS keychain. Personal cloud-key export, transfer, and recovery are not shipped, so account login without that key cannot decrypt the snapshot.
- **Optimistic concurrency**: Version numbers reject a push based on a stale local version. This does not imply cross-device decryption.
- **Team-vault distinction**: A team vault separately wraps a shared key to each registered member's X25519 public key. It does not make personal cloud backups portable.
- **Packaging copy**: Hosted Pro is a planned pilot. Eligibility, team and vault limits, and pricing are TBD; no self-serve checkout is commissioned. Verify the deployed entitlement and current written terms rather than treating source copy as activation evidence.
- **Auth**: GitHub OAuth via device code flow (like GitHub CLI).

## Security Model

- After successful init, managed dotenv values are tokens; unmanaged files, logs, backups, and external tools remain outside this claim
- Vault encryption: ChaCha20-Poly1305 with Argon2id key derivation (32-byte salt, 256-bit key)
- Phantom tokens: 256-bit CSPRNG with phm_ prefix; random collision with supported real-key formats is cryptographically negligible, not impossible
- Proxy binds to 127.0.0.1 rather than a non-loopback interface; same-user local-process and bearer threats remain
- Proxy token authentication rejects callers without the bearer; bearer theft and same-user local-process access remain in the threat model
- Major vault retrieval, serialization, and decrypted-file buffers use targeted zeroization; some proxy lookup copies remain ordinary strings, so this is defense in depth rather than complete memory erasure
- Allowlist model: proxy only injects for configured service patterns
- Authenticated proxy sessions: each proxy run generates a fresh PHANTOM_PROXY_TOKEN; CLI-generated SDK URLs include it locally, and header-aware clients can opt into x-phantom-proxy-token
- Cloud tokens stored hashed (SHA-256) in database — never plaintext
- Streaming/SSE support for OpenAI and Anthropic APIs
- Governed project and client-config effects resolve from retained directory
  capabilities, reject outside-root and symlink/reparse traversal, require
  regular single-link sensitive files, and compare stable identity plus bytes.
  A renamed ambient root and replacement decoy do not redirect an in-progress
  anchored effect in the source-tested cases.
- 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` means verification or durability remains unresolved;
  it is **Partial**, requires reconciliation, and is not proof of rollback.
- 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 same-path root
  replacement during vault resolution.
- Retained roots and cooperative locks are not a same-user sandbox. An
  equivalent same-user process or agent-controlled terminal remains in the
  threat model.
- 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.
- Implementation-security identity:
  `5a3edad60634c78af3079f588bf51fefa0b69586`. 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. Creation authority cannot bypass
  the separate immutability policy; reverify before release.

## Platform Sync

Push secrets to deployment platforms:
```
phantom sync --platform vercel --project prj_xxx
phantom sync --platform railway --project xxx
```

Pull secrets from deployment platforms (requires that provider's credentials):
```
phantom pull --from vercel --project prj_xxx
phantom pull --from railway --project xxx --environment production
```

## Monorepo Support

Phantom supports monorepo subdirectory detection. Running `phantom init` in a subdirectory with its own `.env` creates a project-scoped vault. Each subdirectory can have its own `.phantom.toml` config and independent secret set.

## Smart Secret Detection

Phantom automatically identifies secrets vs config values using heuristics:
- Key patterns: *_API_KEY, *_SECRET*, *_TOKEN, *_PASSWORD, DATABASE_URL, REDIS_URL
- Value patterns: sk-*, sk_*, ghp_*, github_pat_*, glpat-*, xoxb-*, AKIA*, Bearer, eyJ
- Connection strings with @ in URLs
- High-entropy strings (32+ chars of hex/base64)
- Non-secrets left untouched: NODE_ENV, PORT, DEBUG, APP_NAME

## Architecture

12-crate Rust workspace + Next.js backend:
- phantom-core: Config, .env parsing, token generation, sync, auth, cloud API client
- phantom-vault: VaultBackend trait, OS keychain + encrypted file backends, shared crypto module
- phantom-proxy: authenticated HTTP reverse proxy with fixed route-owned auth-header injection, inert client headers/bodies, bounded request acceptance, response scrubbing, and SSE/streaming response support
- phantom-cli: clap CLI with agent readiness, proxy lifecycle, audit, import/export, sync, and team workflows
- phantom-mcp: MCP server via rmcp SDK (stdio transport, 54 release-checked tools)
- phantom-authority, phantom-locus-contract, phantom-broker, phantom-runtime, phantom-evidence, phantom-session, phantom-workspace: fail-closed authority, compatibility, lease, execution-denial, evidence, session, and setup foundations
- apps/web: Vercel-targeted Next.js source (Supabase + Stripe, device auth,
  vault API, billing); repository presence is not deployment or commissioning

The immutable `v0.7.8` GitHub release proves publication, checksums, the six-row
native release matrix, and release attestations for exact source
`f065b13462f9eaf27e0443f8911f021575b7c409`. It does not prove web deployment,
hosted commissioning, native credential-store acceptance, or customer acceptance. Locus,
broker, runtime, session, and externally trusted evidence remain inactive and
fail closed; enterprise packaging remains a separately commissioned plan.

Rama upstream main snapshot
https://github.com/plabayo/rama/commit/267e4790c899736e6f60d982c8a0932406d4079e,
reviewed 2026-09-01, is Phantom's
pinned benchmark for explicit network stacks, modular crates, runnable
examples, and tiered platform CI. Rama is not a dependency, and no feature or
platform parity is claimed.

MIT licensed. CI runs the Rust test suite and clippy across the workspace before release.

## Common Use Cases

1. **Solo developer with Claude Code**: `phantom init` then `phantom exec -- claude` — code safely
2. **Delegate the bounded setup**: Add the MCP server, ask Claude to propose protection, then review mutations and complete secret entry in the trusted terminal; provider issuance remains hard-denied in 0.7.8
3. **Commissioned same-keychain-machine backup**: after separately verifying hosted deployment and entitlement, `phantom login`, `phantom cloud push`, then `phantom cloud pull` where the original cloud encryption key remains available
4. **Deploy to Vercel**: `phantom sync --platform vercel --project prj_xxx`
5. **Provider-backed machine setup**: `phantom pull --from vercel --project prj_xxx` (requires Vercel credentials)
6. **Vault backup**: from a terminal outside agent authority, run `phantom export --output backup.enc`, review/type its exact challenge, and enter a hidden passphrase. Export rejects passphrase files. Import requires its own exact terminal ceremony; only non-Windows import may read a bounded private passphrase file.
6b. **Migrate from Doppler/Infisical/dotenvx/1Password**: `phantom import --from doppler --file dump.json`
6c. **Local audit support**: `PHANTOM_AUDIT=1` + `phantom audit show/tail/verify` can aid troubleshooting and forensics; it is not compliance evidence by itself
7. **Team onboarding**: `phantom env` generates .env.example with placeholders
8. **CI/CD**: Use `phantom check` as a bounded dotenv/key-prefix gate and pair it with a broader repository scanner; preview selected provider sync targets before applying
9. **Pre-commit safety**: Add `phantom check --staged` to hooks while remembering hooks can be skipped or bypassed
10. **Provider rotation and sync**: rotate through the provider's trusted interface, then use a separately reviewed trusted-terminal remove-and-add sequence if the protected name already exists. Those operations are non-atomic, and deployment sync requires its own review. Local token remaps never authorize sync.
11. **Monorepo**: Run `phantom init` in each subdirectory — each gets its own vault and config
12. **Multi-IDE team**: Same MCP server works across Claude Code, Cursor, Windsurf, and Codex