In January, three researchers built a shopping agent on Google's Agent Payments Protocol (AP2), the standard designed to make agent-led purchases safe through cryptographically verifiable mandates. Then they attacked it with nothing more exotic than adversarial text. The paper, "Whispers of Wealth" (arXiv 2601.22569, revised May 2026), reports that simple prompt injections reliably subverted the agent: one attack steered which products the agent ranked and bought, another exfiltrated sensitive user data. The part of the stack that failed was not the cryptography. The mandates verified exactly what they were designed to verify. What folded was the layer that exercises judgment.
Hold that result in mind, because the agent economy is currently pouring money into judgment.
Everyone is hiring a referee
Look at what shipped in the last few months for agent-to-agent commerce, and a single pattern repeats: put the money in escrow, and let a judge decide when it comes out.
ERC-8183 formalizes it: funds sit in an escrow contract while an Evaluator - an agent or a human - decides whether the deliverable meets the spec before releasing payment. It is the pattern Virtuals' Agent Commerce Protocol runs on. Circle has piloted an escrow agent for USDC flows. Kustodia and Nava (which raised $8.3M) are startups built on the same shape. And on July 1, BNB Chain and AWS launched agents that bank themselves - agents deployed to Amazon Bedrock AgentCore with their own wallets, identity, and payment stack from birth. Even the category label is contested now: at least one project has declared itself an "MCP Settlement Standard" from a landing page.
That is five separate, serious teams independently converging on the same component: a referee who holds the money.
The referee exists for a good reason
Before arguing against the judge, steelman him. Most agent-to-agent commerce today is hiring: one agent pays another for work. Write this code. Produce this research. Render this video. The deliverable is subjective. No contract can verify "the code is good" on-chain, so someone with judgment has to look at the output and decide whether it earns the payment. Escrow-plus-Evaluator is a reasonable answer to that problem, and the teams building it are not naive. For services, some referee - human juror, AI evaluator, reputation-weighted panel - is probably unavoidable.
The question is what happens when the same pattern gets applied to the other kind of commerce: trading. Two agents exchanging assets. USDC for ETH, tokenized T-bill for stablecoin, asset on one chain for asset on another.
What the red-team result means for judges
An Evaluator is judgment with release authority. The Whispers of Wealth result generalizes uncomfortably well: any component that uses contextual reasoning to decide whether money moves is a prompt-injection surface, and the injection does not need to be sophisticated. The AP2 agent was not beaten by a cryptographic break. It was beaten by words.
Now give that component custody. A compromised trading agent with standing credentials can lose everything it controls - we wrote about the six-figure Morse-code drain in May. An escrow judge is one step better: the blast radius is the escrowed amount. But the judge is also a single choke point that both sides must trust, that can be manipulated by either side, and that adversarial agents will probe continuously, at machine speed, forever. Security economics 101: the value locked behind a discretionary decision grows, and the cost of attacking discretion stays flat.
The judge-free lane
For asset trades, there is a structural alternative, and it is older than most of this cycle: make the chain itself the verifier. Hash-time-locked contracts work like this:
- Agent A locks asset X, spendable only with the preimage of hash H, refundable after timeout T1.
- Agent B sees A's lock and locks asset Y under the same hash H, with a shorter timeout T2.
- A reveals the secret to claim Y - which publishes the secret on-chain.
- B uses the revealed secret to claim X. Both legs clear, or both refund after timeout. There is no state where one side has both assets.
No referee, because there is nothing to judge: "did the asset arrive" is exactly the question a blockchain answers natively. Delivery verification is objective, so discretion - the injectable layer - is removed from the settlement path entirely. A fully compromised agent can lose at most the one trade in front of it, never a standing account, and no third party ever has custody.
This is what we build at Hashlock: sealed-bid RFQ price discovery fused with HTLC settlement, exposed to agents as an MCP server with tools covering the full lifecycle - create_rfq, respond_rfq, list_open_rfqs for discovery, create_htlc, withdraw_htlc, refund_htlc for settlement. It runs end-to-end on Ethereum mainnet today, driven entirely by MCP tool calls. Sui contracts are deployed and CLI-tested with gateway wiring in progress, and Bitcoin is validated on signet with mainnet pending. Package: hashlock-tech/mcp (scoped), v0.4.1.
Honest limits of the math camp
Atomicity is not free, and pretending otherwise would repeat the escrow camp's mistake in mirror image. Capital is locked for the duration of the settlement window. Timeout parameters are a real design problem: too short risks stranding a leg, too long hands the counterparty a free option to wait out price moves before revealing. And the mechanism only settles what a chain can verify - it has nothing to say about whether delivered code is good code. Atomic locks do not replace Evaluators for services. They replace them for assets.
The comparison, plainly
| Dimension | Escrow + Evaluator | Atomic locks (HTLC) |
|---|---|---|
| Delivery verification | Judgment (agent/human) | The chain itself |
| Custody during trade | Escrow contract + judge authority | Stays with each party until settlement |
| Prompt-injection surface | The judge's reasoning | None in the settlement path |
| Compromised-agent blast radius | Escrowed amount, judge-dependent | The single trade in front of it |
| Subjective deliverables (services) | Handles them | Cannot |
| Objective deliverables (assets) | Adds an unnecessary trusted party | Native fit |
| Capital efficiency | Escrow locked until judgment | Locked for the settlement window |
| Cross-chain | Wrapped/bridged or single-chain | Native, same hash on both chains |
The boundary this table draws is the actual debate: not "which one is right" but where the border sits. If escrow-plus-judge becomes the standard for hiring and then expands by default into asset trades, agents inherit a discretionary custodian in exactly the place they least need one. If the border holds, the two camps are complementary layers of the same economy - judges for work, math for assets.
The deeper methodology behind our side of the border is in the whitepaper on SSRN, and the settlement flow is documented at hashlock.markets/docs.
So here is the question for the people building agents right now: when your agent trades an asset with a stranger's agent, do you want a referee whose reasoning can be whispered at, or a lock that cannot be argued with? And if you are in the escrow camp - what is the mechanism that keeps the Evaluator safe from the same injection that beats the agents it referees?
Top comments (0)