Autonomous payment begins with a delegation problem: translating a person’s purpose into spending authority that remains valid across agents, services, and time.
Suppose a user asks an assistant to organize a small event within a total budget. The assistant hires separate agents to find a venue, arrange catering, and produce materials. Each agent can make a reasonable purchase while the combined workflow exceeds the budget or favors undisclosed affiliates. This is a hypothetical example of why payment authorization must follow the whole delegated task.
Authority has several dimensions
A balance answers whether funds are available. A signature can authorize a particular payment. Neither necessarily describes the full purpose of the purchase. A useful mandate also identifies the principal, permitted goods or services, counterparties, time window, cumulative budget, and conditions for further delegation.
These dimensions can come apart. A purchase may stay below a price ceiling while violating a requirement to use an independent evaluator. An agent may have held permission yesterday but lost it before settlement. A subcontractor may be allowed to request an expense without being allowed to approve it.
What AP2 adds to the conversation
The Agent Payments Protocol, AP2, describes signed mandates connecting a user’s instructions, purchase contents, and payment evidence. Its architecture distinguishes the cart from the broader intent and includes payment information intended to help existing participants recognize agent involvement. See the AP2 specification.
The same specification’s roadmap distinguishes an initial scope centered on card-style pull payments and human-present transactions from extensions such as human-not-present transactions. A described journey is not evidence that every provider supports it today. An implementation needs to verify the actual supported flow.
This is also why autonomous payment should not be equated with cryptocurrency. Signed instructions can accompany existing payment systems. Blockchain-based settlement is one option. In the HTTP service economy, x402 provides a different, complementary way to join resource requests and payment. Its receipt still needs to be connected to the relevant authority and business purpose.
Enforce the budget where money can move
The following is a design proposal for systems built on these mechanisms. Keep spending policy in a service or wallet that can enforce it independently of an agent’s generated explanation. Give the agent a limited ability to request a payment under that policy. A prompt that says “stay within budget” is useful guidance, but it does not implement an accounting invariant.
| Control | Scope | Failure it helps address |
|---|---|---|
| Aggregate budget | One principal and task, across delegates | Several acceptable purchases exceed the total |
| Counterparty policy | Provider and controlling organization | Spending shifts to an unauthorized affiliate |
| Expiry and revocation | Authority at the time of action | A stale mandate remains usable |
| Request identity | A specific business purchase | A retry becomes a duplicate charge |
| Independent acceptance | Defined delivery requirements | Payment relies only on the seller’s own claim |
Concurrent agents make budget reservations important. If several delegates see the same remaining balance before any purchase settles, each may independently conclude that it can spend. The policy layer should account for pending commitments as well as completed transfers, with explicit rules for releasing failed or expired reservations.
Recovery also belongs in the design. A timeout does not by itself establish that no payment occurred. Before retrying, the system needs a way to resolve the earlier attempt. A valid payment followed by failed delivery needs a defined investigation or refund process. These are operational requirements, not automatic properties of a particular token or protocol.
Valid approval can coexist with a conflict of interest
Return to the event-planning example. The catering agent might consistently recommend a related vendor; a reviewing agent might approve the recommendation because its own reward increases with completed orders. Every amount could fit the mandate. The open question is whether the selection and review respected the principal’s requirements.
A related vendor is not automatically an improper vendor. The relationship could be disclosed and approved, or the provider could genuinely offer the best fit. To distinguish those explanations, retain the applicable policy, alternatives considered, information shown to the reviewer, and relevant ownership relationships. A suspicious pattern should lead to an evidence-linked review rather than an automatic accusation.
The draft ERC-8183 proposal makes an adjacent issue concrete: a client funds work, a provider submits it, and an evaluator can attest completion and release escrow. That arrangement makes evaluator selection consequential. A correct contract follows its authorized evaluator; it cannot infer that the evaluator and provider are secretly aligned against the client.
Accountability across the complete transaction
A useful review record would connect the principal’s mandate to the delegated task, selected counterparty, approval, payment attempt, settlement, and delivered result. Different services can retain different pieces, but the references between them need to survive retries and handoffs. Store only the information the reviewers are authorized to access.
For AgentCollusion, a promising experiment is to vary who proposes, approves, and benefits from a payment while holding the task and budget constant. Measure unauthorized cumulative spending, false approvals, successful completion, and the cost of unnecessary intervention. Such an experiment would test controls rather than assume that more approval steps always produce better outcomes.
This article proposes that research; it does not report a new payment experiment. AgentCollusion’s current Trace Lab reviews submitted traces using four deterministic rules and has no wallet, mandate enforcement, or payment integration. The broader objective is to preserve the user’s authority through every delegation that can spend their money.
Research checked on September 6, 2026. Hypothetical scenarios and proposed controls are identified in the text. Read the Japanese manuscript (Markdown).
