Header pricing in x402 v2 and MCP 2026-07-28 leaves spend approval for enterprises to build

Follow one request through the Tokyo demo. The agent's task is stated in business terms, enrich record 42, and it does not know the price or the provider ^[20]. It sends `GET /tools/enrich?record=42` and is refused on purpose with a 402 and a `PAYMENT-REQUIRED` header ^[14]. The header is base64 JSON. Decoded, it is an offer: scheme `exact`, a stablecoin contract as the asset, a `payTo` address, a `maxAmountRequired`, the resource URL, `maxTimeoutSeconds` of 60 and a nonce the server chooses ^[14]. The client retries with a signed payment authorization, and the server returns the result plus evidence of settlement ^[5].

Putting that offer in a header is good engineering. The amount and the payee become fields an edge component can match on before anything is signed ^[14]. HTTP reserved 402 in 1997 and never specified what it meant, and x402 finally gave the code a meaning ^[4]. Twenty-odd years is a patient wait for one line of a spec.

The trap for anyone metering at the edge sits in the MCP binding. The negotiation happens there too, "but not in the same place," Rao and Gonzalez wrote ^[16]. "The MCP binding hands your gateway a 200 for a call nobody has paid for yet," they wrote ^[15]. Metering logic that keys on status codes will pass straight over it ^[15]. A gateway in front of both bindings has to decode the payment metadata on every response, whatever the status line says.

"Seeing a price is not the same as having the authority to approve one," the authors wrote ^[3]. In an earlier post with the Agentic AI Foundation, they argue the spending decision belongs to a budget authority the agent cannot reach ^[9][11]. Their threat model explains why. The agent process and every input to it are treated as hostile. The gateway, the services and their policies are honest but fallible ^[12]. Under that model the agent cannot hold the approval. In my view that puts the check in the gateway or directly behind it, and the enterprise writes the policy.

I would copy one choice in their flow as it stands. Asking is free ^[17]. If learning the price cost money, every agent would need spending authority before it could plan. Authorization would then happen at the least informed moment in the whole flow ^[17]. With free discovery the approver sees the amount and the payee first. A budget rule can match on `maxAmountRequired` and `payTo` from the offer itself ^[14].

The threat model has hard edges. Compromised binaries, malicious operators, key extraction from hardware and chain-level attacks are out of scope ^[13]. The authors say the flow gets interesting when the request arriving at the boundary "turns out not to be the request that was approved" ^[18].