Key findings
- A payment flow does not determine what an agent is authorized to purchase.
- Constrain counterparties, amounts, frequency and purpose, with a clear stop mechanism.
- Verify settlement, service delivery and business value separately.
What does an agent actually have authority to do?
Processing a payment request is different from deciding to buy on an organization’s behalf. Repeated purchase of fixed-price data can fit narrow rules. Selecting new suppliers or changing budgets requires broader authority. Connecting a wallet does not settle that governance question.
The x402 specification describes payment requirements, payment submission, verification and settlement associated with HTTP requests. Connecting a web request to payment does not guarantee the quality of the response or the organization’s purchasing approval. [1]
| Boundary | Example policy | Watch for |
|---|---|---|
| Counterparty | Approved suppliers and addresses | New payees or changed addresses |
| Amount | Per-request and daily budget | Split payments bypassing limits |
| Frequency | Retry and repeated-request caps | Loops and duplicates |
| Purpose | Permitted data and tasks | Mismatch between request and result |
CBK design examples, not claims that a protocol provides these controls by default.
A cheap request can become an expensive loop
At a hypothetical $0.01 per request, 100 daily requests cost $1. An error causing 100,000 retries costs $1,000. A low per-request ceiling does not control cumulative exposure. Budget, repetition and duplicate payments need separate limits.
Request identifiers and result states help distinguish a legitimate retry from a loop. If payment succeeded but the response was lost, decide whether to retrieve the existing result rather than pay again. Network success and business completion are different states.
Separate judgment from spending permission
A language model can evaluate whether data is useful while a narrower system enforces expenditure rules. New suppliers and material changes can require approval while verified repeat purchases run automatically. Flexible reasoning does not require unrestricted funds.
NIST’s AI Risk Management Framework connects governance, context, measurement and management. Applied to payments, this means defining who sets policy, which conditions count as risk, what is logged and when execution stops. This is CBK’s application, not a NIST endorsement of a payment product. [2]
Verify the purchased result separately
A valid payment is not evidence of useful data. Check format, freshness, duplication and agreement with the request. At high request volumes, automated checks and sampled review can be combined.
Delegation follows the same principle. EIP-7702 enables delegation, but the authority and safety of delegated code remain separate questions. Better usability increases the need to explain scope and revocation clearly. [3]
| Area | Required record |
|---|---|
| Cost | Linked requests, approvals, settlements and cancellations |
| Quality | Paid results and validation outcomes |
| Authority | Policy changes and approval history |
| Recovery | Stop, key-rotation and unsettled-request rehearsals |
CBK analysis. This is an analytical framework, not observed customer performance or a market benchmark.
Design the uncertain state between payment and response
When approval succeeds but the connection drops, an agent may not know whether the result exists. Repeating the purchase can duplicate payment; stopping indefinitely can abandon an already purchased result. A status-query path must connect settlement with delivery.
Use states such as unknown, authorized, settled, delivered and validated, with permitted next actions for each. Names can vary, but money already spent must not be confused with a result not yet confirmed. Clear boundaries make safe retries possible.
| State | Next check | Risk of unconditional retry |
|---|---|---|
| Payment uncertain | Existing request status | Duplicate authorization |
| Settled, no response | Retrieve existing result | Duplicate payment |
| Response received, quality unknown | Validate or raise dispute | Accumulated unusable results |
CBK analysis. This is an analytical framework, not observed customer performance or a market benchmark.
Start with a narrow form of autonomy
Full purchasing autonomy is not required to obtain value. Known suppliers and fixed-price repeat tasks make time savings and exception costs easier to measure. Broaden permission only after those observations support it.
Excessive approval can also erase automation’s benefits. Adjust limits using evidence on cost, quality and recovery instead of minimizing every limit mechanically. The objective is repeatable value within controllable authority.
Scope & limitations
Design analysis connecting protocol documentation with risk-management concepts. It estimates neither x402 adoption nor revenue and executed no agent payments. Numerical examples illustrate repeated-request costs.
CryptoBridge Korea analysis based on public materials. Source facts are distinguished from interpretation and hypothetical calculations. References to organizations or projects do not imply their sponsorship or review of this paper.
Sources & scope
- x402 Foundation, protocol specification repository ↗HTTP payment flow, distinct from purchase authority, quality or refund guarantees.
- NIST, AI Risk Management Framework Core ↗Govern, Map, Measure and Manage are applied here to payment-authority design.
- EIP-7702, Set Code for EOAs ↗Protocol delegation specification, not a security assessment of a wallet product.