Below is a customer-refund simulation with an Ed25519 keypair generated in this tab. Drive it: allow a small simulated request, push it past the $500/day cap, try a payment_execute action while declaring read_only, or activate the simulated zero-cap stop. Every simulated evaluation is hashed into a chained record signed by the throwaway browser key.
The simulation and signing above run in your browser. The inline demo code does not transmit its action metadata or private key. It loads cryptographic modules from jsDelivr and fonts from Google. If you click “Verify chain on /verify,” the signed chain and public key are placed in the AgentGuard URL for a separate browser verification; the private key is not. The record demonstrates integrity of simulated metadata under the displayed throwaway public key, not that a refund or human approval occurred.
Each simulated decision is canonicalized, SHA-256 hashed into an entryHash, signed over that hash, and linked to the previous entry by previousHash. The tamper button changes a signed field and shows the resulting hash mismatch.
When the simulation exceeds the cap or declares insufficient capability, the page signs a BLOCK record with its throwaway key. The record shows what this page evaluated; it is not an AgentGuard production receipt.
Every receipt card has a “Verify on /verify” link that re-checks the signature and chain on a separate page, and a copy button so you can verify it from your own terminal.
The recorded deterministic SDK run blocks $96.00 of projected API spend. Separately, it blocks a simulated $9,000.00 wire because the declared capability is insufficient. A zero-cap policy blocks the next call, the signed receipt chain verifies, and a tampered receipt fails verification.
The registered mark, patent-pending status, the live SDK and MCP server, three implemented DAG-trust demonstrations, and the roadmap. For the founder who wants to take it over, or the team that wants to acquire it.