A denied tool call does not reach the tool.

Below is a real run, recorded. Two calls went through a policy boundary to a server that counts what actually arrives. One was permitted and arrived; one was denied and never did. You don't have to take that on trust — the evidence is signed, it's on this page, and you can try to forge it.

1 — What happened

The agent

Two calls, one policy.

ToolDecision

The witness — a separate process

Calls that actually arrived.

#ToolArrived

The witness holds no policy and shares no code with the thing making decisions. It also has no capabilities — every tool it exposes returns a stub, so nothing is destroyed even if the boundary fails. A demo of a safety control should be safe when the control is wrong.

2 — Check the evidence yourself

Both decisions are in one signed bundle: the permit and the refusal. Verification runs in your browser — nothing is sent anywhere, and you can read the code.

Read this before trusting the green. The key above came out of the bundle itself, because the proxy mints a new signing key every time it starts. Checking a bundle against its own key proves it is internally consistent and unaltered — it does not prove who issued it. Real provenance means pinning a key you obtained beforehand, and we do not yet publish a stable one. That gap is ours; it's rung 4 below.

3 — What this does and does not prove

Known limit, stated plainly: this governs the agent's path to the tool; it is not a network firewall. If a tool is reachable by another route, that route is ungoverned — and the proxy says so itself at startup when you point it at a network upstream. In the recorded run the tool was a child process of the boundary with no network path at all.

4 — Do it without us

Download the bundle and verify it with the independently published verifier.