Hello,
AI-generated fake receipts now account for 71% of all flagged expense fraud. A year ago, that number was zero. And that is still mostly humans doing the fraud.
But today, we have AI agents that can discover services and make payments through x402, all without needing any human approval. And with that comes a need for ways to verify what these agents actually bought. OpenAI recently published a cookbook that enables receipt verification and three-way matching for payment flows.
It is the closest thing we have to a fraud check for agentic payments, and so I went deep into how this verification works end-to-end: does an on-chain settlement record prove the agent bought the right thing, at the right price, from the right supplier? Or does it just prove that money moved?
The Fraud Check
Agents are already making purchases on their own. An agent running a procurement task might pay for its data from a gated API, buy compute from another model to process data it cannot handle, or purchase market intelligence that sits behind a paywall. As these transactions grow, so does the question of how to verify what the agent actually bought.
Every company that handles expenses today has a way to verify the receipts. When you buy something, you submit the receipt, and the accounts payable compares it against the purchase order and the bank statement before releasing funds.
This has been the process for decades, and it works because each of those records for verification comes from different parties. The buyer creates the purchase order, Someone else receives the goods, and the supplier sends the invoice. You would have to get all three to coordinate a lie, and the cost of that coordination is what has kept most frauds away.
Now, with Agentic payments, we are building a similar process. When an agent tries to buy something from a paid API, it cannot actually make that purchase on its own. The request must first go to the application layer, which checks it against preconfigured spending rules. It includes pre-approved merchants, budget limits, and pre-authorised categories. If at any instance the request does not match the policy, the purchase does not happen.
And after the payment goes through on-chain, the agent receives what it paid for; the application then runs a second check that compares three things.
The agent’s own account of what it bought
The receipt that was generated independently by the application during the purchase.
The settlement record from the blockchain.
The settlement is also where the fabricated receipts get caught. Because if the agent claims a transaction did not happen, the application already has its own record indicating otherwise.
This is still a much better start for agents’ fraud detection, because before this we had no other way to verify at all. But the problem with this type of fraud detection, when compared with traditional receipt verification, where each of the three records comes from an independent party, is that in agentic payments, two of the three- the agent’s account and the application’s receipt both come from the deployer’s own software. The only true external record is the one on-chain.
And the on-chain record is still very narrow because the payment signature covers who paid to whom and how much, but it does not include any references to what was actually purchased. The metadata about the resource, the URL, and the content description travel with the signed payment but are not part of what is cryptographically verified.
So the verification confirms that the agent’s report is consistent with the payment record, but it still has no way to check what the agent actually received for the money. For example, an agent could pay $2 for a supplier risk report, and the chain would confirm the USDC moved. But the report itself could be just three paragraphs of filler generated in seconds, and the system would still pass it without hesitation because the authorisation is bound to the transfer, not to what is being purchased.
This also creates a market-wide problem because the buyer is software that can simply accept whatever response it receives and move on; there is no natural pressure to check and push out bad sellers, as agents do not consult reputation systems or comparison shop.
They will keep buying from the same merchant regardless of quality unless a developer intervenes. Quality sellers lose the one audience that would pay more for better work, and the market gravitates towards whoever can deliver the cheapest thing that can fulfil the request at that time.
And every payment system has to tolerate some fraud because eliminating it entirely costs more than the fraud itself. For example, Credit cards run at roughly 7 basis points of fraud, and that rate is considered acceptable because driving it lower would kill more legitimate transactions than it would save in prevented losses.
Agentic payments could work the same way, letting some quality slip through because the volume of autonomous transactions offsets it. But that logic only sounds comfortable for low-transaction cases like API calls, but is very hard to accept when the same systems are being built to handle procurement contracts in the thousands, and the agent still has no way to tell whether it got a good deal.
What’s Breaking?
The tools for creating fake receipts have already outpaced the tools for catching them. Ramp recently deployed an AI-powered accounts payable system that flagged over $1 million in fraudulent invoices within the first 90 days. 40% of US employees in a recent survey admitted to using AI to fabricate expense documents.
With agents, the exposure hits the fan because no one reviews the purchase after it settles. Researchers tested the fifteen largest payment facilitators currently in production and found security violations in each. These systems handle money for tens of thousands of sellers, and the vulnerabilities they found are published and reproducible.
As mentioned above, the attacks work because the payment is decoupled from the product. In discovery-layer attacks, researchers steered agents toward malicious endpoints 72% of the time simply by manipulating which servers appeared in service lookup results. The agent had no way to tell it was being redirected because, from its perspective, it was picking a server from a list that looked exactly like any other.
Now, there are some really cool companies trying to solve this. Skyfire raised $9.5M for what they call KYA, Know Your Agent. Their KYA protocol works like KYC for software: it establishes trust scores for autonomous agents before any money changes hands, so that a rogue or unverified agent never reaches the payment step in the first place. I have also written about this in depth in Know Your Agent.
But identity alone can’t protect against a merchant who clears every verification and still delivers garbage. That behavioural layer is where Sardine operates. They closed a $70M Series C building fraud detection that profiles transaction patterns across over two billion devices, and they now run their own AI agents inside that stack to surface the kind of anomalies that static rule-based systems consistently miss.
Further down the stack, I came across Nekuda, which raised $5M, arguing that agent-to-agent commerce needs entirely different plumbing than what we use for human transactions; we need to build purpose-built commerce SDKs where the trust model is designed around software buying from software rather than bolted on after the fact.
The fraud detection we have today is entirely focused on the agent. Did it fabricate a receipt, overspend, or misreport the supplier? But the agent has no economic incentive to cheat. The merchants do. They are selling to a buyer that cannot evaluate quality, cannot compare prices, and will never take its business elsewhere.
That’s all for today!
Token Dispatch is a daily crypto newsletter handpicked and crafted with love by human bots. If you want to reach out to 170,000+ subscriber community of the Token Dispatch, you can explore the partnership opportunities with us 🙌
📩 Fill out this form to submit your details and book a meeting with us directly.
Disclaimer: This newsletter contains analysis and opinions of the author. Content is for informational purposes only, not financial advice. Trading crypto involves substantial risk - your capital is at risk. Do your own research.