The Agent Economy: Identity, Delegation, and Machine Payments

A paying agent is a transaction path, not a new legal person. A useful design does not ask whether an agent is "trusted" in the abstract. It asks whether several independent decisions agree: which software sent the request, which principal authorized it, whether the merchant accepts it, whether payment succeeded, and whether the promised good or service was delivered.

Those decisions leave different evidence. Identity does not prove authority. Authority does not prove intent. Payment does not prove delivery. A signed record does not make the model safe. Collapsing these distinctions produces a smooth demo and an unresolvable dispute.

Start with roles, not protocols

One transaction can involve six roles:

• The principal is the person or organization on whose behalf the purchase is attempted.
• The agent workload chooses and invokes actions. Its model, runtime, and service identity need not belong to the same operator.
• The merchant or resource server prices the item, applies access policy, and records fulfillment.
• An authorization server or credential issuer records what the principal has allowed.
• A payment provider verifies or executes the payment instruction.
• A settlement network moves final value between institutions or accounts.

One organization may fill several roles, but their decisions remain distinct. The merchant independently decides under local policy whether to accept the agent, the mandate, and the order. The payment provider independently decides whether to authorize or settle funds. Neither decision proves that the other occurred.

This is the same separation between authentication, authorization, credentials, and effects developed in Chapter 56. Commerce adds a price, a payment state, fulfillment, and recovery after failure.

Identity is not authority

RFC 9421 HTTP Message Signatures lets a recipient verify that selected parts of an HTTP message were signed by a holder of a particular key and were not changed in transit (Backman et al. 2024). It does not identify the human principal or grant permission to buy. The current Web Bot Auth work composes HTTP Message Signatures with agent identifiers and key discovery. As of August 2026, its protocol is an active Internet-Draft, not an RFC; the working-group charter says that end-user authentication is out of scope (Meunier and Major 2026; Internet Engineering Task Force 2026). Visa's Trusted Agent Protocol (TAP) also uses RFC 9421 signatures for agent recognition and defines optional consumer and payment-related evidence. It is a Visa specification, not a universal identity layer beneath every commerce protocol (Visa 2026).

OAuth is not merely an application identifier. It is an authorization framework: an access token represents delegated access with a scope and duration (Hardt 2012). RFC 8693 Token Exchange can represent delegation and distinguish a subject from an acting party, while RFC 9396 Rich Authorization Requests can carry structured authorization details (Jones et al. 2020; Lodderstedt et al. 2023). These standards provide important building blocks. They do not, by themselves, define a portable meaning for every shopping instruction, bind a merchant to accept it, or prove that an order was fulfilled.

The verifier therefore needs two answers, not one:

1. Authentication: which key, workload, client, or service signed this request?
2. Authorization: which principal allowed which action on which resource, for which audience and period?

A valid answer to either question still leaves acceptance to the recipient's business rules.

A mandate is a bounded instruction

A commerce mandate should be narrow enough that a verifier can decide without reconstructing a conversation. A minimal record identifies the principal, the agent workload, the intended audience, the permitted action and resource, the maximum amount and currency, its issue time and expiry, conditions on merchant or product, the required approval rule, whether redelegation is allowed, an idempotency key or nonce, and a revocation reference. It also identifies the policy or schema used to interpret those fields.

AP2 applies this idea to payment evidence. Its current specification defines open and closed Checkout Mandates plus Payment Mandates. In a human-not-present flow, the user can sign the open constraints and the agent can later bind the selected checkout details. The resulting artifacts can help a verifier compare the order, payment instruction, and earlier authorization; they do not settle payment or allocate liability on their own (Agent Payments Protocol 2026).

Signed credentials have the same boundary. The W3C Verifiable Credentials Data Model standardizes a way to express claims and attach securing mechanisms. Its verification model does not prove that a claim is true or that a verifier must accept it. The verifier still applies status checks and business rules (Sporny et al. 2025). A mandate is evidence for a decision, not the decision itself.

Protocol names hide different jobs

Agent-commerce projects overlap, but they are not interchangeable layers in one mandatory stack. The job and boundary of each mechanism are easier to compare than their launch claims:

• RFC 9421 and Web Bot Auth work: request authentication and agent recognition; not principal authority, intent, or merchant acceptance.
• OAuth, Token Exchange, and Rich Authorization Requests: protected-resource authorization and delegation; not a completed order, payment, or delivery.
• ACP and UCP: product, checkout, order, and capability coordination; not one universal payment or settlement rail.
• AP2: transaction evidence for checkout and payment authorization; not settlement, merchant acceptance, or legal liability.
• Visa TAP: agent recognition and optional commerce evidence; not universal identity or authorization across schemes.
• x402 and MPP: payment negotiation and settlement coordination over HTTP; not demand, profitability, delivery, or dispute resolution.

ACP's current specification keeps the merchant as the system of record and lets payment handlers negotiate how credentials are supplied; payment and settlement remain with the merchant's provider (Agentic Commerce Protocol 2026). UCP covers capability discovery, checkout, orders, payment-token exchange, and identity linking, and can optionally compose with AP2 (Universal Commerce Protocol 2026). These are forms of checkout coordination. AP2 supplies transaction evidence. TAP supplies agent recognition within its scheme. x402 and the Machine Payments Protocol (MPP) supply payment interactions. Implementations may compose them, but the specifications do not imply a universal dependency graph.

What changes the economics of small payments

HTTP 402 remains reserved for future use in the HTTP standard (Fielding et al. 2022). Earlier systems already showed that very small digital payments were technically possible. Millicent, published in 1995, used broker-issued scrip to reduce the cost of small transactions (Glassman et al. 1995). The harder problem was the buyer's attention. Szabo argued that the mental cost of deciding, monitoring, and resolving a small purchase can exceed its price, and he also warned that configuring a purchasing agent merely moves some of that work (Szabo 1999).

Delegation can amortize a decision; it does not make the decision free. Let

$$o_{\mathrm{agent}}(n) = \frac{c_m}{n} + c_a ,$$

where $n$ is the number of purchases governed by one mandate, $c_m$ is the mandate cost, and $c_a$ is the per-purchase agent cost for monitoring, review, and exceptions. Compare this with $c_h$, the human decision cost per purchase. Delegation reduces decision overhead only when $c_m/n+c_a<c_h$. All costs must use the same unit and the same accounting horizon, such as dollars per month or minutes per week. This is a decision model, not a claim that any symbol has a universal value.

The merchant has a different threshold. Suppose $n$ requests share one settlement or processing batch. A simple net margin per request is

$$m_n = p(1-r) - \frac{f}{n} - c ,$$

where $p$ is price, $r$ is a percentage fee, $f$ is the batch's fixed fee, and $c$ is the fulfillment cost per request. Each term must again use the same unit and the same accounting horizon. Batching lowers $f/n$; it does not lower fulfillment cost, create demand, remove losses, or eliminate refund and dispute expense. The full economic ledger in Chapter 76 must price those terms explicitly.

Follow the transaction, then follow the evidence

The useful unit of design is an end-to-end attempt, including retries and repair.

For each attempt, retain the mandate version, authenticated requester, quote, merchant decision, payment-provider response, fulfillment result, and effect receipt. Do not compress them into one success flag. Useful states include denied, payment required, authorized, settled, fulfilled, failed, unknown, refunded, and disputed. Some belong to access, some to money, and some to delivery; their timestamps and authorities differ.

Retries make that separation operationally necessary. A timeout after payment may mean "not charged," "charged but response lost," or "charged and fulfilled but receipt lost." Give each logical purchase a stable idempotency key, reject a replayed mandate or nonce, and implement exactly-once business effect on top of at-least-once message delivery. Reserve budget before an irreversible action; commit it when the defined effect occurs; release it on a known failure. Unknown outcomes go to reconciliation rather than an automatic retry. Keep payment status and fulfillment status separate so a later refund or dispute can reference the original evidence.

x402 is a payment protocol, not an economic guarantee

The current x402 specification makes a concrete use of HTTP 402 while leaving the standard HTTP status code itself unchanged. A typical version 2 exchange is:

1. The resource server returns 402 Payment Required with a Base64-encoded PaymentRequired object in PAYMENT-REQUIRED.
2. The client selects an offered method, creates the payment payload, and retries with PAYMENT-SIGNATURE.
3. The resource server verifies locally or asks a facilitator to verify.
4. After successful verification, the server performs the work and settles directly or through that facilitator.
5. The server returns the resource and a settlement result in PAYMENT-RESPONSE.

The specification separates the client, resource server, and optional facilitator, and describes itself as network, token, and currency agnostic (x402 Foundation 2026). In practice, every offered scheme still has concrete finality, liquidity, fee, compliance, privacy, and refund properties. A successful settlement does not prove that the response was useful, delivered once, or authorized under an external contract. x402 lowers integration friction for a payment request; it does not guarantee demand or positive margin. The publisher economics discussed in Chapter 79 still require a price, enforceable access policy, and a buyer willing to pay.

MPP illustrates why protocol and payment instrument must also remain separate. It uses a 402 challenge and retry flow, but can negotiate stablecoin, card, or other payment methods (Weinstein and Kaliski 2026). Neither a 402 response nor a protocol name tells an operator which asset moved, when settlement became final, or which refund and consumer-protection rules apply.

Evidence of activity is not evidence of a mature economy

Protocol publication is not production adoption. A repository, partner list, transaction count, payment value, and controlled experiment measure different things; they should not be placed on one growth curve.

Anthropic's Project Deal is useful precisely because its boundary is clear. In an internal experiment, employee agents negotiated 186 deals with just over $4,000 in total transaction value (Anthropic 2026). The study can reveal behavior inside that marketplace and compare assigned model conditions. It does not establish population demand, merchant acceptance, fraud loss, or economy-wide market share. Those require production denominators: eligible users, attempted orders, accepted orders, payment value, fulfillment, refunds, disputes, and losses over a stated period.

Model quality can still change bargaining outcomes, search costs, and access to offers. That turns an apparently technical choice into the market-power questions of Chapter 77. The inference should follow the evidence: a bounded experiment motivates measurement; it does not supply a market forecast.

Operate a transaction contract

Before giving an agent money, write the transaction contract in fields that every participant can log and test:

• Authority: principal, agent workload, audience, permitted action, amount, currency, expiry, approval rule, redelegation rule, revocation reference.
• Order: merchant, offer and quote identifiers, item constraints, taxes and delivery terms, allowed substitutions, and quote expiry.
• Control: nonce, idempotency key, cumulative budget, per-order limit, rate limit, reserve/commit/release rules, and escalation threshold.
• Evidence: authenticated request, mandate version, authorization decision, payment status, fulfillment status, effect receipt, and retention period.
• Recovery: timeout owner, reconciliation procedure, cancellation window, refund route, dispute route, and the party allowed to retry.

Test duplicate delivery, a replayed signature, revocation during checkout, a quote change after approval, partial fulfillment, settlement followed by delivery failure, a lost response after success, delayed finality, and a refund after the budget period closes. The agent should stop or escalate when the contract cannot classify an outcome. Guessing is not recovery.

The model remains an untrusted planner within this contract. Prompt injection, tool compromise, and misleading merchant content are runtime problems addressed in Chapter 57. Payment controls bound their consequences; they do not prevent them.

Further reading