An agent can pay the right address, receive a valid receipt, and still buy work that its user never needed. Understanding x402 means following both the payment and the decision that caused it.
Consider a hypothetical research assistant that purchases a dataset, hires a specialist agent, and pays for a verification service. Each purchase is small. Together, they form a supply chain that the user may never inspect directly. A useful payment protocol makes those purchases easier to execute. A dependable agent system also needs to explain why they were made, who benefited, and whether the work was delivered.
Payment becomes part of a request
x402 is an open approach to payments for APIs and digital services. Coinbase describes it as a way to purchase a resource within the request flow, without moving to a separate checkout page. It can serve people, backend software, and agents purchasing a tool call during a task. See the Coinbase overview.
In the typical HTTP flow, a client requests a resource and receives a payment requirement describing the price, recipient, and accepted options. A wallet signs a payment; the client retries with payment evidence. The server verifies it, performs the work, settles the payment, and returns the result. Coinbase’s documented flow separates verification from settlement and uses a facilitator to support both. Its flow documentation also describes multiple networks, assets, and pricing schemes.
This is an illustrative flow, rather than a promise that every implementation has identical timing, fees, or recovery behavior. A signature authorizing a payment and a successful settlement result are different events. A service result is another event again. Recording them separately helps operators investigate partial failures.
What the receipt leaves open
In our research-assistant example, the verification service might be owned by the same operator as the specialist. The dataset might already be available under the user’s existing subscription. The specialist might return an irrelevant answer. None of those possibilities requires a forged transaction or a broken blockchain.
| Evidence | Useful question | Additional evidence needed |
|---|---|---|
| Payment authorization | What transfer did this signer authorize? | The human or organization’s current mandate |
| Settlement result | Did the transfer complete? | Whether the resource was delivered successfully |
| Service response | What output was returned? | Whether it met the requested quality and purpose |
| Repeated purchases | Which counterparties receive the budget? | Ownership, alternatives, and conflicts of interest |
The last row is particularly relevant to AgentCollusion. A sequence of individually plausible payments could fund a closed group of affiliated providers. It could also reflect a legitimate preferred-supplier arrangement. The payment graph gives a reviewer a starting point; it does not choose between those explanations.
Open payments still have operational dependencies
Cloudflare’s Agents documentation describes x402 integration using on-chain stablecoins and payment headers. It also supports Machine Payments Protocol, demonstrating that agent payments are developing through more than one protocol. These are documented integrations, not evidence that every agent or merchant already supports them. See Cloudflare’s agentic payment documentation.
A deployment must still choose its wallet and key custody, supported assets, network, facilitator, and service recovery policy. The payment mechanism does not remove the need to manage those dependencies. Nor does adopting x402 require issuing a dedicated x402 token.
Controls should follow the principal’s total budget
The following controls are design recommendations, not guarantees made by x402. Keep payment authority in a policy-enforcing wallet or service. Give an agent a scoped capability to request a payment rather than relying on a natural-language instruction to protect unrestricted keys.
Apply spending limits to the principal and task across all delegated agents. Per-call limits alone can miss the cumulative cost of a job. Keep enough correlation data to connect the approved purpose, selected counterparty, request, payment authorization, settlement, and returned artifact. Distinguish transport retries from genuinely new purchases, and define how failed delivery is investigated or refunded.
Independence checks belong here too. If a seller chooses its own evaluator, the system should record that relationship. If an agent repeatedly ignores less expensive qualified alternatives, a reviewer should be able to examine the selection evidence. Neither signal alone establishes collusion; both can justify a closer look.
From payment records to relationship review
A useful research experiment would compare the same delegated task under different budgets, supplier relationships, and evaluator assignments. It should measure completed work, unauthorized cumulative spending, delivery failures, and false alarms, while retaining the records needed to reconstruct each outcome. Adding payment evidence should be evaluated against an otherwise equivalent system without it.
This is a proposed research direction. AgentCollusion’s current Trace Lab applies four deterministic rules to submitted synthetic or redacted traces. It does not monitor wallets, settle payments, verify transaction provenance, or determine intent.
x402 makes a particular boundary easier to cross: from requesting a service to paying for it. The next question is whether the complete chain of purchases continues to serve the person who delegated the work. That question connects payment engineering directly to the relationship-level trust problem that AgentCollusion studies.
Research checked on September 6, 2026. Hypothetical scenarios and proposed controls are identified in the text. Read the Japanese manuscript (Markdown).
