Proving it¶
Central verification says "we tested this profile against a testbed last Tuesday". That is worth something, and it is not what you actually want to know, which is: is the gate in front of my production doing its job right now?
Only your instance can answer that. So it answers hourly, and shows the answer.
What a run does¶
Four checks, none of which writes anything anywhere.
1. Enumerate and drift. Fetch tools/list from each connected service, hash
the canonical form, compare with the digest that was verified. A mismatch is
drifted — a tool was added, removed, or its schema changed.
2. The refusal sweep. Call every denied tool by its raw name through your
instance's own /mcp, with a short-lived internal key, and assert each comes back
-32003 with zero upstream calls recorded.
Two assertions, and the second is the one that matters: -32003 says the gateway
refused; zero upstream calls says the refusal happened before anything left the
box. A gate that denies after forwarding is not a gate.
3. Credential scope. Ask each vendor what your credential can actually do, wherever the vendor can answer. A "can write" answer demotes the service to Tier 2 immediately, notifies, and is audited.
4. The audit chain. Verify the hash chain over the whole log.
Reading the answer¶
0 of 47 denied tools reachable, credential scope confirmed read-only,
toolset matches verified digest, audit chain verifies
Four comma-separated clauses, always in that order, so two reports can be read side by side.
The console separates two different questions, and conflating them is how a green tick starts meaning nothing:
- The wall — did any denied tool become reachable? Did anything drift? Can a credential write? Does the chain verify?
- Fully proven — could every check actually be made?
An unreachable upstream fails the second and says nothing about the first.
What it refuses to claim¶
This is the part that makes the rest worth reading. A proof that reported "verified" when it could not check something would launder an absence of evidence into a green tick.
| It says | When |
|---|---|
toolset not yet attested — nothing to compare against |
No attestation exists for this profile yet |
toolset not checked — X did not answer |
The upstream was unreachable |
credential scope not established on X |
The vendor exposes no way to ask |
credential CAN WRITE on X |
The vendor said so. Go and look |
"Not introspectable" is a real answer. A green tick nothing checked is not.
It never blocks /mcp¶
A proof is a read, it is hourly, and a failing one changes availability only through the same gate any other signal uses. An instance that refused production reads because its own self-check was slow would be worse than one without a self-check.
Where the reports go¶
data/proofs/, as JSON, hashed so you can tell whether the file you are reading is
the file that was written. The last 200 are kept.
That hash is not a signature. Your instance has no private key an outsider would trust, and pretending otherwise would be worse than saying so. The control plane signs attestations; a local proof is evidence for you.
Running it yourself¶
prodpeek prove # exit 0 if the wall held, 1 if not
curl -X POST -H "$H" $B/api/v1/proofs # over the API
From an agent, run_proof on /mcp-admin. And prodpeek__proof on /mcp lets a
client key read the last report — so an agent can check the gate in front of it is
working before it trusts what it reads through it.
Configuring it¶
With the schedule off, the CLI and the API still run one on demand.