In this recorded run, the denied tool call never reached the tool.

1 · What happened

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. One caveat: the decisions in the bundle are signed; this arrival count is our own recording and is not. Nothing on this page proves the count to you; rung 2 is where you run the boundary yourself and generate your own.

Both receipts carry request_id "2": the recorded run sent its two calls with the same JSON-RPC id. That is the condition known issue 2 on /security warns about when two clients share one proxy; the run above had one client, the agent.

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.

Where that key came from. It was read off the proxy's startup banner, which prints the active public key before any bundle exists, and the proxy was run with a key file so the same key comes back on every restart. It is not taken from the bundle. That distinction is the point: checking a bundle against a key the bundle itself supplied shows only that the bundle is internally consistent, never who issued it.

What it still does not prove. This key is published here, on our page, and nowhere that does not depend on us. Pinning it shows the evidence was signed by the key we published, which is more than the page could say before and less than an identity you could check without trusting us. That last step is rung 4 below. Two limits worth knowing now. A key persists across restarts only when the proxy is given one: 3.6.0 through 3.6.2 reads AGA_GATEWAY_KEY, then AGA_GATEWAY_KEY_FILE, and mints a per-process key when neither is set, when --ephemeral is passed even if one is set, and, with a warning, when the supplied key is invalid or unreadable; its startup log says which. And the key above is published only here, so check provenance for what is actually published before you rely on it.

3 · What this does and does not prove

• This page A recorded run on our machine, signed with a key that survives restarts and is printed above. The receipts are real and the verification is real. It is a demonstration, not an audit, and it cannot show you the boundary refusing something live.
• Runtime evaluation, only in approved isolation Start with static verification, which needs no running proxy. A runtime test needs an approved isolated environment, disposable data, no production credentials and review of the known issues. Do not run it on your normal workstation. Within that separate scope, install @attested-intelligence/aga-mcp-server@3.6.5 from npm, point it at a disposable server, and watch the boundary permit and deny in your own logs (aga-proxy's default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode). The published package reads AGA_GATEWAY_KEY and then AGA_GATEWAY_KEY_FILE, so setting a valid one gives you a signing key that survives restarts, which is how the run above was recorded. It mints a key for that process, which changes when the process restarts, in three cases: neither is set, --ephemeral is passed even if one is set, or the supplied key is invalid or unreadable (with a warning). Its startup log says which. Nothing here is a special build. The run was recorded on 2026-09-18 at 23:36 UTC, after the 3.6.0 release commit and three days before the npm publish; the one commit between the recording and the published tag changed a line of THREAT_BOUNDARY.md and no code.
• Offline verification Take the bundle to a machine that has never touched ours and check it with the separately published verifier. Different package, no shared code with what signed it.
• An identity published away from the evidence A gateway key you can obtain somewhere that does not depend on this page, so a receipt proves who signed it without taking our word for the key, plus a conformance corpus anyone can run against any implementation, ours included. The stable key now exists. Publishing it independently of us does not.

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 check it with the separately published verifier. The command below pins the key from section 2, so it checks the expected signing key as well as the signed contents. Identifying a person or organization still requires a separately trusted key mapping. Drop the --pubkey argument and you get an integrity-only result, labelled as such.

The gateway key, held in a key file and read off the proxy's startup banner: