Threat-model first: make Guardian’s x402 module opt-in, auditable, and policy-gated.

Why this is the safe first paid slice

Guardian already has sensitive private-account state, delta/canonicalization concepts, auth, acknowledger, network, and storage components. An agentic payment module should not be a generic “call facilitator from server” feature; it needs a narrow boundary that preserves Guardian’s existing invariants.

This readback deliberately avoids live keys, private account material, payments, or facilitator credentials. The first implementation should be mocked, fail-closed, and feature-gated until maintainers decide what authority Guardian may hold on behalf of users.

Readiness checklist

• Module registration: config flag, capability metadata, and independently disabled default path.
• Request contract: deterministic resource id, max amount, chain id, token, expiry, nonce, user/account binding, and delta/proposal binding.
• Verifier seam: no network spend in unit tests; mocked 402 challenge, verify failure, settle failure, receipt success, and replay attempt fixtures.
• Policy controls: per-account caps, per-resource allow-list, supported-network list, approval timeout, and operator/admin audit logs.
• Failure modes: malformed payment header, stale quote, facilitator timeout, over-budget quote, unsupported network, duplicate settle, and post-signing rejection.
• Docs split: threat model, configuration, local mock flow, and a “not custody / not private-key delegation” operator warning.

Suggested PR split

• PR 1 — spec/docs: module threat model and hook lifecycle for x402, with acceptance criteria and no runtime changes.
• PR 2 — interfaces: typed Rust traits / TS client models for quote, verify, settle, and receipt records.
• PR 3 — mocked module: fail-closed x402 middleware behind a feature/config flag with fixture tests only.
• PR 4 — optional integration: maintainer-approved facilitator adapter and e2e test path using non-production credentials.

Relevant proof