For teams that let AI agents near production

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

Prodpeek is a self-hosted gateway between Claude Code, Cursor or your CI agent and your production stack. Logs, deployments, dashboards and read-only queries go through. Deploys, restarts, writes and deletes are refused on every call. Every call is logged.

Request early access See how it works

Runs on your network Agents never hold a credential Every call logged

prodpeek · /mcp key: dev-anders · ttl 8h
coolify__get_logs ALLOWED
reason allowed_by_profile profile coolify/read-only
postgres__select ALLOWED
reason allowed_by_profile runs in BEGIN READ ONLY
coolify__deploy_application DENIED
reason tool_explicitly_denied classification write
audit seq 1042 · hash-chained upstream credential never sent to agent

The problem

A production token doesn't know the difference between reading and deleting.

Connect an MCP server and the agent gets every tool it exposes, the delete sitting next to the list. Most vendor tokens can't be scoped to reads alone. And the instruction telling the agent to be careful is just another prompt.

2025 · Replit

The agent deleted the production database

It had eleven all-caps instructions not to touch it. It dropped the live database anyway, then fabricated records to hide what it had done.

Reported by The Register

June 2025 · Asana

A vendor's own MCP server leaked across tenants

Asana's first-party server exposed data from roughly 1,000 customers to each other. It ran for over a month before anyone caught it.

Reported by The Register

2025 · GitHub MCP

A prompt injection turned a read into an exfiltration

Invariant Labs showed a public issue steering an agent into leaking private repository data. Simon Willison's assessment: still no convincing mitigations.

Research by Invariant Labs / devclass

What your agent can do

Everything you'd let a new hire read on day one. Nothing they could break.

One policy per service, one line per tool, each with a verdict. Reads that return secrets are treated as writes and refused with the rest.

Coolifycoolify/read-only
Applications, services and databases. Deployment status and history. Application logs. Backups list.
Deploy, start, stop, restart. Environment variables. Private keys.
Postgrespostgres/read-only
Schemas, tables, indexes, table stats, activity. One SELECT at a time, inside a read-only transaction, row-capped, with a timeout.
INSERT, UPDATE, DELETE, DDL. COPY TO PROGRAM. Reading files off the server.
Grafanagrafana/read-only
Dashboards and panel queries. Datasource queries. Alert rules and firing alerts. Annotations.
Datasource credentials. Service accounts, users, API keys. Creating, changing or deleting anything.
GitHubgithub/read-only
Repositories, commits, diffs. Pull requests and issues. Workflow runs and job logs.
Merge, push, file writes. Secret-scanning alerts. Repository and org secrets.
OpenAPIany internal API
Every GET the spec describes, with the spec's own limits.
Every POST, PUT, PATCH and DELETE. Any GET that looks like it returns a secret.
SSH hostssh/diagnostics-read
Load, disk, memory, listening ports. Service status and journal tail. Container list and logs.
A shell. Arbitrary commands. Arbitrary file reads. rsync.

Also DigitalOcean, Cloudflare, Prometheus, Confluence, and OpenAPI (any internal API). Every service, with a guide to creating a key that can't do more than the policy allows.

Verified, and kept verified

A profile is a claim. Prodpeek tests the claim.

Every allowed tool is exercised against the real service and seen to succeed. Every refused tool is called through the gateway by name and seen to be refused. The result is a signed verdict your instance checks before it trusts a profile.

  • Re-verified when the vendor ships. A new upstream version re-runs the whole suite. Verdicts age and expire; they are never assumed.
  • Pulled the moment it drifts. If a vendor adds a tool that could write, or a refusal stops holding, the profile is revoked and your instance refuses that service until a human has looked.
  • Nothing you have to run. The harness runs on our side against real testbeds. Your instance only polls for the verdict and checks its signature.

How it works

One container between your agents and your services.

Prodpeek runs on your network, holds the upstream credentials, and hands each agent a short-lived key instead. Nothing about your infrastructure leaves it.

Connect your services

Add each upstream with a read-only token from that vendor. The token is encrypted at rest inside Prodpeek. No agent ever sees it.

Mint a key per person and per agent

Shown once, short-lived, tied to the services it may reach. "Who asked for that?" always has an answer.

Point the agent at the gateway

One MCP endpoint. The policy runs on every call, not only when tools are listed. Allowed reads pass through. Everything else gets a refusal with a reason.

Your agentClaude Code, Cursor, CI
Prodpeekpolicy + audit
coolify postgres grafana

See the architecture

Works with Claude Code, Cursor, Codex CLI, VS Code, and any other MCP client that speaks HTTP. One endpoint, one key, every agent.

Why it holds

Hiding a tool is not the same as refusing it.

Most gateways remove dangerous tools from the list an agent sees and call that read-only. A tool that isn't listed can still be called 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.

Vendors describe these filters as best-effort, not as authorization boundaries. That is honest, and it is exactly the problem.

What Prodpeek does instead

The allowlist runs twice

Once to shape the list a client sees. Again, independently and 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 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

Who it's for

Small teams that run their own production.

Built for the team where the person who could fix production at 2am is also the person shipping features at 2pm. Not for the organisation with a platform team and a procurement process.

The CTO of a 5 to 30 person product team

You want Claude Code to look at last night's deploy and the error logs before you do. You don't want it holding a token that could also redeploy.

The one DevOps person

Every "can you check prod?" lands on you. Give the developers and their agents a read-only view, and most of those questions answer themselves.

The consultant running production for several clients

One instance, one project per client, separate keys and audit logs. Each client can see exactly what your agents were allowed to read, and when.

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

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.

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

Setup

One container. About ten minutes.

Bring it up, add a service with its read-only token, mint a key, point your agent at it. Test connection in the console shows which tools the policy allows and refuses before any agent touches it.

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>"

Prodpeek is opening to its first pilot teams now. Request access and you get the image, the setup guide, and a direct line to the person who built it.

Pricing

One flat price per team.

14-day free trial, no card. After that a monthly price per team, not per call and not per agent. The price will be on this page, and you can run it before you ever have to talk to anyone.

What a team gets

  • The gateway, the console and key management, self-hosted
  • Every service profile, verified against the real service and re-verified when it changes
  • The append-only audit log, per project and per key
  • Uptime monitoring of your connected services, free, licensed or not
  • No account with us, no telemetry, no data leaving your box

What happens if you stop paying

The container stays up, the console keeps working, your configuration and audit log stay intact. Agent calls through the gateway are refused until you renew. Nothing is deleted and nothing is held hostage.

Consultants running one instance for several clients: there will be a per-project price, so each client sees their own line.

Request early access

Project status

Where it is today.

As of 2026-09-25. This block is the one place on the page that describes the current build rather than the product.

Works now

  • The gateway and the console
  • Keys per developer and per agent
  • Services for Coolify, GitHub, Grafana, Prometheus, DigitalOcean, Cloudflare, Confluence, Postgres, SSH and Git
  • An OpenAPI connector: an internal API's spec becomes a read-only menu
  • Policy enforced on every call
  • Hash-chained audit log
  • Uptime monitoring of connected services
  • Test connection shows allowed and refused tools before an agent is connected

Next

  • The verification harness and signed verdicts. Profiles are marked example today
  • The control plane that revokes a drifted profile
  • Licensing and a public image

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. Nothing is sent to us.

How is this different from the read-only flag on GitHub's or Grafana's MCP server?

Those flags filter what one server lists, and the agent still holds that vendor's token. Prodpeek holds the token, enforces the policy on every call rather than at listing time, and does it across every service from one key with one audit log.

What can an agent actually see?

Only the tools its profile allows, with the argument limits 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 refused outright. Sensitive values that turn up inside an otherwise legitimate read, such as a connection string in a log line, are masked before the agent sees them.

What happens when a call is refused?

The agent gets a structured refusal naming the reason, such as tool_explicitly_denied, tool_not_in_allowlist or argument_constraint_violated. The same reason is written to the audit log against the key that made the call.

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

Which agents does it work with?

Anything that speaks MCP over HTTP and can send a bearer header. Claude Code is what it is built and tested with. Cursor, Codex CLI, VS Code and a plain script all fit the same shape.

What if a profile is wrong?

The decision table is 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.

And a profile never stays wrong quietly. Each one is verified against the live service, re-verified when that service changes, and revoked from every instance the moment a refusal stops holding.

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 policy it enforces is a file you can read; and every decision it makes is in a hash-chained log you can verify without trusting us.

Is it open source?

The policies are open. The runtime is not. Every profile is a plain YAML file listing each tool and its verdict, and those files are published so anyone can check exactly what an agent was allowed to read. The gateway itself is commercial software you run on your own box.