Vetting AI Agents Before Payment: What Breaks When the Counterparty Is a Bot, and What We Do Instead

Your agent just received a quote from a vendor it has never talked to before. The deal looks fair, the response time is good, and the counterparty wants payment in USDT0 on a chain neither of you touched an hour ago. You have about 200 milliseconds to decide. What do you do?

This is the moment that broke us when we first started letting autonomous agents spend real money. Every instinct we'd built up about vendor vetting — read the reviews, call the reference, trust the gut — assumes the counterparty is a company with a website, a LinkedIn page, and a human willing to spend twenty minutes on the phone. Bots don't have any of that. We had to translate the entire human ritual into something an agent could call in milliseconds, and we had to do it without lying about what we actually know.

Here's how vetting AI agents before payment ends up looking in practice, and the honest places it still isn't good enough.

How a Human Vets a New Vendor

Vetting AI agents before payment is the act of verifying an autonomous software agent's identity, declared capabilities, and reputation signal before sending it money or sensitive instructions, then reducing the result to an auditable recommendation. EVIDIQ is the trust layer that performs this verification, returning a deterministic 0–100 trust score with an explicit verdict.

Start with the part everyone recognizes. A human goes through a familiar ritual when a new vendor shows up:

1. Read the public surface. Landing page, About page, terms of service, pricing — anything that lets you sanity-check the claim.
2. Look for third-party signal. Reviews on G2, a presence on GitHub, an entry in a marketplace, an old tweet from someone who actually used the thing.
3. Cross-check the identity. WHOIS, a verifiable business address, maybe a LinkedIn that ties a name to a face.
4. Make the call. If something still feels off, you email the founder, ask for references, or just walk away.

Each step is slow on purpose. You're spending human attention on a decision you don't trust yet. The whole flow works because you have the luxury of time, a face to attach to the contract, and a stack of soft signals accumulated over a career. None of that comes for free.

Every Step of That Process Assumes a Human Has Minutes

[IMAGE_PROMPT: A modern flat illustration of a tired developer at a cluttered desk, holding a magnifying glass over an empty chair. On the desk are crumpled checklists with red X marks, a broken stopwatch, a flatlined gas gauge, and discarded paperwork. Color palette: muted blues, coral accents, off-white background. Style: clean vector with soft shadows. No text. No real brand logos. Conveys: human vetting process breaking down at agent speed.]

Here's the thing: drop that flow into an agent context and it falls apart on every single step.

• Public surface. An agent can read a landing page, sure — but it can't tell the difference between a polished pitch and a paper-thin wrapper around an LLM call. The reading step becomes a token-budget problem, not a vetting step.
• Third-party signal. Bots don't have G2 profiles. They don't have Twitter threads. A "review" for an agent is more often a script that posts a star rating against itself. The signal-to-noise ratio drops to near zero.
• Identity. There's no face. There's no LinkedIn. The closest thing you get is an EVM address, an ENS name, or an ERC-8004 identity id — and most agents can't be bothered to claim those, so the absence of identity looks identical to the absence of a legitimate vendor.
• The call. You can't call an agent and ask a follow-up. There's nobody on the other end to wait for you to make up your mind. The contract either settles in this turn or it doesn't settle at all.

Agents make decisions on the order of hundreds of milliseconds, in chains of dozens per session. They also deal in counter-parties that appear, do one job, and disappear. The human vetting ritual is a slow ritual on purpose, and that purpose evaporates the moment you ask an LLM to do it — that's why vetting AI agents before payment is a fundamentally different problem from vetting a SaaS company. So we didn't ask. We replaced it.

The Machine-Readable Equivalent

The honest move is to admit that no human checklist will fit inside a function call. Instead, EVIDIQ publishes a JSON-shaped artifact an agent can fetch, hash, and reason about in a single round trip. The EVIDIQ docs call this the Trust Report. Here's roughly what one looks like:

{
  "agent_id": "erc8004:0x9f3a…4c2",
  "endpoint": "https://vendor.example/.well-known/agent.json",
  "trust_score": 78,
  "recommendation": "proceed_with_escrow",
  "components": {
    "identity": 92,
    "capability": 80,
    "reputation": 65,
    "risk": 18
  },
  "evidence_anchors": ["0g:mainnet:0xa17…9b"],
  "signature": "0x…"
}

This is what vetting AI agents before payment actually looks like when an LLM is the one doing the deciding. Each field maps to something the human checklist was doing, just in a shape an agent can ingest:

• identity (0–100) — replaces WHOIS and the LinkedIn check. Rewards a verifiable EVM address, an ENS name, a TLS-served domain, or an ERC-8004 on-chain identity id. No verified anchor, low score, fast.
• capability (0–100) — replaces reading the About page and trying the product. Combines declared capabilities with a live probe of the agent's endpoint — a bounded ~6-second GET that checks reachability, TLS, and whether the surface serves a machine-readable skill, agent card, or MCP manifest.
• reputation (0–100) — replaces reference calls and review scans. Today we score this from identity anchors and economic skin-in-the-game signals, like whether the endpoint is actually running a paid x402 service that costs something to keep up. More on this in a minute, because this is the part we're still honest about.
• risk (0–100, lower is safer) — replaces gut. Static checks for known-bad address lists, hostile redirection, missing transport security, the equivalent of the "they're being weird on the call" feeling.
• recommendation — replaces the email you didn't send. One of four strings: proceed, proceed_with_escrow, caution, do_not_proceed. Not a number to interpret, an explicit instruction.

Same inputs always produce the same score. The formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. There's no random forest, no LLM judge hidden behind a wall. We expose the math because the moment trust scoring becomes a black box, agents can't audit each other and humans can't audit the agents.

The report itself is tamper-evident. We canonicalize the JSON, hash it with keccak256, anchor it on 0G Storage, and sign it with an EVIDIQ-controlled key under the EVIDIQ Notary docs. Anyone — your agent, an auditor, you — can re-fetch the evidence, re-hash it, and recover the signer. A wallet balance alone tells you nothing about intent. That's the gap EVIDIQ closes.

For agents that want the call wired in directly, we ship two open surfaces. The MCP server at evidiq.dev/mcp exposes verify_agent, plus the free how_to_install and get_evidiq_skill tools. The agent-facing Skill at evidiq.dev/skill.md is a couple of paragraphs of markdown any LLM can read, no SDK required.

Where the Replacement Is Still Catching Up

[IMAGE_PROMPT: A modern flat illustration of a progress dashboard split into four equal segments labeled abstractly as identity, capability, reputation, and risk. Three segments are filled with clean geometric patterns in teal and lavender; the reputation segment is shown as a partially filled bar with a subtle dashed outline indicating "in progress". A small padlock icon sits at the center, and abstract blockchain nodes orbit the dashboard edge. Color palette: teal, lavender, soft white. Style: clean vector, developer-tool aesthetic. No text. No real brand logos. Conveys: trust scoring with one component still maturing.]

Here's the part a press release would skip, and the part you deserve to hear.

The reputation component in 2026 is not yet a full transaction history. It's an anchor-and-signal model: an identity anchor (an EVM address, an ENS name, an 8004 id), plus a few live signals like "does this endpoint actually run a paid x402 service that has burned real money to stay online." That's better than nothing — it's the closest thing to "this counterparty has put real assets at risk" that exists today. But it's not the same as five years of on-time settlements pulled from a smart-contract registry.

A human reference call is a different beast. It is, in practice, "tell me about the last time you and this person did business and what went wrong." Our reputation component cannot answer that question yet. We can tell you the agent exists, it's reachable, it has paid for its own infrastructure, and it has a stable identity. We cannot yet tell you, with the confidence of a long history, that it delivered on the last hundred jobs. That audit trail is a roadmap item, not a shipped feature, and any framing that pretends otherwise is selling you something.

Other gaps worth naming plainly:

• There is no on-chain dispute resolution yet. proceed_with_escrow is a recommendation to use escrow. We do not custody funds, do not arbitrate, do not grant authority. Choosing which escrow contract, who holds the keys, and what the dispute rules are — that's still the parties' call. Our EVIDIQ Operator docs walk through how to wire proceed_with_escrow into common settlement flows, but the operator stays in charge.
• There is no regulatory certification yet. An EU AI Act conformance badge or an AML pass is future work. If your counterparty must clear one of those gates, EVIDIQ today is one input — useful, not sufficient.
• The capability probe is bounded. It confirms the endpoint serves a skill manifest and accepts a request. It does not run your specific workload. We treat probes as a reachability-and-shape check, not a substitute for you running a dry run.

If your gut says a number feels too generous, that's worth investigating before you wire funds. We're publishing the math specifically so that disagreement is actionable.