|
| 1 | +# Autonomous security runner |
| 2 | + |
| 3 | +`solguard-autonomous` is the reproducible, headless proof that SolGuard can control an |
| 4 | +autonomous payment loop without a person approving each transaction. It is independent of the |
| 5 | +dashboard: CLI events and gateway audit receipts are the authoritative evidence, while a UI may |
| 6 | +observe them passively. |
| 7 | + |
| 8 | +## Deterministic sequence |
| 9 | + |
| 10 | +The local command executes one fixed sequence against the real contracts, identity verifier, |
| 11 | +integrity guard, mandate engine, behavioural engine, decision API service, authorization guard, |
| 12 | +and simulated settlement boundary: |
| 13 | + |
| 14 | +1. Three 10 USDC payments to a known recipient are allowed and settled. These confirmed clean |
| 15 | + settlements establish a 10 USDC behavioural average. |
| 16 | +2. A 10 USDC payment to a first-seen but policy-allowed recipient is quarantined. It receives no |
| 17 | + authorization and never reaches settlement. |
| 18 | +3. The exact same signed request and nonce are submitted again. Replay protection blocks it |
| 19 | + before behaviour evaluation and settlement. |
| 20 | +4. A manipulated x402 requirement requests 20 USDC for a new attacker recipient at the fifth |
| 21 | + evaluated attempt inside ten seconds. The documented compound rule is therefore true: new |
| 22 | + recipient + at least 2x the clean average + high velocity. SolGuard blocks the request without |
| 23 | + authorization or settlement. |
| 24 | + |
| 25 | +There is no random compromise trigger. Scenario inputs, ordering, and observed time are fixed for |
| 26 | +each run. |
| 27 | + |
| 28 | +## Execution boundary |
| 29 | + |
| 30 | +```text |
| 31 | +simulated paid resource -> x402 parser -> canonical PaymentRequest |
| 32 | + -> Ed25519 agent signature -> authenticated decision API |
| 33 | + -> ALLOW -> request-bound authorization -> injected settlement boundary |
| 34 | + -> REQUIRE_APPROVAL -> quarantine; stop that intent |
| 35 | + -> BLOCK -> stop that intent |
| 36 | +``` |
| 37 | + |
| 38 | +The runner owns an agent identity key but has no wallet-signing method. Its only payment dependency |
| 39 | +is the injected settlement protocol. The default implementation uses the existing in-memory |
| 40 | +settlement adapter and labels every result `SIMULATED`. |
| 41 | + |
| 42 | +The decision API itself is constructed with a forbidden settlement adapter. This makes an |
| 43 | +accidental attempt to settle from the policy service an explicit failure. |
| 44 | + |
| 45 | +## Behaviour state |
| 46 | + |
| 47 | +Only a successful settlement calls `BehaviourEngine.record_allowed`. Quarantined, replayed, |
| 48 | +blocked, or failed traffic cannot enter the clean amount/recipient baseline. Attempts still count |
| 49 | +toward the velocity rule, as required for rapid-drain detection. |
| 50 | + |
| 51 | +## Output and exit status |
| 52 | + |
| 53 | +The command emits a single JSON object containing ordered runtime events and computed totals. It |
| 54 | +returns zero only when all expected decisions and signer-boundary invariants are observed. A |
| 55 | +resource, protocol, API, authorization, or settlement failure stops safely and returns non-zero. |
| 56 | + |
| 57 | +No result from this command is a real Solana transaction or a real asset balance. Real devnet |
| 58 | +confirmation remains a separate opt-in integration and must be supported by RPC-derived evidence. |
0 commit comments