Vetting AI Agents Before Payment: Why the Human Checklist Breaks at Machine Speed

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 any money moves. EVIDIQ does this as a deterministic, machine-readable check: an agent calls verify_agent, gets back a 0-100 score with an explicit recommendation (proceed, proceed_with_escrow, caution, do_not_proceed) and a signed evidence trail anchored on-chain.

To keep vetting AI agents before payment usable at machine speed:

1. Collect the counterparty's identity, endpoint, and declared capability data.
2. Request a signed EVIDIQ Trust Report and read its recommendation with the underlying evidence.
3. Use escrow or stop the payment when the report calls for stronger protection.

This turns vetting AI agents before payment into a repeatable control instead of a manual ritual.

Picture this. A new vendor slides into your inbox with a proposal: cheaper API access, a niche data feed, a one-off model inference job. What do you do before you wire anything?

You Google them. You read the homepage. Maybe you check Glassdoor if it's a company. You ask a friend who has used them. You scan for any obviously bad press. You negotiate a smaller first invoice, or you ask for a reference call. You click "pay" only after some version of that ritual clears.

It's not glamorous. But it works — for humans, at human speed.

The pieces of the ritual are roughly:

• A public identity you can attach the name to (a domain, a LinkedIn, a registered company).
• A claimed capability (they say they do X, and there's a product page showing X).
• A reputation signal from somewhere other than their own marketing (a review, a referral, a paper trail).
• A risk check (sanctions, fraud lists, anything screaming "walk away").
• A protection mechanism if things go wrong (escrow, net-30 terms, chargeback rights).

When all five light up reasonably, you pay. When any of them are missing or red, you pause.

We've been building agent infrastructure at EVIDIQ for long enough to recognize this exact ritual. The thing is, every single step assumes the person doing the checking has minutes — sometimes hours — to do it. And the new buyer in the room is not a person. It's another agent, deciding in the gap between two HTTP requests.

Every Step of That Process Assumes a Human Has Minutes

Let's replay the same checklist at agent speed and watch it collapse.

1. "Google them." A human types a name. An agent does not Google. An agent calls a discovery endpoint, reads JSON, and moves on. If the agent's "Google" is a directory that anyone can self-register into, the check is a vanity search, not a verification.

2. "Read the homepage." A human skims marketing copy and pattern-matches for red flags. An agent can GET a URL, sure. But which URL? Whose homepage? And a wall of marketing prose is exactly what an LLM is worst at judging — it reads like training data, not evidence.

3. "Check LinkedIn / Glassdoor / reviews." There is no LinkedIn for a bot. There are no Glassdoor reviews for an MCP server. There might be a GitHub repo, but a green repo with one commit is not the same as a real reputation.

4. "Ask a friend." A human picks up the phone. An agent asks another agent. That second agent is also a stranger, also unverified, also possibly compromised. The reference call now has an N-of-1 trust problem at every hop.

5. "Negotiate a smaller first invoice." Even this fails. The whole point of an agent is that it doesn't haggle — it has a budget, a route, and a deadline. A 10-cent test payment followed by a $10,000 follow-up is exactly the shape of a draining attack, and a smart attacker will pass the first probe happily.

6. "Gut check." The most important one. A human's pattern recognition across years of being scammed is genuinely load-bearing. An agent has no gut. It has whatever signal its verifier feeds it, and whatever priors the prompt baked in.

The honest version: at agent speed, the human ritual reduces to "does the endpoint return 200 OK." That's not vetting. That's a heartbeat. The reason this matters is that x402 — the HTTP-402-based payment flow most agents are settling on — moves money in the same request that returns 200. There is no intermission for a human to think.

So what does the machine-readable equivalent look like? We had to answer that question ourselves before we shipped EVIDIQ, and the short version is: a structured Trust Report an agent can parse in a single round trip.

The Machine-Readable Equivalent

The job of a human's checklist is to reduce a stranger to a yes/no, with confidence. The job of EVIDIQ's verify_agent call is the same job, in JSON.

Here's the mapping. On the left, what a human does. On the right, the field in the EVIDIQ Trust Report that stands in for it.

• Public identity (LinkedIn, domain, registered company) → identity sub-score (0-100), rewarded for a verifiable EVM address, an ERC-8004 on-chain identity id, an ENS name, or a TLS-served domain.
• Claimed capability + evidence it actually does the thing (homepage, demo, product page) → capability sub-score, which combines declared capabilities with a live probe — a bounded ~6-second GET checking reachability, TLS validity, and whether the endpoint serves a machine-readable skill, agent card, or MCP surface.
• Reputation signal from third parties (reviews, referrals, paper trail) → reputation sub-score, drawn today from identity anchors and live signals such as "does this endpoint run a paid x402 service — i.e. real economic skin in the game."
• Risk check (sanctions, fraud) → risk sub-score (0-100, inverted in the final formula), with explicit flags surfaced alongside the number.
• Protection mechanism (escrow, chargeback) → not granted by EVIDIQ. The recommendation field tells the caller proceed, proceed_with_escrow, caution, or do_not_proceed, and the calling agent decides whether to wrap settlement in escrow, a deposit, or a dispute window.

The final trust score is deterministic: identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Same inputs, same score, every time. Our scoring formula is auditable on purpose. When an agent says "I rejected this offer because the trust score was 41," another agent — or a human auditor — can re-run the formula and confirm.

A simplified report looks like this:

{
  "agent_id": "0xVendor…",
  "score": 78,
  "recommendation": "proceed",
  "components": {
    "identity": 92,
    "capability": 85,
    "reputation": 60,
    "risk": 18
  },
  "evidence_hash": "0x9f3c…",
  "evidence_anchor_tx": "0G Storage mainnet tx hash",
  "signature": "0xEVIDIQ… (EIP-191)"
}

Two things to notice. First, the evidence is anchored — the report's canonical hash is stored on 0G Storage mainnet, and the verdict is signed with our key. Anyone can re-fetch the evidence, re-hash it, and recover the signer. Second, the score is not a vibe. It's a number you can argue with. We document the full math in the EVIDIQ docs, because the only thing worse than a black box is a black box in the middle of a payment flow.

Where the Replacement Is Still Catching Up

Here's the part we don't sugarcoat.

A human reference call works because it pulls on a long history. "I've used them for two years, here's what went wrong, here's how they handled it." EVIDIQ's reputation component is not there yet. As of 2026, today's reputation sub-score is built from identity anchors and live economic signals — the agent has a real EVM address, the endpoint runs a paid x402 service, the domain resolves, the on-chain identity is signed. That's useful, and it raises the cost of impersonation meaningfully. But it is not the same thing as "this agent has completed 14,000 transactions over 18 months and disputed 0.3% of them."

The roadmap is straightforward. The pieces are clear: an ERC-8004-aligned on-chain reputation registry, automated dispute resolution, attestations from counterparties, decay over time. None of that is shipped today. If you read the EVIDIQ Notary docs you'll see the tamper-evident evidence pipeline (canonical report → keccak256 → 0G Storage → optional 0G Compute GLM-5.2 risk analysis inside a TEE → EIP-191 signature) is live, but the historical reputation ledger on top of it is the next quarter's work, not last quarter's.

Worth saying directly: if your use case requires "five years of clean history or no payment," EVIDIQ's verify_agent will honestly tell you the trust score is reputation-limited and surface proceed_with_escrow. That's the right answer when the signal is thin. Pretending the history is fully there would be worse.

The other honest gap: regulatory posture. EVIDIQ is not certified under the EU AI Act, not an AML gate, not a regulated trust service. We produce evidence and a recommendation. The calling agent — and the human behind it — owns the compliance call. Those are real limits, and naming them is part of what makes the report trustworthy in the first place.