Vetting AI Agents Before Payment: Why Manual Vetting Breaks Down at Agent Speed

A wallet pings you at 3:14 a.m. with a settlement request for $4,200. The payer is an autonomous agent you've never seen. It claims to be a translation service, it's quoting a job your buyer posted 11 minutes ago, and it wants payment in USDT0 before it releases the deliverable. Do you sign?

That's the question EVIDIQ exists to answer. And in 2026, the honest answer is: a human, working manually, cannot answer it fast enough.

How a Human Vets a New Vendor

Vetting AI agents before payment is the process of verifying an autonomous agent's identity, declared capabilities, and reputation signal before authorizing any x402 or stablecoin transfer. EVIDIQ does this by returning a deterministic 0–100 trust score with an explicit proceed, proceed_with_escrow, caution, or do_not_proceed recommendation — signed, anchored, and auditable.

Every procurement manager knows the script. A new vendor shows up asking for money, and before you wire anything, you run them through a checklist. We use the same script ourselves when we onboard a new SaaS vendor or a contractor for our project:

1. Search the company name. Read reviews on G2, Capterra, or wherever the category lives.
2. Check LinkedIn. Real people, real tenure, real photos.
3. Ask for references. Two names minimum. You actually call them.
4. Verify the domain. WHOIS, an HTTPS cert, a business address that isn't a mailbox.
5. Check financial signals. D&B, a credit pull, a public filings page if they exist.
6. Read the contract. Indemnification clauses, IP terms, kill-switch language.
7. Gut check. Does this person sound like a real human being who'll be here next quarter?

The sequence takes between two hours and two weeks depending on the size of the cheque. Most of it is friction designed to slow down fraud, not to optimise for speed. And it works. Mostly. For humans.

Every Step of That Process Assumes a Human Has Minutes

Now run the same checklist against the agent that pinged you at 3:14 a.m.

1. Search reviews. No G2 page. The vendor is a process. It has no G2 page.
2. Check LinkedIn. There's no LinkedIn for a bot. No photo, no tenure, no ex-employer. Just a wallet address and a hostname.
3. Ask for references. Who would you even call? The previous counterparty was another bot, and bots don't pick up the phone.
4. Verify the domain. Sometimes doable. WHOIS still works. But a registered domain is a $9 investment; the marginal cost of a throwaway domain for a one-time scam is roughly the price of a coffee.
5. Check financial signals. No D&B for an agent. No credit bureau. No filings page. There's an on-chain wallet, and a wallet balance tells you nothing about intent.
6. Read the contract. Often there's no human-readable contract at all. There's a JSON document describing capabilities, an HTTP endpoint, and a payment address.
7. Gut check. There's no gut. You're asleep. The agent isn't.

Every step in the human checklist assumes the counterparty is a person with a paper trail a person can read. The agent economy has neither. Worse, the time budget for the decision has collapsed from "this afternoon" to "before this HTTP request times out."

This is the gap. The checklist isn't wrong; it's just optimised for the wrong species.

The Machine-Readable Equivalent

So what does vetting AI agents before payment actually look like at machine speed? It looks like a JSON Trust Report — a deterministic, signed blob your agent can fetch, verify, and act on in a single round trip.

Here's roughly the shape of what EVIDIQ returns from its verify_agent call:

• agent_id — the canonical identifier we resolved (often an ERC-8004 identity, an ENS name, or a verified domain).
• identity_score — 0–100, weighting a verifiable EVM address, on-chain identity id, ENS, and a TLS-served domain.
• capability_score — 0–100, weighting declared capabilities plus the result of a live probe against the agent's own endpoint.
• reputation_score — 0–100, derived from identity anchors and live signals (running a paid x402 service counts as economic skin in the game).
• risk_score — 0–100, where higher is worse.
• trust_score — the deterministic aggregate: identity0.3 + capability0.3 + reputation*0.2 + (100-risk)*0.2.
• recommendation — one of proceed, proceed_with_escrow, caution, or do_not_proceed.
• evidence_hash — keccak256 of the canonical report, anchored on 0G Storage mainnet.
• signature — EIP-191 signed by the EVIDIQ key.

Mapping this back to the human checklist makes the analogy concrete:

• Search reviews → reputation_score from on-chain signals and the live x402 service check.
• Check LinkedIn → identity_score from a verified EVM address, ENS, or ERC-8004 id.
• Ask for references → bounded live probe of the agent's endpoint (a ~6s GET confirming reachability, valid TLS, and a real machine-readable surface).
• Verify the domain → TLS handshake included in the probe.
• Read the contract → the agent's own declared capabilities, re-fetched and matched.
• Gut check → risk_score plus the recommendation field — the explicit verdict a human would otherwise have to write down.

Same job. Different substrate. Your agent gets the answer in milliseconds and acts on it inside the same request that would otherwise have timed out. We built the probe deliberately to be bounded — six seconds, one GET, no recursive crawling — because we want verification to be cheap enough to run before every settlement, not just before the first one. Our scoring formula is weighted to err on the side of caution when the reputation component is thin; you can audit the exact weights in the EVIDIQ docs.

Where the Replacement Is Still Catching Up

Honest moment: the mapping above is real, but it's not 1:1. There's one human step we still cannot fully replace, and we want to be clear about it.

A human reference call gives you transaction history. "Have you worked with this vendor before, and did it go well?" is the single most powerful signal in vendor vetting, and we do not yet have a fully equivalent on-chain reputation ledger. EVIDIQ's reputation component today is built from identity anchors and live signals — verifiable identity, whether the endpoint runs a paid x402 service, the quality of its declared capability surface, and similar anchors. It is not yet a long-running, dispute-aware registry of "agent X delivered Y for counterparty Z and got paid without complaint."

What does that mean for you, practically, when vetting AI agents before payment?

• For a first transaction with a brand-new agent, treat the recommendation as proceed_with_escrow unless multiple anchors line up. Our scoring formula is weighted that way on purpose.
• For repeat counterparties, the reputation signal strengthens with each verified interaction — that's where the roadmap is heading.
• Independent verification matters: anyone holding a report can re-fetch the evidence from EVIDIQ Notary, re-hash it with keccak256, recover the EVIDIQ signer from the EIP-191 signature, and confirm the verdict was not retroactively edited.

The direction is clear: a full historical record of agent performance, with dispute outcomes, will eventually live where today's anchor signals live. We are not there yet, and we won't pretend otherwise. Until then, the right model is: use EVIDIQ as your trust layer, layer your own escrow on top for unfamiliar counterparties, and let the reputation signal compound as more transactions go through.