Every number on this page is copied by hand from a real artifact produced by our own validation harnesses — real TCP/HTTP against a real gateway process and a real durable state store, never in-process function calls or invented figures. Reviewed 2026-09-11.
The attempted-request scale of each real adversarial or concurrency workload, log-scaled because these scenarios legitimately span 1,000 to 1,000,000 attempts.
Each row is one real run: what was attempted, what was accepted, what was rejected, and the invariant checked against database state — not only the test harness's own counters.
| Test | Category | Status | Attempted | Accepted / Rejected | Invariant |
|---|---|---|---|---|---|
| Multi-Tenant Isolation | Security Correctness | PASS | 1,000,000 | 0 / 1,000,000 | 0 cross-scope budget influence, 0 cross-scope approval consumption, 0 unexpected 5xx |
| Replay Protection | Security Correctness | PASS | 1,000,000 | 0 / 1,000,000 | 0 duplicate replay acceptances, 0 budget violations |
| Budget Race (single reservation, concurrent claims) | Concurrency | PASS | 100,000 | 1 / 99,999 | exactly 1 successful consumption, 0 double-consumes, 0 budget violations |
| Approval Consumption Race (cross-replica) | Distributed Systems | PASS | 200 | 2 / 198 | 1 successful consumption per repeat, 0 duplicate_successful_consume, final SQL state = consumed |
| Multi-Replica Identity (restart + concurrency sweep) | Distributed Systems | PASS | 500 | 500 / 0 | 0 id_collisions, 0 false_idempotent_alias at concurrency 100/500/1000; DB row count matches harness (2,100 = 2,100) |
| Trust-Boundary Closure | Security Correctness | PASS | 52 | 52 / 0 | 52 / 52 real, separate-OS-process boundary assertions pass |
| Broker Failure Recovery | Failure Recovery | IN PROGRESS | 0 | 0 / 0 | results publish on completion |
Every result above states its own topology, state backend and transport — none are shared assumptions.
1,000,000 requests from tenant B attempting to influence or read tenant A's budget/approval state, real HTTP path end to end.
1,000,000 replayed payment-proof requests against the real enforcement path.
100,000 concurrent requests racing to consume the same single budget reservation.
Two repeats of a 100-way concurrent burst racing to resume the same approval grant across 4 replicas.
10 restart cycles x 50 distinct legitimate requests, re-run at 3 concurrency levels.
Structural checks that the issuer's DB role cannot write authorization_records, the gateway config contains no signing key, least-privilege roles start and serve real traffic, and related isolation invariants.
Broker outage/recovery drill while the gateway continues serving live traffic.
Not yet complete -- shown as IN PROGRESS, not fabricated as PASS.
cargo test --workspace --all-features — 593 passed, 0 failed, 2 ignored. Verified 2026-09-11. This single constant is the only place this number is defined — every page that shows it reads from here.
A feature comparison against publicly documented capabilities of adjacent agent-payment and wallet-infrastructure products. x402Shield does not win every row — see the honestly-marked gaps below.
| Dimension | x402ShieldPayment authorization boundary | CrossmintAgent-payment platform | TurnkeyWallet + signing policy infrastructure | AWS Bedrock AgentCore PolicyGeneral agent-action authorization | SkyfireAgent-payment platform | Coinbase x402 / CDP FacilitatorPayment protocol / facilitator |
|---|---|---|---|---|---|---|
| Primary roleWhat the product is built to do first | Yes | Yes | Partial / different model | Yes | Yes | Yes |
| Built specifically for agent paymentsvs. a general product agent payments is one use case of | Yes | Yes | Partial / different model | Partial / different model | Yes | Partial / different model |
| Customer-defined spending controlsLimits, caps, allowlists the customer configures | Yes | Yes | Yes | Partial / different model | Yes | Not publicly documented |
| Deterministic authorizationSame request always yields the same decision, no model in the decision path | Yes | Partial / different model | Yes | Yes | Not publicly documented | Not publicly documented |
| Human approval supportA person can be required to approve a specific action | Yes | Yes | Yes | Partial / different model | Not publicly documented | Not publicly documented |
| x402 supportSpeaks the x402 HTTP payment protocol | Yes | Yes | Not publicly documented | Not publicly documented | Not publicly documented | Yes |
| Wallet / signing infrastructureHolds or produces the signing key itself | Not publicly documented | Yes | Yes | Not publicly documented | Yes | Not publicly documented |
| Can sit in front of customer-controlled signing infraAuthorizes without requiring custody of the key | Yes | Not publicly documented | Not publicly documented | Not publicly documented | Not publicly documented | Not publicly documented |
| Exact request ↔ payment authorization bindingThe signed payment is cryptographically bound to the exact authorized request | Yes | Not publicly documented | Not publicly documented | Partial / different model | Not publicly documented | Partial / different model |
| Separate authorization vs. payment-signing boundaryThe thing that decides is a different process/key than the thing that signs | Yes | Not publicly documented | Partial / different model | Not publicly documented | Not publicly documented | Not publicly documented |
| Delegated financial authority / attenuationA parent can grant a narrower, never-wider authority to a sub-agent | Yes | Not publicly documented | Partial / different model | Not publicly documented | Not publicly documented | Not publicly documented |
| Replay / idempotency protectionA repeated request cannot execute twice | Yes | Not publicly documented | Not publicly documented | Not publicly documented | Not publicly documented | Partial / different model |
| Authorization evidence / reconciliationA durable, checkable record of what was authorized and signed | Yes | Not publicly documented | Not publicly documented | Yes | Partial / different model | Not publicly documented |
| Payment settlementActually moves/confirms funds on a rail | Not publicly documented | Yes | Yes | Not publicly documented | Yes | Yes |
Payment-specific authorization boundary between agent intent and signing infrastructure
Agent payment platform — non-custodial wallets, cards and stablecoin payments for agents
Wallet and signing infrastructure with a policy engine enforced inside a secure enclave
General-purpose, deterministic tool-call authorization for AI agents
Agent payment network — agent wallets, identity (KYA) and per-agent spending limits
x402 payment protocol reference facilitator — payment verification and on-chain settlement