An agent proposes reading .env. You would like that proposal stopped before the file enters its conversation. If the value is already in the conversation, you would at least like to know that it went to the model provider. Vantage, on today's Product Hunt board, tries to cover both moments. It wraps Claude Code, Codex, Copilot CLI, OpenCode or pi; meters their requests through a local proxy; and uses each agent's hook to judge tool calls against file and command rules.
Those two moments are easy to conflate. I built the open-source CLI, ran its mock demo, and sent synthetic actions through its real Codex hook. A configured .env rule stopped the read. A synthetic DB_PASSWORD already present in a tool result passed through the proxy to my local mock provider unchanged, and Vantage reported it. That is the distinction to understand before relying on this as a guardrail.
What ships
The Product Hunt listing links directly to the GitHub repository as Vantage's website. The pinned checkout is 5504ed313dbf55d7084809b53660e696790cc6db, package version 0.2.0, MIT, TypeScript, Node 22.6 or newer. The README describes five agents and one invocation: vantage run <agent>. The technical notes explain the split between its local API proxy, pre-tool hooks, session logs and cost meter.
The proxy reads model usage and subscription limit headers while passing traffic to the provider. vantage watch follows a session in a second terminal. Session logs give replay, stats, search and a git change summary their data. A .vantage/policy.json file supplies allow, warn, ask or deny levels by action type, plus patterns for individual files and commands. --max-cost and --max-quota can make later tool calls ask for approval after a threshold. The dollar figure is an estimate at API list prices, which matters on a subscription: the API-equivalent cost is not your subscription bill.
The default action policy is permissive. Reads and writes are allow; shell and network actions are warn, which observes rather than blocks. Running vantage policy init creates a starter file that asks before .env reads and several destructive commands and denies private-key files. You must enable that starter policy or write your own rules to get those file protections.
Setup and test boundary
I cloned the repository into ph-tests/vantage/vantage-src/ on Windows 11, using Node 24.11.1. npm ci installed four packages, npm run build completed, and the upstream npm test finished with 190 passing tests. My sandbox initially blocked Node's test subprocesses with spawn EPERM; the same suite passed when run with subprocess access. The sandbox's npm cache also lacked one tarball, so I installed with a local cache and network access. Neither was a Vantage test failure.
The product's node dist/cli.js demo command ran its fake agent, local proxy and mock Anthropic endpoint without an account. It printed Hello, world!, then in 1024, out 87, cache 512 and ~$0.0030. Those are the demo's fabricated usage and list-price calculation, not a measured bill or a live provider request.
I then ran a separate BDD harness built around the compiled CLI. Its scenario and driver are in ph-tests/vantage/vantage.feature and vantage.test.mjs. The harness creates an empty project and VANTAGE_HOME, runs policy init, calls vantage hook codex as the agent would, and records its decisions. A local HTTP server replaces the provider; it records the one request that reaches it. No real agent session, credential, account or external API entered this run.
A hook can stop the proposed action
The starter file gives .env an ask rule and *.pem a deny rule. I submitted five synthetic Codex pre-tool events to the CLI process, not just its exported policy function:
| Proposed Codex action | Hook result |
|---|---|
Read on the test project's .env | deny, with a reason saying Codex cannot pause to ask |
Read on notes.txt | No decision; Codex's ordinary permissions remain in force |
Read on private.pem | deny |
Bash with git push --force origin main | deny, converted from the starter rule's ask |
Bash with a PowerShell expression that builds .env from ".en" + "v" | No decision from the file rule |
The first, third and fourth calls also produced three decision records. For Codex, Vantage turns ask into a block because the hook cannot suspend a tool call for approval. Its reason tells the agent to leave the action to the user. Claude Code, Copilot CLI and pi can ask through their hook/UI path, according to the adapters and README; I did not run those agents. An allow or warn result deliberately emits no permission decision, so Vantage does not override an agent's own stricter permission settings.
The dynamic PowerShell path is a useful limit, not a bypass I found by fuzzing. File rules inspect literal file arguments and words in the shell command. They cannot know what a shell expression will evaluate to. The source says these are guardrails rather than an OS sandbox, and gives bash -c "$X" as the same class of case. If your threat model includes an agent trying to evade the text matcher, use the agent's own sandbox or OS isolation as well.
A warning observes a request that has already gone out
The proxy test supplied a fabricated tool-result line, DB_PASSWORD=Xk9vQ2mLp7Rt, in a Messages API request. My local mock received the exact JSON body, including the value. The response came back normally. Vantage's request callback reported one finding: value of DB_PASSWORD, sourced to the output of Read /synthetic/.env. The finding held a masked prefix and fingerprint, not the full value.
This is deliberate. The secret scanner observes the outgoing conversation and does not rewrite it. In vantage run, that finding becomes an alert that the value was sent and may need rotation. A warning cannot retroactively protect a credential. The preventive control is the pre-tool rule, before the file or command output enters the conversation.
I also passed five fabricated strings to the same scanner used by the proxy:
| Synthetic text | Finding |
|---|---|
aws_access_key_id=AKIAIOSFODNN7EXAMPLE | AWS access key |
DB_PASSWORD=syntheticlongpassword | Value of DB_PASSWORD |
aws_secret_access_key= followed by a 40-character value | None |
| Postgres URL with a password | None |
Authorization: Bearer followed by a long value | None |
The scanner covers named token formats and uppercase assignment names containing PASSWORD, SECRET, TOKEN, API_KEY and a few related terms. It does not claim to recognize every credential. The AWS pair is particularly clear: the example access-key ID is recognized, while the separate secret-value line is not. For .env files, the starter file rule offers broader prevention than these scanner patterns when the agent proposes reading the file by a visible path. The scanner still matters for a secret introduced by another route, or for telling you what may need rotation after a rule was not in place.
The rest of the surface
Vantage's choice of a separate watch terminal is sensible for a CLI wrapper. The agent owns its own terminal; a meter that redraws on top of it can break input. The source registers the hook for one run, starts the local proxy, and writes append-only session events. Logs include prompt and reply previews, tool names and targets, usage, decisions and masked secret findings. The README says the session folder is ignored by git automatically. I did not test a real long session or inspect an actual agent's UI, so I cannot judge how readable watch and replay remain over hours.
There are two different privacy promises here. Vantage's code keeps its own log locally and the README says it sends no telemetry; I did not perform a full network audit. The wrapped agent's model requests still leave the machine for its chosen provider through Vantage's proxy. My mock recorded exactly that forwarding behavior on localhost. "Everything stays on your machine" in the launch discussion describes Vantage's own storage, not model inference.
The pricing, subscription quota forecast, budget handoff, Codex WebSocket path, and other agents' hooks have upstream tests, but my firsthand checks did not exercise them with live provider traffic. I did not run Vantage against an authenticated Codex or Claude Code session, or verify that an installed agent fires the hook under every supported version. The 190 passing upstream tests are useful evidence of implementation coverage; they do not turn these untested integrations into my observations.
Verdict
Vantage has a good separation of responsibilities: a proxy for observing requests and usage, an agent hook for stopping proposed tools, and a local log for later review. The isolated run supports that design for the Codex hook and one mock provider request. I would initialize and inspect the policy before starting an agent, because the default policy does not block sensitive reads. I would also treat its secret alerts as incident notices: the value has already reached the provider, and the recognizer only covers known shapes. With those boundaries understood, it is a useful way to add visibility and narrower tool permissions without changing the agent's own configuration.
Reproduce it: clone Jovan158/vantage.ai at 5504ed313dbf55d7084809b53660e696790cc6db into ph-tests/vantage/vantage-src/, run npm ci, npm run build, npm test, then node ../vantage.test.mjs from the clone or node vantage.test.mjs from ph-tests/vantage/. The feature file names the scenarios; the driver builds a synthetic project, invokes the compiled CLI, and starts the localhost mock.
Sources: Product Hunt listing · Vantage README and landing page · technical notes · pinned repository source: src/agents/codex.ts, src/commands/hook.ts, src/rules.ts, src/secrets.ts, src/proxy.ts.