Skip to content

[P0] Prove autonomous attack resistance before wallet signing #35

Description

@TFT444

Objective

Produce the end-to-end security proof that SolGuard prevents a compromised autonomous agent from creating a valid wallet signature or blockchain transaction while legitimate autonomous commerce continues.

Dependencies

Blocked by #34. This issue is the final required proof gate for the autonomous demonstration.

Required sequence

  1. Execute one legitimate autonomous x402 payment through SolGuard and confirm it on Solana devnet.
  2. Transition the same agent into a deterministic compromised state.
  3. Execute the required adversarial cases automatically.
  4. Prove that every blocked case stops before wallet signing and settlement.
  5. Execute a later legitimate request to prove safe recovery.

Required adversarial cases

  • Hard per-agent spending-limit violation
  • First-seen recipient requiring quarantine
  • Velocity-only burst producing FLAG/REQUIRE_APPROVAL, never BLOCK by itself
  • Exact amount-anomaly boundary at 8x the approved average producing BLOCK
  • Compound drain: new recipient + at least 2x average + high velocity producing BLOCK
  • Replayed request nonce
  • Transaction mutation after authorization
  • Reused single-use authorization
  • Decision API, signer, facilitator, and RPC failure injection

Security invariants

  • Every BLOCK produces no signing authorization.
  • Every quarantined request remains unsigned unless a separate explicit approval workflow is introduced later.
  • The protected wallet rejects direct, replayed, expired, and transaction-mismatched requests.
  • Blocked traffic never updates the trusted behavioural baseline.
  • No blocked request produces a Solana transaction signature or settlement reference.
  • Failure of any required security control fails closed.
  • An allowed transaction and a blocked attempt are never represented by the same evidence state.

Required machine-readable evidence

For each request, record only computed runtime values:

  • Canonical request and digest
  • Agent and mandate identifiers
  • Decision and stable reason codes
  • Policy version
  • SolGuard authorization identifier or explicit absence
  • Wallet signer invocation and signing state
  • Solana transaction signature or explicit absence
  • RPC confirmation status for submitted transactions
  • Sanitized hash-linked audit receipt
  • Before/after queried balances

Acceptance criteria

  • One command runs the normal, compromised, blocked, and recovery sequence without payment-by-payment human control.
  • The normal payment has a real confirmed devnet transaction signature.
  • Every blocked attack has no authorization, no wallet signature, and no on-chain transaction.
  • Exact 8x and exact 2x boundary regression tests match the documented rules.
  • Velocity alone never becomes a hard block.
  • Mutation, replay, and concurrent authorization-consumption tests fail before signing.
  • The runner exits non-zero if any invariant or expected evidence field is missing.
  • Three consecutive clean-process runs produce the expected decisions.
  • Ruff, formatting, strict mypy, full coverage, adversarial tests, and GitHub CI pass.
  • Evidence distinguishes real devnet, sandbox, simulated, and recorded states without overclaiming.

Presentation boundary

The CLI and automated evidence are authoritative. The existing dashboard may observe the event stream, but manual dashboard interaction is not required to prove security.

Keywords

autonomous-attack wallet-drain-prevention pre-signing-proof adversarial-testing replay compound-drain solana

Problem-first presentation contract

Act 1: demonstrate the failure

  • Feed the deterministic manipulated-x402 fixture to the isolated unsafe reference wallet.
  • Explain that the resulting transaction can be cryptographically valid while remaining financially unauthorized.
  • Show only actual simulated-ledger changes or disposable devnet evidence, with the mode and token value labelled accurately.

Act 2: demonstrate SolGuard protection

  • Reset to the same initial scenario state and replay the identical canonical attack fixture through the SolGuard-protected path.
  • Prove BLOCK through authorization absence, signer non-invocation, transaction-signature absence, and unchanged protected balance.
  • Complete a later legitimate payment to prove that protection does not disable normal autonomous commerce.

Comparison integrity

  • Use the same agent mission, payment requirements, recipient, amounts, ordering, and timing in both acts.
  • Keep the unsafe reference and protected wallet as separate components; never implement a runtime switch that disables SolGuard for the protected signer.
  • Use deterministic inputs rather than random attack timing.
  • The CLI and machine-readable receipts are authoritative. Any visual observer renders those events and does not create evidence values.
  • State explicitly that direct theft of an independently usable wallet private key is outside the proof boundary; the protected design keeps that key isolated behind SolGuard authorization.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: demoDemonstration, presentation, and launch readinessarea: securitySecurity controls and threat mitigationsarea: testingAutomated verification and adversarial testingbuild-orderControls the mandatory implementation sequencepriority: P0Required for the minimum viable secure product

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions