|
| 1 | +# Judge demonstration runbook |
| 2 | + |
| 3 | +This runbook presents the live dashboard as evidence of the running gateway, not as a |
| 4 | +mock product animation. Use the guided mode so each screen is tied to one gateway result. |
| 5 | + |
| 6 | +## Before presenting |
| 7 | + |
| 8 | +1. Start `uv run solguard-dashboard` or open the verified hosted fallback. |
| 9 | +2. Confirm `/healthz` returns `status: ok`. |
| 10 | +3. Open the dashboard at a desktop width and select **Reset demo**. |
| 11 | +4. Confirm the header says **LIVE SECURITY ENGINE** and **SIMULATED SETTLEMENT**. |
| 12 | +5. Keep `uv run solguard-demo --skip-paysh` ready as a terminal fallback. |
| 13 | + |
| 14 | +Do not describe a settlement as real, devnet, or on-chain unless its transaction signature |
| 15 | +has been independently verified for that run. |
| 16 | + |
| 17 | +## Two-minute story |
| 18 | + |
| 19 | +### 1. State the problem |
| 20 | + |
| 21 | +> An autonomous agent can hold valid wallet access and still make a dangerous payment. |
| 22 | +> SolGuard decides whether that payment should reach the signer before money can move. |
| 23 | +
|
| 24 | +Select **Start guided demo**. Point to the separation between the agent, SolGuard, the |
| 25 | +wallet boundary, and settlement. |
| 26 | + |
| 27 | +### 2. Allow ordinary commerce |
| 28 | + |
| 29 | +Run **Normal payment** and step through the request, integrity, mandate, behaviour, and |
| 30 | +authorization stages. |
| 31 | + |
| 32 | +Visible proof: |
| 33 | + |
| 34 | +- decision is `ALLOW`; |
| 35 | +- the request and policy digests come from the current event; |
| 36 | +- signing state is `SIGNED`; and |
| 37 | +- settlement is visibly labelled `SIMULATED`. |
| 38 | + |
| 39 | +Say: "The owner did not approve this payment manually. The agent operated inside a |
| 40 | +pre-approved mandate, so the gateway allowed it autonomously." |
| 41 | + |
| 42 | +### 3. Escalate uncertainty without stopping everything |
| 43 | + |
| 44 | +Run **First-seen recipient**. |
| 45 | + |
| 46 | +Visible proof: |
| 47 | + |
| 48 | +- decision is `REQUIRE_APPROVAL`; |
| 49 | +- the reason identifies recipient novelty; and |
| 50 | +- no signing authorization reaches the wallet. |
| 51 | + |
| 52 | +Say: "Autonomy is bounded, not removed. An unfamiliar but otherwise plausible payment is |
| 53 | +paused for approval instead of being silently signed." |
| 54 | + |
| 55 | +### 4. Prove integrity enforcement |
| 56 | + |
| 57 | +Run **Replay attack**. |
| 58 | + |
| 59 | +Visible proof: |
| 60 | + |
| 61 | +- the reused request is `BLOCK`; |
| 62 | +- the reason is `REQUEST_REPLAYED`; and |
| 63 | +- signing state remains `NOT_SIGNED`. |
| 64 | + |
| 65 | +Say: "A valid-looking payment cannot be reused with the same per-agent nonce." |
| 66 | + |
| 67 | +### 5. Trigger the memorable attack |
| 68 | + |
| 69 | +Run **Compound drain** and advance to the behaviour, wallet, and evidence stages. |
| 70 | + |
| 71 | +Visible proof: |
| 72 | + |
| 73 | +- the decision is `BLOCK`; |
| 74 | +- the reasons include compound drain, new recipient, and high velocity; |
| 75 | +- the wallet is `NOT_SIGNED` and has no settlement reference; |
| 76 | +- the simulated wallet balance does not fall for the blocked request; |
| 77 | +- the email and bearer token are redacted; and |
| 78 | +- the receipt chain verifies. |
| 79 | + |
| 80 | +Say: "The important output is not the red alert. It is the missing signature. The blocked |
| 81 | +request never crossed the wallet boundary." |
| 82 | + |
| 83 | +### 6. Close with the product |
| 84 | + |
| 85 | +> Payment protocols answer how an agent can pay. SolGuard answers whether that agent |
| 86 | +> should be allowed to pay. We are looking for an agent platform or wallet partner to |
| 87 | +> validate this pre-signing boundary with its own sandbox payment intents. |
| 88 | +
|
| 89 | +## If the network or hosted page fails |
| 90 | + |
| 91 | +1. Start the local dashboard and repeat the same four controls. |
| 92 | +2. If a browser is unavailable, run `uv run solguard-demo --skip-paysh` and show the |
| 93 | + emitted decisions and invariants. |
| 94 | +3. Use the recorded evidence package only as clearly labelled backup footage. |
| 95 | + |
| 96 | +Never replace a failed external integration with an unlabelled simulation. Reliability is |
| 97 | +part of the demonstration; accurate labels preserve reviewer trust. |
| 98 | + |
| 99 | +## Fast reviewer questions |
| 100 | + |
| 101 | +- **Is settlement real?** The hosted fallback uses simulated settlement. The security |
| 102 | + decisions, signing-state outcome, sanitized receipt, and dashboard metrics are computed |
| 103 | + by the running local gateway. |
| 104 | +- **Can blocked traffic poison the baseline?** No. The behaviour engine learns recipients |
| 105 | + and amounts only from approved traffic. |
| 106 | +- **What stops replay?** Freshness and per-agent nonce checks run before policy and signing. |
| 107 | +- **What happens if a control fails?** The gateway fails closed and does not issue signing |
| 108 | + authorization. |
| 109 | +- **Is this production-ready?** No. Durable replay coordination, multi-tenant isolation, |
| 110 | + authenticated administration, hardened key custody, high availability, and independent |
| 111 | + security review remain production work. |
0 commit comments