What Prodpeek is¶
A short version, then the parts that matter.
The short version¶
You run one container on your own network. It holds the credentials for your production systems — Coolify, Grafana, a Postgres, a Prometheus — encrypted at rest. Your agents and developers get a personal key to Prodpeek, not to those systems.
When an agent calls a tool, Prodpeek checks it against a published read-only policy for that service, refuses anything not explicitly allowed, and writes a line to a tamper-evident log either way. The credential is injected on the way out and never travels back.
The two problems it solves¶
Agents must not be able to write to production. Not because they are malicious — because they are eager. An agent mid-troubleshooting finds the cause and "just fixes" it. It was right about the cause. It also just restarted production in the middle of the afternoon.
Access must be easy to hand out and easy to take back. Right now four developers hold four sets of keys to Grafana, DigitalOcean and AWS that nobody rotates and nobody can enumerate. With Prodpeek each person has one key, issued centrally, with an expiry, and every call is attributed to them.
The four ideas¶
1. Deny by default¶
A tool nobody wrote a rule for is refused because it is not there, never
because someone remembered to forbid it. A vendor shipping a new delete_everything
tool tomorrow is refused tomorrow, by a policy written today.
2. Filtering is not enforcement¶
Hiding a tool from the list is not the same as refusing it. Prodpeek applies the allowlist twice, in two independent code paths — one shapes what an agent sees, the other judges what an agent calls. Calling a tool by its raw name that was never advertised gets refused by the second one.
That is not a hypothetical. It is CVE-2026-46519: a gateway whose filter and executor shared an implementation, where a hidden tool was still callable. Prodpeek has a test asserting the two do not share code.
3. Some reads are the risk¶
"Read-only" sounds safe until get_application_envs returns your database
password. Coolify's list_private_keys is a read. So is GitHub's secret
scanning alert list — which contains the detected secrets.
Prodpeek classifies those read_leaks, denies them, and never sends their output
to an LLM. That classification is the thing a generic "read-only proxy" cannot do,
because it requires somebody to have looked at each tool and decided.
4. Two fences, and saying when there is only one¶
Tier 1 means the credential itself cannot write — a Coolify read-only token, a non-superuser Postgres role, a fine-grained GitHub token. Prodpeek is the second fence.
Tier 2 means the gateway is the only fence, because the vendor's credential
is coarse or absent. Prometheus has no authentication at all, so
prometheus/read-only is Tier 2 and says so in the file.
An honest Tier 2 is worth more than a Tier 1 claim nobody can prove. Every profile states which it is.
What you interact with¶
| Who | What for | |
|---|---|---|
/mcp |
agents, developers | reading production, with a client key |
/admin |
you, in a browser | connecting services, minting keys, reading the log |
/api/v1 |
CI, the CLI, an admin agent | the same operations, as JSON, with an admin key |
/mcp-admin |
an admin agent | the same operations, as MCP tools |
A client key opens /mcp and nothing else. An admin key opens the other two and
never /mcp. Present one at the wrong door and you get wrong_door, audited —
in both directions, deliberately. An admin key is not a skeleton key.
What comes free¶
Uptime monitoring, unlicensed and never blocked. Every service you register is watched automatically. This keeps working on an expired trial — it is the reason to install Prodpeek before you are ready to pay for it.
Evidence packs. When a monitor goes down, Prodpeek runs the reads that service's profile says to run first, through its own gate, and attaches the results to the incident. You arrive to facts instead of a blank terminal.
prodpeek prove. Hourly, your instance calls every denied tool by raw name
against itself and asserts each one is refused with zero upstream calls. It
verifies the audit chain and asks each vendor what your credential can actually
do. That runs on your box, about your instance — central verification is a claim
about last Tuesday.