Read-only agent gateway

You want agents debugging production. You just don't trust them there.

Prodpeek gives your AI agents verified read-only access to production. They can look. They can't touch.

Self-host in 10 minutes See how verification works

Runs on your network No agent ever holds a credential Every call logged

prodpeek · /mcp principal: dev-anders
github__list_pull_requests ALLOWED
reason allowed_by_profile profile github/triage-read tier 1
github__merge_pull_request DENIED
reason tool_explicitly_denied classification write
audit seq 1042 · hash-chained upstream credential never sent to agent

This keeps happening

The agent didn't mean to. It did it anyway.

Every one of these was a team that trusted a tool boundary that turned out not to be a boundary.

2025 · Replit

It deleted the production database

An agent dropped a live database despite eleven all-caps instructions not to — then fabricated records to cover what it had done.

Reported by The Register

June 2025 · Asana

A first-party MCP server leaked across tenants

Asana's own MCP server shipped with a cross-tenant flaw that exposed roughly 1,000 customers' data. It ran for over a month before anyone caught it.

Reported by The Register

GitHub MCP · Invariant Labs

Prompt injection turned a read into an exfiltration

The "lethal trifecta" — private data, untrusted instructions, and a way out. Simon Willison's assessment: we still don't have convincing mitigations.

Research by Invariant Labs / devclass

How it works

Three steps. One container. Your network.

Prodpeek sits between your agents and your services. Nothing about your infrastructure leaves your infrastructure.

Connect your services

One self-hosted instance. Add each upstream with a read-only token — encrypted at rest, and never handed to an agent.

Hand out one key each

A key per developer and per agent, shown once. Every call it makes is attributed to it, so "who asked for that" always has an answer.

Every call is checked and logged

The policy runs on each call, not just when tools are listed. Allowed reads pass through. Everything else is refused, with a reason.

Your agentClaude, Cursor, CI
Prodpeekpolicy + audit
github grafana postgres

The guarantee

Filtering is not enforcement.

Most gateways hide dangerous tools from the list and call it read-only. Hiding a tool does not stop anyone from calling it by name.

How that fails

CVE-2026-46519 (CVSS 8.8): a server's read-only setting filtered tools at the discovery layer. A tool hidden from tools/list was still callable by name through tools/call. One request deleted pods.

The same shape has shown up elsewhere. Vendors describe these filters as best-effort content filters rather than authorization boundaries — which is honest, and which is exactly the problem.

What Prodpeek does instead

The allowlist is applied twice

Once to shape the list a client sees — a courtesy, nothing more. Again, deny-by-default, on every tools/call, including calls naming tools that were never advertised.

The two checks are separate code paths, and a test asserts they stay separate. Sharing one implementation is precisely how the CVE happened.

2×

Independent enforcement paths, tested in isolation and end to end over real HTTP

0

Write tools advertised, ever — there is no write path to enable, not even behind a flag

100%

Of calls written to an append-only, hash-chained log you can verify yourself

Profiles

The policy is a file you can read.

One file per service, listing every tool and the verdict behind it. No URLs, no credentials — the loader rejects a profile that tries to carry either. Your environment stays in your instance; only the policy is published.

github/triage-read Draft

Pull requests and issues, for triage. Tier 1.

list_pull_requests get_pull_request list_issues create_pull_request merge_pull_request
grafana/oncall-read Draft

Dashboards and logs for an incident. Tier 2.

search_dashboards query_loki_logs get_datasource_by_uid reads that leak are denied
coolify/read-only Draft

Deployments and service state. First real target.

list_applications get_deployment restart_application deploy
confluence/docs-read Draft

Runbooks and architecture pages, scoped by space.

get_page search spaces outside the allowlist
Every profile says draft today. None says verified.

verified is going to mean something specific and earned: every allowed tool called against the real service and seen to succeed, every denied tool attacked twice — once with the least-privilege credential, once through the gateway by raw tools/call — and anything the vendor credential failed to block written down rather than quietly dropped. The harness that does this is the next milestone. Until it has run, a test in CI stops any profile from claiming otherwise.

Who this is for

Built for teams of 5 to 100 developers.

Agent governance platforms are built for organisations with a procurement department. If that isn't you, most of what they sell is overhead.

One Docker command. No Kubernetes, no service mesh, no platform team required to keep it alive.

No sales call. The price is on this page. You can run it before you talk to anyone.

Your infrastructure. It runs on your network, against your credentials, inside your trust boundary.

No identity-provider project. Mint a key per developer and per agent. That is the whole onboarding.

Small enough to audit. The decision engine is a few hundred lines with no third-party dependencies. Read it before you trust it.

No annual contract. The gateway keeps working whether or not you pay for profile updates.

Get started

Self-host in 10 minutes.

Bring it up, add an upstream with a read-only token, mint a key, point your agent at it. The contract suite runs first, with no credentials and no network.

Terminal 
cp .env.example .env
docker compose run --rm prodpeek gen-key   # paste into .env
docker compose up --build

# then point the agent at the gateway
claude mcp add --transport http prodpeek http://localhost:8787/mcp \
  --header "Authorization: Bearer <key>"

Open http://localhost:8787/admin to add services and mint keys. Test connection enumerates the live server and shows you exactly which tools the policy allows and denies — before any agent touches it.

Pricing

The gateway is yours. The verification is the product.

Running Prodpeek costs nothing. What you can pay for is somebody else doing the work of proving, per tool, that a profile is what it claims to be.

Self-host

The gateway, the console, and the community profiles.

Free

Run as many instances as you like

  • Full policy engine and audit log
  • Admin console and key management
  • Community profiles, as-is
  • No account, no telemetry
Start self-hosting

Pro

Verified profiles, kept current as upstreams change.

— / team / month

Price to be set before launch

  • Everything in Self-host
  • Verified profiles with recorded harness runs
  • Updates when an upstream adds tools
  • Negative-test records for every denial
Get notified at launch

Team

Priority on the services you actually depend on.

— / team / month

Price to be set before launch

  • Everything in Pro
  • Priority profiles for your stack
  • Direct support channel
  • Input on the profile roadmap
Get notified at launch

FAQ

The questions a security reviewer asks.

Where does it run, and what leaves my network?

One container on your own infrastructure. Your agents talk to it; it talks to your upstreams. Upstream credentials are encrypted at rest in its local database and are never included in anything an agent receives.

What can an agent actually see?

Only the tools its profile allows, with the argument constraints that profile sets — a page-size ceiling, a Confluence space allowlist, a required repository.

Reads that return secrets are treated as dangerous even though they are reads. get_datasource_by_uid returns datasource credentials, so it is denied outright. There is no redaction layer yet, and we would rather deny a leaky read than claim to have scrubbed it.

What happens when a call is denied?

The agent gets a structured refusal naming the reason — tool_explicitly_denied, tool_not_in_allowlist, argument_constraint_violated, and so on — and the same reason is written to the audit log against the key that made the call.

Reasons are stable identifiers rather than prose, so denials group cleanly by cause when you go looking for what your agents keep trying to do.

What if a profile is wrong?

The decision table is published as a plain file: every row is one call and the verdict the engine must return, with a note on why. The test suite executes that file, so it cannot drift from the code. If you disagree with a row, that is a bug report — quote the row's id.

Profiles are drafts until the verification harness has run against a live service. None of them claims otherwise today, and CI enforces that.

Do you have SOC 2?

No. Prodpeek is pre-launch and built by a very small team, and a SOC 2 report would be a claim about a company rather than about this software.

What is offered instead: it runs inside your boundary, so your auditors are looking at your own infrastructure; the decision engine is small enough to read in one sitting; and every decision it makes is in a hash-chained log you can verify without trusting us.

Is it open source?

The licence has not been settled yet, and nothing has been published under one — a deliberate pause rather than an oversight. The intended shape is a readable, open runtime with the verified profiles and harness as the paid asset, but until that is decided this page is not going to promise you a licence it cannot deliver.