Dev.to Security 🔐 Cybersecurity 👁 0 📖 2 min read

What we learned building two fail-closed verification tools for the agent economy

ERC-8004 gives AI agents an on-chain identity, but identity is not trust. A few recent posts here made that point well, including one showing that a naive average of reputation scores can crown the wrong agent as "best."

ERC-8004 gives AI agents an on-chain identity, but identity is not trust. A few recent posts here made that point well, including one showing that a naive average of reputation scores can crown the wrong agent as "best." That matches something we ran into ourselves, from a different angle, while building two small open-source tools.

We did not set out to build a trust layer for agents. We built two narrow verification tools, for two unrelated problems, and only noticed afterward that they shared the same design rule: never say "clean" when you mean "I didn't actually check."

Tool one: checking a sanctions-list claim

Al-Muqarin compares a claim ("this company is not on an EU/UK/OFAC/US sanctions list") against signed, dated snapshots of the public lists. The one design choice we would point to: if a list is missing, stale, or below a minimum version number, the answer is never "clean." It is ONMEETBAAR, not measured. A tool that quietly treats "I could not check" the same as "I checked and it is fine" is worse than no tool at all, because it looks like a green light.

We are not claiming this is unique. OpenSanctions and a hosted tool called agentbroker both already sign results in the sanctions-screening space, and OpenSanctions covers far more data than we do. What we did not find elsewhere is a signed snapshot of the list itself, with a version floor that refuses a rolled-back list. That is a narrow claim, not a big one.

Tool two: checking a payment receipt

agent-receipt-verify checks x402/EIP-712 payment receipts: did an agent actually pay what it claims to have paid, on the rails it claims to have used. Same rule applies: a receipt that does not fully check out is reported as such, not rounded up to "looks fine."

The part that might be useful even without our code

We trust both tools today because we tested them against our own planted mistakes, over and over. We plant deliberate bugs in the code (a missing check, a flipped comparison, a dropped field) and require every single one to make a test fail. Al-Muqarin currently catches 548 out of 548 planted faults this way.

That discipline is free to copy, with or without our tools. If you are building anything that outputs "verified" or "trusted," try deleting one check at a time and see if your test suite actually notices.

Where we are honestly stuck

Neither tool solves agent trust. Al-Muqarin has zero paying users right now; we are treating that as the real test, not the code. A separate prototype of ours, a fail-closed checker for independently-verified impact claims (did an agent's donation actually do what it claimed), has a gap we have not closed: the "who verified this" field is still free text. Nothing stops someone from writing a controller description that is not obviously "us" and getting a false pass. We know this, we have a test that proves it, and we have not fixed it yet.

If any of this overlaps with what you are building on top of ERC-8004 or x402, we would genuinely like to hear where it breaks.

More from us: github.com/holistis and tokenizen.nl.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.