Written by: Vaidik Mandloi
Compiled by: Chopper, Foresight News
Today, AI-generated fake receipts already account for 71% of all flagged expense fraud cases, a figure that was zero a year ago. Currently, most of these fraudulent activities are still carried out by humans.
Now, we have AI agents capable of discovering services and making payments via x402, all without any human review. This presents a significant challenge: how to verify what these agents actually purchase. OpenAI recently released a practical guide, offering a solution for implementing receipt verification and third-party reconciliation in payment processes.
This is currently the closest to a usable fraud-checking solution for agent payments that we have seen. This article breaks down the complete operational logic of this verification mechanism: Can on-chain settlement records prove that an agent bought the correct product from a legitimate supplier at the right price, or do they merely prove that funds were transferred?
Fraud Verification Mechanism
AI agents are already autonomously executing procurement activities. An agent responsible for procurement might pay for access to a permissions API to obtain data, invoke the computing power of other large models to process data it cannot handle itself, or purchase market intelligence behind paywalls. As such transactions increase, a critical question emerges: How do we verify what the agent actually bought?
All companies handling expense reimbursements today have a receipt verification process. After an employee completes a purchase and submits a receipt, the accounts payable department cross-references the receipt, purchase order, and bank statement before authorizing payment.
This process has been in use for decades and works effectively because the three verification records come from independent entities. The buyer issues the purchase order, another party confirms receipt, and the supplier provides the invoice. To commit fraud, one would need to collude with all three parties to forge the records, and the high cost of such collusion largely deters fraud.
Now, agent payments are building a similar verification process. When an agent wants to make a purchase from a paid API, it cannot directly complete the transaction. The request first goes to the application layer, which checks it against pre-configured spending rules, including an approved merchant list, budget limits, and permitted expense categories. If the request violates the policy rules, the purchase is blocked outright.
After the on-chain payment is executed and the agent receives the corresponding service, the application layer performs a second round of verification, comparing three pieces of information:
- The purchase details reported by the agent itself
- A receipt independently generated by the application during the purchase process
- The settlement record generated by the blockchain
Forged receipts can be identified at this stage. Even if the agent falsely claims the transaction did not occur, the application layer retains an independent record that can be cross-referenced.
This is a significant advancement for agent fraud detection, as there was previously no feasible verification method. However, compared to the traditional receipt verification model, this solution has a shortcoming. In the traditional model, the three credentials come from unrelated third parties. In the agent payment system, two credentials—the agent's report and the application-generated receipt—come from the software of the system's developer itself. The only truly independent external credential is the on-chain record.
Furthermore, the on-chain record itself carries very limited information. A payment signature typically only records the payer, payee, and transfer amount, but does not include details about the actual purchased item. Resource metadata, access addresses, or content descriptions might be transmitted along with the signature message but are not covered by cryptographic verification.
In essence, this verification can only confirm that the agent's report matches the transfer record. It cannot verify what the agent actually received after spending the money. For example: An agent spends $2 to purchase a supplier risk report. The chain can confirm the USDT transfer was completed. However, the report delivered to the agent might be just a few seconds of AI-generated, useless filler text. The entire system would still pass verification because the authorization is tied to the transfer action, not the purchased item itself.
This also leads to market-wide issues. The buyer is a software program; upon receiving a result, it simply continues execution without actively judging its quality. The agent won't invoke reputation systems or compare suppliers. Unless the developer intervenes manually, the agent will keep placing orders with the same merchant regardless of delivery quality. Suppliers providing high-quality services lose customers willing to pay a premium for quality. The entire market tilts towards "the lowest-cost provider that can fulfill the request."
Any payment system can only tolerate a certain level of fraud. The cost of completely eliminating fraud would outweigh the losses caused by fraud. For example, the credit card industry has a fraud rate of about 7 basis points, a level considered acceptable. If forced to reduce fraud further, the losses from legitimate transactions being wrongly declined would exceed the gains from avoiding fraud.
Agent payments might evolve similarly in the future: allowing a certain level of service quality flaws, with the risk absorbed by the scale of massive autonomous transactions. This logic might hold for small-scale scenarios like API calls. However, when the system is used to handle procurement contracts worth thousands or more, and the agent still cannot judge if it received value for money, the risk becomes difficult to accept.
Emerging Vulnerabilities
The speed of innovation in tools for forging receipts is outpacing that of fraud detection tools. Ramp recently launched an AI-powered accounts payable system, which flagged a large number of AI-forged document cases within the first 90 days. Emburse admitted in a survey that cases of using AI to mass-produce expense vouchers have already emerged.
In the agent scenario, the risk is further amplified. After transaction settlement, there is no human to manually review the purchase. An academic paper studying 15 mainstream, operational payment infrastructures on the market found security vulnerabilities in all of them. These systems handle funds for tens of thousands of merchants, and the disclosed vulnerabilities are reproducible.
The root cause of these attack vectors is the decoupling of the payment action from the actual product delivery. In a service discovery layer attack case, researchers merely tampered with the server list returned by a service query, successfully inducing the agent to access a malicious service endpoint. From the agent's perspective, this service was indistinguishable from a normal listing, completely unaware it had been hijacked and redirected.
A number of startups are now trying to address this problem. shturl.cc/P raised $9.5 million, launching the KYA (Know Your Agent) protocol. This protocol is akin to KYC for software programs: before funds are transferred, it establishes a trust score for autonomous agents. Risky or unverified malicious agents are directly prevented from entering the payment process.
However, relying solely on identity verification cannot prevent situations where the merchant itself is legitimate but delivers subpar content. Sardine.ai, focusing on behavioral risk, completed a $70 million Series C funding. Its product uses transaction profiles from over 2 billion devices for fraud detection. They now deploy AI agents within their own risk control stack to detect various anomalous behaviors that static rule systems struggle to find.
In the underlying infrastructure space, Nekuda.ai secured $5 million in funding. The project proposes that commercial interactions between agents should not reuse old architectures designed for human transactions. There is a need to specifically build commercial SDKs for transactions between software entities, with trust models designed natively, not patched on later.
Most existing fraud detection systems today focus the scrutiny on the agent itself: Has the agent forged a receipt, overspent, or misreported a supplier? But the agent itself has no economic motive to commit fraud for profit. The party with the real incentive to commit fraud is the merchant. The merchant faces buyers—software programs—that do not evaluate service quality, compare prices, or actively switch suppliers.
