Potencia tu agente
El comando propio del publicador. No es un endpoint de PlugMCP.
Host a copy with our keys and logs.
npx -y [email protected]Claude Code no tiene enlace de instalación para un comando local. Copia el comando de abajo y ejecútalo en una terminal.
claude mcp add io.github.ashlrai-phantom-secrets-mcp -- npx -y phantom-secrets-mcp@0.7.9Ejecútalo en una terminal.
{ "mcpServers": { "io.github.ashlrai-phantom-secrets-mcp": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
¿URL remota o un comando en tu máquina? En qué se diferencian las dos instalaciones
Ejecutar en PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
AbrirDel publicador
Your agent can use the key. It never sees it.
Delegate more to AI without putting real keys in agent context.
Phantom replaces project secrets with scoped phm_ placeholders. Applications use those placeholders through an authenticated local proxy, while agents use value-blind MCP tools for inventory, diagnostics, and governed requests.
Value-blind secret metadata and gated workflows for AI coding agents through Phantom's local proxy.
Quick start · Delegate safely · Why Phantom? · MCP setup · Docs · Contribute · phm.dev
brew tap ashlrai/phantom
brew trust --formula ashlrai/phantom/phantom
brew install ashlrai/phantom/phantom
macOS via Homebrew; installs phantom and phantom-mcp (reviewed v0.7.8). Linux and Windows:
use the matching release asset. Then run
phantom init in your project and phantom setup --client claude (or
cursor, windsurf, codex). Full walkthrough: Quick Start.
▶ Historical v0.4 demo — current behavior differs · 🛡 Security model · 📋 Threat model · 💬 Discussions
Choose the smallest path that answers your next question. The first path uses no credential, makes no network request, and does not install or configure Phantom.
AI coding agents routinely work in repositories that also contain local credentials. Once a real API key enters an agent context, transcript, tool call, or generated file, you have lost control of where that value may persist.
Traditional secrets managers focus on keys at rest and in transit. Phantom adds a boundary for agent context:
phm_ mappings, MCP responses remain value-blind, and exact proxy routes inject their own configured authentication values. Unmanaged files, broader shell authority, and same-user processes remain in the threat model.v0.7.9 GitHub release, phantom init protects a project without requiring an account, DNS changes, or a custom CA.Phantom's implemented user-facing surfaces are the CLI, vault, authenticated local proxy, MCP server, and optional cloud/team workflows documented below. Cloud and team behavior additionally depends on the deployed service, account plan, and provider configuration; source code alone is not deployment or customer-acceptance evidence. The conversation facade is intentionally narrow:
phantom_do is proposal-only. It canonicalizes a closed Cargo action and reports its digest, effect, and activation blockers; execute is hard denied.phantom_setup_workspace can propose setup, create a bearerless request, and report authenticated status. Applying a request remains a separate trusted-terminal operation.phantom grant retains value-blind lifecycle metadata and design-source foundations, but 0.7.9 hard-denies every live provider issuance/renewal path before credential or network access. A provider grant is not an execution-kernel authority grant, broker lease, or permission for an agent to execute work.See the documentation map, architecture, security policy, and threat model for the evidence behind those boundaries.
Reproduce with python3 eval/leak-rate/harness.py 5 (about 3 minutes, Linux, phantom 0.7.9; fake canary keys only, no paid keys). Method and limits: eval/leak-rate/README.md.
450 = 30 attack techniques x 3 secrets x 5 runs (cat .env, printenv, /proc/self/environ, base64 and hex dumps, git add -f, ps eww, phantom reveal/export/exec, every MCP tool called with confirm=true, and a README prompt injection the scripted agent obeys). Per-technique table: eval/leak-rate/table.md.
What this does not show: it is a scripted worst case, not an LLM, so it measures where a key can appear, not how often a model goes looking. One out-of-scope case is reported separately: an unmanaged key file the developer never put in .env stays readable (15 of 15 in both setups). Same-user access to the OS keychain is outside the documented boundary and is not tested. Proxy use of a key on an allowed route is by design. One machine, no external audit.
Install both binaries from the reviewed v0.7.9 GitHub release.
On macOS, the Homebrew formula is the shortest path; it currently installs the
previous reviewed v0.7.8 binaries until the tap is bumped to v0.7.9:
$ brew tap ashlrai/phantom
$ brew trust --formula ashlrai/phantom/phantom
$ brew install ashlrai/phantom/phantom
For exact v0.7.9 on macOS, Linux, or Windows, use the matching release asset
in Installation. Then protect and verify the project:
$ phantom init
# Auto-detects .env, .env.local, or .env in subdirectories
# Stores real secrets in the native credential store or encrypted vault,
# then rewrites .env with phantom tokens
# Auto-configures Claude Code MCP server if detected
$ phantom agent doctor
# One human-readable readiness check for AI-agent safety
$ phantom exec -- claude
# Authenticated proxy running on an ephemeral 127.0.0.1 port
# App/test processes use phantom tokens; agents use value-blind metadata
For a task contract you can hand to Claude Code, Codex, Cursor, Windsurf, or Copilot, use the safe delegation quickstart and the copyable policy and task templates. Teams evaluating a controlled rollout can start with the enterprise adoption guide.
The same core command surface is implemented for native Windows, with remaining
native acceptance limits tracked in the platform matrix. Install the exact v0.7.9
Windows ZIP for your architecture from Installation, verify its
published .sha256 sidecar, and place both executables on PATH. WSL is a
separate Linux environment with its own filesystem and credential-store context.
For an explicitly supervised foreground proxy, run phantom start with stdin,
stdout, and stderr each attached to a trusted terminal. Terminal attachment is
an admission check, not proof of who controls a PTY. The CLI detects your shell and prints the matching env-var syntax;
copy those exports into the terminal that launches the client, keep the owning
terminal open, and press Ctrl-C there to stop. Detached --daemon mode and
external process control are fail-closed until Phantom has a separately reviewed
private cross-platform control channel. phantom stop only authenticates a
legacy v0.7.3 .phantom.pid session to report migration guidance; v0.7.3 had no
authenticated shutdown endpoint, so the new binary never kills that process or
deletes its record. Stop it from its owning v0.7.3 terminal with Ctrl-C, or use
the bounded recovery procedure in Troubleshooting.
For reference:
PowerShell:
$env:OPENAI_BASE_URL = "http://127.0.0.1:PORT/openai/_phantom/TOKEN/"
$env:PHANTOM_PROXY_PORT = "PORT"
$env:PHANTOM_PROXY_TOKEN = "TOKEN"
cmd.exe:
set OPENAI_BASE_URL=http://127.0.0.1:PORT/openai/_phantom/TOKEN/
set PHANTOM_PROXY_PORT=PORT
set PHANTOM_PROXY_TOKEN=TOKEN
Git Bash / WSL: use the export X=Y syntax from the main quick-start.
Notes:
PHANTOM_PROXY_TOKEN is the proxy session authenticator. By default, phantom exec and phantom start include it in local *_BASE_URL values as /_phantom/TOKEN/ so unmodified SDKs work. Header-aware clients can set PHANTOM_PROXY_HEADER_AUTH_ONLY=1 and send x-phantom-proxy-token: $PHANTOM_PROXY_TOKEN instead.phantom.exe is blocked by Windows application-control policy, do not automatically remove Mark-of-the-Web. First verify the archive checksum and both binary identities against the release metadata. If local policy permits the verified binaries, a user may then remove the mark explicitly with PowerShell: Get-ChildItem "$env:USERPROFILE\.phantom-secrets\bin\*.exe" | Unblock-File.phantom init is a #!/bin/sh script. Native git from the command line invokes it via Git for Windows' bundled sh.exe, which is what the official Git for Windows installer ships. GUI clients (GitHub Desktop, some IDE integrations) may run with a stripped-down PATH that lacks sh.exe and silently skip the hook — for these, run commits from a terminal, or use phantom check --staged directly. CI is the durable safety net regardless.v0.7.9 release contains x64 and ARM64 Windows ZIPs, and both native Windows rows passed the tag-bound release acceptance workflow. The archives are not Authenticode-signed; this receipt does not prove every enterprise application-control policy will accept them. See the platform support matrix. .env file (AI read denied) OS Keychain / Vault
+--------------------------+ +---------------------+
| OPENAI_API_KEY=phm_a7f3 | ---> | sk-real-secret-key |
| STRIPE_KEY=phm_c9d1... | | sk_live_real-key... |
+--------------------------+ +---------------------+
| |
v v
App / test process Phantom Proxy (127.0.0.1)
+--------------------------+ +------------------------------+
| Loads phm_ tokens | | Intercepts HTTP requests |
| Agent gets MCP metadata | ---> | Injects route-owned auth key |
| Makes API calls to proxy | | Forwards over TLS to real API|
+--------------------------+ +------------------------------+
phantom init reads .env, stores real secrets in the native OS credential store or encrypted-file fallback, and rewrites .env with phm_ tokensphantom exec -- claude starts a local reverse proxy, sets SDK-compatible service base URLs such as OPENAI_BASE_URL=http://127.0.0.1:PORT/openai/_phantom/TOKEN/, exposes PHANTOM_PROXY_TOKEN to the child process, and launches the commandphm_ tokens.phantom exec also replaces project tokens with fresh child-process tokens for that run. Project phm_ values persist until rotation; they are not provider credentials and are never client-resolved, but a process controlling an authenticated active proxy can still invoke its configured provider routes.Phantom does not grant AI tools permission to read .env or other dotenv files. phantom setup removes legacy Phantom-managed dotenv read grants and preserves deny rules; agents use value-blind MCP inventory instead.
phantom grant retains value-blind lifecycle metadata and provider protocol
design foundations. In 0.7.9, all live provider issuance, enrollment exchange,
refresh, renewal, and revocation execution is hard-denied before Phantom reads a
provider credential or opens a provider network connection. Do not use grant or
rotation commands expecting a vendor-side change. Test-only mocks demonstrate
local transaction behavior only; they are not live-provider acceptance.
In these docs, provider grant means design-era credential lifecycle metadata;
no live grant flow runs in 0.7.9. Authority grant means the inactive, value-free execution
authority type in phantom-authority. A provider grant cannot be reinterpreted
as an authority grant, Locus credential, broker lease, or execution permit. See
the design-era grant lifecycle specification; the
issuance contract is the original design contract and
retains design-era status language.
Phantom ships an MCP server so AI coding tools can inspect value-blind metadata and request gated lifecycle operations. MCP responses do not return real secret values.
Use this read-only path before exploring the full tool catalog:
v0.7.9 GitHub release.phantom setup --client codex,
replacing codex with claude, cursor, or windsurf when appropriate.phantom_capability, then phantom_status. Report the
value-blind authority, hard denials, project ID, dotenv protection counts, and
service mappings. Do not request or reveal secret values.”phantom_check with no arguments. Report findings
without changing files or credentials.”These calls inspect the configured local surface. They do not prove that cloud, team, deployment, provider, authority-kernel, or customer workflows are active or accepted.
phantom_capability reports authority and hard denials for the small facade (not the separately gated advanced compatibility catalog); phantom_do canonicalizes one closed Cargo action and reports the exact activation blockers without executing it; phantom_setup_workspace proposes an exact value-blind plan, creates a bearerless apply request after revalidation, or reads authenticated request status. Provisioning the machine-local seal key and creating a request both require confirm plus an out-of-band approval token; MCP never claims or applies the request.phantom_list_secrets, phantom_status, phantom_init, phantom_add_secret_interactive, phantom_add_secret (deprecated; refuses plaintext), phantom_remove_secret, phantom_rotate, phantom_copy_secretphantom_doctor, phantom_why, phantom_check, phantom_env, phantom_validate_secret, phantom_validate_allphantom_wrap, phantom_unwrap, phantom_sync, phantom_cloud_push, phantom_cloud_pull, phantom_cloud_statusphantom_team_list, phantom_team_create, phantom_team_members, phantom_team_invite, phantom_team_key_publish, phantom_team_vault_push, phantom_team_vault_pullphantom_audit_recent, phantom_audit_stats, phantom_audit_analytics, phantom_audit_anomalies, phantom_audit_anomalies_realtime, phantom_audit_hotspot_alerts, phantom_audit_incidents, phantom_leak_incidents_realtime, phantom_audit_alerts, phantom_audit_export_report, phantom_compliance_status, phantom_rotate_with_candidate, phantom_rotate_promote, phantom_rotate_provider, phantom_rotate_with_expiry, phantom_list_with_expiry, phantom_secret_rotation_due, phantom_validation_schedule, phantom_validation_history, phantom_secrets_expiry_check, phantom_secrets_auto_rotate, phantom_expiry_enforce, phantom_rotation_schedule_next, phantom_apply_expiry_policyphantom_secrets_auto_rotate and phantom_rotate_with_expiry are deprecated
compatibility names for approved local phm_ token remaps. They do not rotate
a provider credential, renew TTL/rotated_at metadata, clear leak incidents,
or sync credentials. phantom_rotate_provider is also hard-denied before
credential or network access in 0.7.9. Team invites may assign only member or admin; ownership transfer
is not an invite role.
Tools that write state, retrieve or use credentials, or make provider/network
requests are disabled by default. They can reach their confirm: true and
one-use approval_token gates only when the operator sets
PHANTOM_MCP_EFFECTS=trusted-terminal in a server environment outside agent
authority. phantom mcp-approve requires attached stdin/stderr, shows the
bounded value-blind effect plus exact parameters, and requires a fresh typed
challenge before approval. A same-user shell or agent-controlled PTY can
defeat that ceremony; leave effects disabled unless the approval command and
~/.phantom approval storage are outside the requesting agent's authority.
Conditional tools keep
their inspection mode ungated and activate both gates only for the effectful
parameters. Real secret values are never accepted as MCP tool arguments; new
secrets are entered out-of-band in a trusted terminal. The exact 54-tool names,
descriptions, and JSON schemas are mirrored from runtime tools/list into
mcp-registry/server.json, and release smoke tests
reject any drift.
phantom_rotate_with_candidate and phantom_rotate_promote remain in the
54-tool compatibility catalog as deprecated hard denials. They never create,
validate, or promote a candidate and never change vault or shadow metadata;
phantom_rotate_provider is also hard-denied before credential or network
access in 0.7.9. phantom add creates new names only and refuses existing-name
replacement before reading a value. Replacing a credential therefore requires
a separately reviewed provider rotation plus an explicit trusted-terminal
remove-and-add sequence; those are distinct, non-atomic operations.
Workspace setup is deliberately split across trust boundaries. MCP can call
phantom_setup_workspace with phase=propose, then phase=request_apply using
the exact returned plan_id and pre_state_id. The first proposal requires
dual approval only when it must provision the machine-local plan-seal key;
request_apply always requires dual approval because it persists a value-free
request outside the repository. Apply it from an attached trusted terminal
with phantom workspace apply --request <ID>; MCP has no claim or apply
operation.
One command per AI client — Phantom writes the right config file in the right place:
phantom setup --client claude # project MCP; see docs/claude-code.md for v0.7.9 migration
phantom setup --client cursor # ~/.cursor/mcp.json
phantom setup --client windsurf # ~/.codeium/windsurf/mcp_config.json
phantom setup --client codex # ~/.codex/config.toml
phantom setup --client gemini # ~/.gemini/settings.json (Gemini CLI)
phantom setup --client claude --print # snippet to stdout for any other client
Install both v0.7.9 release binaries before setup. Version 0.7.9 records the
running phantom executable with mcp serve when it can resolve that executable,
otherwise it looks for a local standalone phantom-mcp. Setup has no network
package-runner fallback and fails closed when neither local runtime is
executable. Inspect the generated entry, then restart the AI tool so it picks up
the new config.
Phantom's stdio MCP server can be configured in MCP clients that support local command servers. The setup writer currently has reviewed presets for Claude Code, Cursor, Windsurf, Codex, and Gemini CLI; other clients require their own compatible configuration.
Back up and restore a vault on the same keychain machine with client-side encryption. Phantom Cloud receives the encrypted vault payload rather than the decrypted secret values; endpoint, client, account, and OS-keychain security remain part of the trust boundary. The cloud encryption key is generated and stored in the local OS keychain. Phantom does not currently ship key transfer or recovery, so account sign-in without that key cannot decrypt this backup. Login, logout, cloud push/pull, and browser open are not headless agent actions: run them with stdin, stdout, and stderr attached to a terminal outside the requesting agent's authority and complete each fresh exact typed challenge. The public hosted service is not currently commissioned for authenticated cloud or dashboard use. The commands below document the source-backed flow for a future verified deployment and entitled account; they are not a live-service acceptance receipt.
$ phantom login
# Opens GitHub OAuth (device code flow)
$ phantom cloud push
# After commissioning: encrypted client-side and uploaded to the configured service
$ phantom cloud pull # restore on the machine that holds the original cloud key
# Downloaded and decrypted locally
$ phantom open
# After commissioning: opens the configured read-only dashboard.
Cloud backup uses ChaCha20-Poly1305 with a random client-side passphrase stored in the OS keychain and derived via Argon2id for encryption. The server stores only ciphertext. Team vaults are separate: they wrap a shared vault key to each registered member's X25519 public key; that does not make personal cloud backups portable.
The repository includes fixed-membership team-vault workflows intended for a
planned hosted Pro pilot. Pilot eligibility, team and vault limits, and pricing
are TBD; no self-serve checkout is commissioned. The
service path stores ciphertext plus per-member encrypted key shares. Team roles
gate invitation management, but all members can read and write the shared vault;
member removal and atomic offboarding rotation are not shipped. Treat this as a
pilot capability until the hosted service and account entitlement are commissioned.
CLI team mutations require the same attached trusted-terminal ceremony before
credential, keypair, vault-value, or network access. MCP team reads and writes
are provider requests and remain disabled by default behind confirm plus a
one-use out-of-band approval token.
$ phantom team create "engineering"
# Creates a team; you become the owner.
$ phantom team invite <team_id> <github-username>
# Invites by GitHub login.
$ phantom team key-publish <team_id>
# Registers your X25519 public key on the team.
# (Run once per team; the private key stays in the OS keychain.)
$ phantom team vault-push <team_id>
# Encrypts the current project's vault with a fresh symmetric key,
# wraps that key (X25519 + ChaCha20-Poly1305) for every member that
# has a registered public key, then uploads.
$ phantom team vault-pull <team_id> # on a teammate's machine
# Pulls, decrypts the per-member share with their private key,
# decrypts the vault, writes secrets locally.
The pq-hybrid cargo feature adds an experimental X-Wing (X25519 + ML-KEM-768)
team key share. It is off by default and does not change default behavior: the
default build keeps the X25519 share described above. The X-Wing share is local
only. phm.dev does not accept it yet, because the hosted team key route takes
32-byte public keys and an X-Wing public key is 1216 bytes. The x-wing and
ml-kem crates are unaudited, and X-Wing is pre-1.0. Do not rely on it for
production secrets.
The proxy's HTTPS client uses the aws-lc-rs provider and offers the hybrid X25519MLKEM768 group first, then X25519, secp256r1 and secp384r1. A hybrid key exchange is used only if the upstream server supports it. A hermetic test confirms that a local server accepting only X25519MLKEM768 negotiates it with the proxy, and that a server sharing no group with the proxy fails the handshake. Which group a given provider negotiates is not tested. To see the groups this build offers, read from the proxy's own TLS config:
phantom doctor --pq
After a hosted deployment is commissioned and accepted, its read-only team dashboard is designed to show team memberships and member lists.
Phantom 0.7.9 does not execute live provider issuance or rotation. Every
provider path—single-provider CLI, batch CLI, MCP, grant enrollment, additive
issuance, and destructive/rolling refresh—is hard-denied before provider
credential access and before network I/O. Operators must rotate at the vendor,
then use Phantom's trusted local secret-entry path. Source adapters and exact
cfg(test) mocks are transaction-design evidence, not provider activation,
commissioning, or acceptance.
phantom rotate --batch remains metadata-only discovery/manual guidance and
fails closed before vendor execution. No single-provider exception exists.
phantom vault migrate-linux from a trusted terminal to copy and verify its vault in persistent Secret Service before switching. Phantom does not claim Secure Enclave hardware binding. Argon2id uses m=64 MiB, t=3, p=1.phm_ placeholders in .env, rotatable on demandPHANTOM_PROXY_TOKEN; CLI-generated SDK URLs include it for compatibility, and header-aware clients can opt into x-phantom-proxy-token with PHANTOM_PROXY_HEADER_AUTH_ONLY=1phm_ tokens. After authenticating and matching an exact built-in route, the proxy injects that route's configured vault secret only into its fixed authentication header; a missing mapping fails before any upstream call. Request bodies are still collected under a hard byte cap before forwarding. Custom routes: phantom start serves custom routes from .phantom.toml; phantom exec refuses them and runs only Phantom's exact built-in routes. The reason: phantom start is run by a person on project config they have reviewed. phantom exec launches an agent, and anything in the repository, .phantom.toml included, may have been written by that agent or by an untrusted change, so accepting custom routes there would widen the attack surface.*_KEY, *_TOKEN, sk-*, ghp_*) from config (NODE_ENV, PORT)phantom check --staged when Git invokes the hook; it checks staged dotenv content plus a bounded set of hardcoded-key prefixes. Hooks can be bypassed or skipped, so CI and a broader secret scanner remain necessary..env.PHANTOM_AUDIT=1 writes vault events as JSONL to ~/.phantom/audit.log. Each entry is chained with HMAC-SHA256; phantom audit verify detects tampering. phantom audit show/tail/path for log access.phantom wrap wraps selected runtime/build scripts (dev, start, serve, build, deploy, preview) and deliberately leaves test, lint, type, and format scripts alonephantom watch reports new unprotected secrets; legacy --auto hard-denies before mutation, so protection stays a reviewed transactional phantom initphantom init --all <DIR> processes eligible repositories found within a five-level bounded scan and stops below the first matching repository; use --dry-run to verify the exact set and --jobs N to control parallelismphantom setup --client claude|cursor|windsurf|codex|gemini writes the right MCP config for each AI tool, or --print for a generic snippetphantom agent doctor and phantom agent report --json report bounded protection findings and activation gaps; they do not certify a repository or agent as safephantom doctor reports install source, vault backend, audit-log status, Argon2 params, and MCP wiring per clientphantom why <KEY> explains detection heuristicsphantom copy shares secrets between project vaultsHomebrew 6 requires explicit formula trust for third-party taps:
$ brew tap ashlrai/phantom
$ brew trust --formula ashlrai/phantom/phantom
$ brew install ashlrai/phantom/phantom
This formula installs both phantom and phantom-mcp from the immutable
v0.7.8 GitHub release.
It has not yet been bumped to v0.7.9. Until it is, a Homebrew install writes
Claude Code MCP registration to the legacy location; see the
Claude Code guide for the manual .mcp.json step, or use
the v0.7.9 assets below.
Use the asset matching your OS and architecture. Download its adjacent
.sha256 file from the release, verify it before extraction, and place both
phantom and phantom-mcp (.exe on Windows) on PATH.
On Linux, verify with sha256sum -c <archive>.sha256. On Windows, compare
Get-FileHash -Algorithm SHA256 <archive> with the published sidecar.
The v0.7.9 tag resolves to source commit
7a51ce512ec4aee12cc29ff859036af63fbe93db:
$ git clone https://github.com/ashlrai/phantom-secrets.git
$ cd phantom-secrets
$ git checkout 7a51ce512ec4aee12cc29ff859036af63fbe93db
$ cargo build --release --locked --bin phantom --bin phantom-mcp
Do not treat unpinned package-manager commands as v0.7.9. In the exact
2026-09-29 registry snapshot, npm latest remains 0.6.0; the immutable npm 0.7.4 wrappers
exist only under release-candidate after failing cross-platform acceptance.
No npm 0.7.9, crates.io 0.7.9, or MCP Registry 0.7.9 publication is
represented by this GitHub release receipt. Homebrew is separately published
and verified through its tap, and currently remains at v0.7.8.
[!IMPORTANT] Release-state snapshot (verified 2026-09-29): the current release is the immutable
v0.7.9GitHub release at source commit7a51ce512ec4aee12cc29ff859036af63fbe93db. Its 19-asset release set, checksums, archive-specific SPDX SBOMs, GitHub provenance and SBOM attestations, and all six native release rows are bound to that immutable release record by tag-bound workflow 34153902556. Exact public registry endpoints were requeried on 2026-09-29. The Homebrew formula still installs the previous reviewedv0.7.8until its tap is bumped; npmlatestremains0.6.0, and the npm0.7.4wrappers remain quarantined underrelease-candidateafter failed npm-channel acceptance. The GitHub receipt alone does not prove the separately verified Homebrew formula, an npm or crates.io package, MCP Registry entry, hosted-service commissioning, provider activation, signing/notarization, certification, or customer acceptance. See release readiness and platform support.
$ phantom setup --client claude # or cursor, windsurf, codex, gemini
The Rust workspace is organized as product crates plus fail-closed execution-kernel foundations. Presence in the workspace does not mean a foundation is activated in production.
Project-local effects resolve from the retained root acquired with the project transaction lock; global editor configuration is separately bounded beneath a retained user-config authority. A renamed ambient path and replacement decoy do not redirect those in-progress governed writes. These controls are not a same-user sandbox: local locks coordinate Phantom writers, and another process with equivalent user authority remains inside the threat model. See the architecture, threat model, and platform evidence matrix.
Initialization retains the reviewed project-root identity and exact dotenv/config leaf snapshots before vault provisioning, then revalidates root and leaf identity, bytes, and permissions under the project lock before mutation. On Windows, new private anchored files/directories establish a protected current-user DACL before content bytes, while replacements preserve the reviewed exact DACL and inheritance state before writing. Those Windows properties are source contracts; protected native Windows CI acceptance remains pending.
CommittedVerifiedButDurabilityUncertain is committed, exactly verified
success with a value-free warning/receipt and must not be rolled back or
retried. CommittedButUncertain is the distinct Partial case requiring
operator reconciliation because verification or durability remains unresolved.
Vault-backed mutations resolve machine-local vault/application authority before the project transaction lock, then compare the acquired root identity and reread the exact config through that lock. This avoids the shared process-environment/project-lock inversion without trusting project bytes during the gap.
Phantom also tracks a pinned Rama-derived engineering standard for explicit network stacks, modular crates, runnable examples, and tiered platform CI. Rama is a benchmark, not a dependency, and the comparison is not a feature or platform-parity claim.
apps/web contains the Next.js site and backend routes for cloud vault sync, GitHub device authentication, and Stripe billing. The repository source and local tests are separate evidence from the currently deployed state at phm.dev.
Registry tracks: npm latest currently resolves
phantom-secrets and
phantom-secrets-mcp at
0.6.0. Exact 0.7.4 wrappers remain public only under release-candidate
after failing native npm-channel acceptance; do not use that candidate as the
reviewed v0.7.9 GitHub release path.
CI runs locked, all-target workspace builds and tests on macOS, Linux, and Windows runner environments, plus formatting, Clippy, and npm release-mapping checks. Release builds and native end-to-end acceptance are separate evidence layers; see Platform support.
phantom sync.phm_ prefix distinguishes Phantom tokens from supported real-key formats; random collisions are cryptographically negligible, not mathematically impossibleSee SECURITY.md for the responsible disclosure policy and THREAT_MODEL.md for the full threat model (assets, actors, mitigations, known gaps, cryptography summary).
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. See the enterprise adoption guide
for shipped-versus-planned gates, or contact [email protected] to discuss a
written scope.
Phantom Secrets is one of the open-source tools from Ashlr, a forward-deployed engineering company. Its siblings: Lexicon, Locus, Ashlr Stack, Ashlr Markdown, Ashlr plugin.
Focused contributions are welcome. Start with
CONTRIBUTING.md, the
examples index, or a
discussion. The
project does not assume that a good first issue label is populated. Follow
CODE_OF_CONDUCT.md, and use
SECURITY.md rather than a public issue for vulnerabilities.
MIT — see LICENSE.
Value-blind secret metadata and gated workflows for AI coding agents through Phantom's local proxy.
{ "mcpServers": { "io.github.ashlrai-phantom-secrets-mcp": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}Herramientas
Aún no hay lista de herramientas. Los servidores remotos la reciben tras la primera comprobación de estado.
Preguntas frecuentes
Copia en esta página la configuración stdio para Cursor, Claude Desktop, Claude Code o VS Code. Usa la instalación del publicador, no un proxy de PlugMCP.
Este registro no indica ninguna variable de entorno obligatoria.
Phantom Secrets se ejecuta localmente por stdio.
Última comprobación: 2026-11-15. Value-blind secret metadata and gated workflows for AI coding agents through Phantom's local proxy.