# Agent payment protocols converged — and the recipe is breakable. A team adding payments to an agent does the responsible thing: they survey the field before committing. They look at x402, at AP2, at the smaller protocols circling the same problem, and they notice something reassuring. Everyone has landed in roughly the same place. The same shape recurs — the agent carries a signed authorization for the payment, presents it alongside the request, and settlement is verified at the moment of the call. Convergence, the team reasons, is what a maturing field looks like; a dozen groups arriving independently at one design is the market finding the answer. They pick the most established option and build. Then they read the security literature, and the reassurance inverts. The design everyone converged on has a named set of attacks against it — replay, context-binding failures, prompt-injection-to-payment — demonstrated in published red-teaming, and demonstrated against the recipe itself rather than one vendor's bug. The thing the team read as maturity was a single point of failure with good adoption numbers. Convergence is usually a good sign. In agent payments it is also a structural risk, and the two facts do not contradict each other. When every protocol shares a design, every protocol shares the design's weaknesses — and the 2026 security literature has found those weaknesses and attacked them. This post is about what "the recipe is breakable" means for a team that still has to ship a paying agent, because the answer is not "pick a different protocol." There is no un-converged protocol to pick. ## The field converged on one recipe The agent-payment rails shipped fast. x402 gave agents a way to pay per call. AP2 gave them mandates — signed authorizations describing what an agent is permitted to spend and on whose behalf. Identity standards grew up alongside. Different groups, different specs, and underneath them a design that is now strikingly uniform. The shared recipe has three moves. First, authorization is a signed artifact the agent carries — a mandate, a payment payload — created ahead of the call and presented with it. Second, verification happens at the point of the transaction: the counterparty checks the artifact and settles. Third, identity is a layer to the side — the question of _which_ agent is acting is answered by a different mechanism than the one that authorizes the spend, and the two are stitched together rather than fused. We walked the per-call version of this flow in detail in [the x402 economy](/blog/x402-economy/); the point here is that the flow is no longer one protocol's flow. It is the field's. None of this is foolish. The recipe is a reasonable answer to a genuinely hard problem, and convergence on it reflects real design taste. But "reasonable" and "uniform" together produce a specific consequence, and that consequence is the rest of this post. ## Convergence concentrates the attack surface In a fragmented field, an attacker pays a tax. Every target runs a different design, so an exploit has to be re-tooled per victim, and the cost of that re-tooling is a quiet tax on attacks that protects everyone a little. A converged field refunds the tax. When x402, AP2, and the next protocol all express the same recipe — signed authorization, presented with the request, identity bolted alongside — an attack on the _recipe_ is an attack on every implementation of it. The adversary studies the design once and spends the proceeds everywhere. This is monoculture risk, and it is as old as security: the more uniform the population, the better any single pathogen travels. The threat-modeling literature has started to map the agent-protocol surface with this in mind. [_Security Threat Modeling for Emerging AI-Agent Protocols_](https://arxiv.org/abs/2602.11327) (arXiv 2602.11327) analyzes a family of agent protocols and identifies twelve protocol-level risks recurring across the creation, operation, and update phases of a protocol's life. Read the structure of that result: the risks are sorted by protocol _lifecycle stage_, not by vendor. They are properties of how these protocols are shaped, which means a team inherits them by adopting the shape — not by adopting a particular implementation of it. ## What the red-teaming found The attacks are not hypothetical, and they are not subtle. [_Whispers of Wealth_](https://arxiv.org/abs/2601.22569) (arXiv 2601.22569) red-teamed Google's Agent Payments Protocol with prompt injection and got in. Its Branded Whisper Attack and Vault Whisper Attack manipulate the agent into altering product rankings and extracting user data — and the paper's blunt conclusion is that basic adversarial prompts can compromise a financial transaction flow. This is the prompt-injection-to-payment path made concrete: the component deciding to pay is a language model, the language model is injectable, and the payment rail trusts the agent's stated intent. [_Zero-Trust Runtime Verification for Agentic Payment Protocols_](https://arxiv.org/abs/2602.06345) (arXiv 2602.06345) attacks a different seam. It identifies replay and context-redirect attacks against AP2 — a signed mandate captured and reused, or a mandate valid for one context steered into authorizing another — and proposes runtime verification with dynamically generated nonces as the fix. The fix detail matters as much as the attack: it adds roughly 3.8 ms of verification latency, and holds that latency steady at throughput up to 10,000 transactions per second. A check that cheap, closing a gap that real, tells you the gap was a design omission rather than a hard open problem. The recipe simply did not bind the mandate tightly enough to a single use and a single context. [_SoK: Security of Autonomous LLM Agents in Agentic Commerce_](https://arxiv.org/abs/2604.15367) (arXiv 2604.15367) steps back and maps the whole surface: twelve cross-layer attack vectors across five threat dimensions, with the conclusion that securing agentic commerce demands coordinated controls across layers rather than a fix at any one of them. A systematization-of-knowledge paper appearing at all is the signal. The field's attack surface is now coherent enough to be mapped — which means it is coherent enough to be shared. ## Where the recipe is thin Pull the findings together and the converged design has four thin spots, and a team should be able to name all four before it picks a protocol. **Replay and context-binding.** A signed mandate is, by default, close to a bearer token. Unless something binds it to exactly one use in exactly one context, a captured mandate is a reusable one — the gap _Zero-Trust Runtime Verification_ closes with nonces. **Prompt-injection-to-payment.** The agent is an LLM and the LLM is injectable. The rail authorizes based on the agent's intent, and the agent's intent is attacker-reachable through every channel [our prompt-injection taxonomy](/blog/prompt-injection-vulnerability-class/) enumerates. _Whispers of Wealth_ is this gap, demonstrated. **Identity sits beside the payment, not inside it.** Because authorization and identity are separate, stitched-together layers, the binding between "this specific verified agent" and "this spend" is weaker than it looks — one of the cross-layer seams the SoK is built to expose. **No dispute layer.** The recipe settles; it does not arbitrate. When an agent pays an agent and the deal is wrong, there is no protocol-level recourse — the gap [escrow and dispute resolution for agent commerce](/blog/agent-commerce-escrow/) exists to fill. ## Building on a breakable recipe anyway You cannot adopt your way out of this, because there is no un-converged protocol. You engineer your way out, by building the safe-operations layer the protocols did not ship with — which is the argument [spend rails for agents](/blog/agent-spend-rails/) made before the attacks were even published, and the attacks have now made non-optional. **Put runtime verification between intent and settlement.** Adopt the nonce-and-context-binding check from _Zero-Trust Runtime Verification_, or an equivalent. A signed mandate should be spendable exactly once, in exactly the context it was issued for. **Cap the blast radius.** Per-counterparty, per-call, and per-day spend ceilings, plus a circuit breaker on total drawdown, mean a successful injection-to-payment empties a bounded envelope, not the treasury. **Bind payments to a verified identity.** Do not let "which agent is spending" stay an adjacent, loosely-coupled layer. [ERC-8004 agent identity](/blog/erc-8004-agent-identity/) is how the spend gets tied to an agent you can actually name and check. **Isolate the treasury and refuse auto-top-up.** The agent's wallet is not the operator's wallet, and a drained agent wallet must not silently refill itself — that turns a one-time loss into a faucet. **Red-team injection-to-payment, specifically.** Run _Whispers of Wealth_-style attacks against your own flow. The question is not whether your agent can be injected; it is whether an injection reaches a signed transaction. **Know which published attacks apply to you.** Map your chosen protocol against the replay, context-binding, and cross-layer findings above. "We adopted the standard" is not a security posture. "We adopted the standard and here is each known attack on its recipe and what we did about it" is. ## The checklist Before a paying agent goes live on a converged protocol: - [ ] You can name the known published attacks against your protocol's recipe — replay, context-binding, injection-to-payment — and what you did about each. - [ ] Runtime verification sits between the agent's intent and settlement; a mandate is spendable once, in one context. - [ ] Per-counterparty, per-call, and per-day spend ceilings exist, with a circuit breaker on total drawdown. - [ ] Payments are bound to a verified agent identity, not to an anonymous or loosely-coupled one. - [ ] The agent's treasury is isolated from the operator's, and there is no auto-top-up. - [ ] Injection-to-payment is an explicit case in the red-team suite, traced from a hostile input to a signed transaction. - [ ] There is a dispute and recourse path for a settled payment that should not have happened. - [ ] None of the above lives in the agent's prompt; the controls are deterministic code the agent cannot argue with. Convergence told you the field agreed on an answer. It did not tell you the answer was safe, and the security literature has now established that it is not — uniformly, across the recipe. Build on the converged protocol, because you have no choice. Just do not mistake everyone agreeing for anyone having checked. ## Reading list - [_Whispers of Wealth: Red-Teaming Google's Agent Payments Protocol via Prompt Injection_](https://arxiv.org/abs/2601.22569) (arXiv 2601.22569) — the Branded Whisper and Vault Whisper attacks; prompt-injection-to-payment, demonstrated against a real agent-payment protocol. - [_Zero-Trust Runtime Verification for Agentic Payment Protocols_](https://arxiv.org/abs/2602.06345) (arXiv 2602.06345) — replay and context-binding failures in AP2, and a nonce-based runtime check that closes them at ~3.8 ms per verification. - [_SoK: Security of Autonomous LLM Agents in Agentic Commerce_](https://arxiv.org/abs/2604.15367) (arXiv 2604.15367) — twelve cross-layer attack vectors across five threat dimensions; the map of the field's shared attack surface. - [_Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP_](https://arxiv.org/abs/2602.11327) (arXiv 2602.11327) — twelve protocol-level risks sorted by lifecycle stage, not by vendor; the structural case that these weaknesses come with the shape. A maturing field converges. A safe field converges on something that was checked first. Agent payments did the first and not yet the second — so the checking is now your job, and it starts with naming the attacks the recipe already has.