DEMO MODE · cryptography runs in your browser with an ephemeral keypair generated at page load · this is not the production GeoClear signing infrastructure · nothing leaves this page
Demo · AI Agent Claim Review

Was the agent inside or outside scope?

A 5-step walkthrough of how an AI-agent insurance claim is reviewed using GeoClear evidence artifacts. The cryptography is real (digital signature, computed in your browser); the keys are demo-ephemeral. Click through each step at your own pace — about 7 minutes end to end.

GeoClear preserves evidence. The insurer determines coverage.
GeoClear does not determine coverage. We preserve the evidence insurers need to review what happened.
Step 1Agent Scope Cert
Step 2Runtime Decision
Step 3Claim Review
Step 4Tamper test
Step 5Bundle download
Step 6Verify in-browser
Step 1 of 5 · at policy bind

Agent Scope Certificate

⏳ unsigned

An enterprise binds insurance coverage on its customer-support agent. The Agent Scope Certificate captures what the agent is authorized to do, against the agent operating policy version active at bind. The insurer underwrites against this machine-checkable scope.

Canonical payload

Step 2 of 5 · at action time

Runtime Decision Receipt

⏳ unsigned

A customer asks for a refund and threatens legal action. The agent does three things: promises a $7,500 refund, tells the customer the company accepts liability, and calls the refund API without the required human approval. The Runtime Decision Receipt records what the agent did, against the agent operating policy active at action time.

Tool call
refund_api(amount=7500)
Human approval
missing
Restricted commitment
liability admission detected
Agent operating policy at action time
v1.7

Canonical payload

Step 3 of 5 · after the incident

Claim Review

⏳ unsigned

The insurer's claims team opens the bundle. They have the Agent Scope Certificate (what the agent was allowed to do) and the Runtime Decision Receipt (what the agent actually did). The question: was this inside or outside authorized scope?

Approved limit
refund ≤ $500
Agent action
refund $7,500 · limit exceeded
Approval requirement
refund > $500 needs human approval
Approval status
missing

Canonical payload

Step 4 of 5 · the aha moment

Tamper test

What stops a reviewer from "fixing" the bundle to make the agent look like it acted inside scope? Try it. Edit the refund amount in the Runtime Decision Receipt below. The receipt was created at action time against the retained evidence. If you change any byte of the evidence, the receipt no longer matches.

Verifier recomputes against the in-bundle signature each time you change this value. The signature itself is unchanged — this is the same property the customer's offline verifier has at audit time, three years from now.
✅ VERIFICATION VALID · receipt matches retained evidence
Could someone edit the ZIP and re-sign it?

You can always edit a file. Cryptography does not stop editing. It stops undetected editing.

There are three cases:

Case 1 · edit the JSON, keep the original signature Verification fails because the signed value no longer matches the changed payload. Detected — this is exactly what the live tamper-test in Step 4 demonstrates, just on disk instead of in the browser editor.
Case 2 · edit the JSON, try to re-sign with the original key You cannot. The signer's private key is not included in the bundle. The bundled jwks.json contains only the public half. In the demo, the private key only exists in your browser's memory and is destroyed on page reload. In production, the private key lives in GeoClear's hardware-backed signing infrastructure and never leaves it. Blocked at the cryptography layer.
Case 3 · edit the JSON, generate your own keypair, sign with it, replace the bundled public key The bundle is now internally consistent — modified payload + your new signature + your public key. In this browser demo, that bundle would pass verification because the demo uses an ephemeral browser keypair with no external trust anchor.

Production closes this gap with an external trust anchor. A production GeoClear receipt is verified against GeoClear's public verification material — not against whatever key appears inside the ZIP. To fake a production receipt, an attacker would need to control the trusted public-key source, not just edit a downloaded bundle.
GeoClear does not prevent someone from editing a file. GeoClear makes unauthorized edits detectable, and production verification ties the receipt to a trusted public anchor outside the bundle.
Step 5 of 5 · customer-held bundle

Claim Evidence Bundle

Everything goes into one portable, customer-held ZIP. The bundle is the artifact that survives vendor changes, disputes, and time — the property a screenshot does not have.

In this browser demo, the bundle verifies against the demo public key included in the ZIP. In production, the verifier checks the receipt against GeoClear's public trust anchor, not just a key bundled with the file. That is what prevents someone from editing the bundle, generating a new key, and pretending the modified version is authentic.

Bundle contents

claim-evidence-bundle-2026-05-05.zip
📄manifest.json — bundle index + DEMO-mode label + verification recipe
📄scope-certificate.json — retained evidence + receipt
📄runtime-decision-receipt.json — retained evidence + receipt
📄claim-review.json — retained evidence + receipt
🔑jwks.json — public key (the demo-ephemeral keypair generated for this session)
📜verify.md — offline verification instructions

This demo bundle is signed with an ephemeral keypair generated in your browser at page load. A production GeoClear bundle is signed with the customer-grade signing infrastructure described in the gated security whitepaper. The cryptographic mechanic is identical; the trust anchor differs.

Step 6 of 6 · insurer-side verification

Verify the bundle right here

⏳ ready to verify

Skip the download-and-extract. Click Run verifier to watch what an insurer's claims reviewer would see in their terminal — right here, on the page. Click any artifact in the file tree to inspect it. Switch between Demo Mode and Production Mode below to see why a re-signed ZIP cannot fake GeoClear authenticity.

Demo Mode shows how verification works — checks the receipt against the verification material bundled with the ZIP. Good for teaching.
Production Mode shows why authenticity cannot be forged by editing the bundle, replacing the verification material, or re-signing with a new key — the verifier resolves the receipt's origin identifier against GeoClear's external public trust anchor, not the verification material bundled with the receipt.

verify-bundle · demo session
$ verify-bundle ./claim-evidence-bundle.zip (click "▶ Run verifier" above)
·
No verification run yet
Click "▶ Run verifier" to start
Switch between Demo Mode and Production Mode using the toggle above. Then try the red-team scenarios below.

Browse the bundle

claim-evidence-bundle.zip
📄manifest.json
📄scope-certificate.json
📄runtime-decision-receipt.json
📄claim-review.json
🔑jwks.json
📜verify.md
📄 manifest.json · clean
 

⚠ Tamper any field, then re-run the verifier

Pick any artifact, pick any field, change its value — the terminal pane re-runs verification and shows which artifact fails. The signature itself is unchanged; only the canonical bytes diverge.

No tampering applied. Bundle is clean.

🔴 Red-team scenarios · can you forge a V-certified bundle?

Three one-click attacks. Each one applies a different forgery technique, then re-runs the verifier in the current mode. The key takeaway: Demo Mode trusts the verification material bundled with the receipt, so an attacker who re-signs with their own keypair appears valid. Production Mode requires the receipt's origin identifier to resolve against GeoClear's external trust anchor, so no in-bundle forgery can pass.

No attack applied. Use Reset above to clear any tamper or attack.
Anyone can edit a file. Only a receipt verified against GeoClear's public trust anchor remains V-certified.
GeoClear preserves evidence. The insurer determines coverage.