AI Agent Escrow Risk, Decided: EVIDIQ's Four Verdicts

Picture this: a coding agent your team has never worked with offers to compile a smart-contract audit for 2,400 USDT. It provides a wallet address, a polite description of its skills, and a link to a homepage that loads fine in your browser. Do you pay it directly? Do you demand escrow? Do you walk?

The honest answer in 2026 is that nobody — not your CFO, not your security team, not even the agent itself — can responsibly make that call from a wallet balance and a bio. The relevant question is the AI agent escrow risk baked into the specific counterparty you're about to deal with: how solid is the identity, can the agent actually do what it claims, has it ever carried economic skin in the game, and what's the surface-level risk signal? A binary thumbs-up or thumbs-down collapses all of that into noise.

We built EVIDIQ to return something more useful than a Boolean: a deterministic 0–100 trust score, an explicit verdict, and the evidence behind both — without ever holding the money ourselves.

Four Verdicts, Not a Yes/No

AI agent escrow risk is the exposure you take when an AI agent asks to be paid first. EVIDIQ scores it with a 0–100 trust score mapped to four recommendations: proceed, proceed_with_escrow, caution, or do_not_proceed. Same inputs always produce the same score; evidence is signed; nobody holds your funds.

A two-bucket answer — trusted / not trusted — fails the middle case, and the middle is where most real counterparties sit. A self-describing agent with a working endpoint but no track record is not "trusted." Neither is it safe to call it "not trusted" and walk away from a profitable deal. Treating those two cases as identical is exactly how teams lose money to fraud on one side and lose deals to overcaution on the other. We split the response into four buckets so the verdict matches the situation.

The four recommendations cover the full spectrum:

• proceed — settle normally, no additional rails
• proceed_with_escrow — settle through an escrow mechanism you control, release only on deliverable
• caution — narrow scope, smaller ticket, manual review, or refuse if risk profile is wrong
• do_not_proceed — decline the deal, or push the counterparty to remediate first

The Thresholds, Exactly

The final score comes from a fixed formula that anyone can re-run on the same inputs:

identity * 0.3
+ capability * 0.3
+ reputation * 0.2
+ (100 - risk) * 0.2

Each component is itself 0–100. Identity rewards a verifiable EVM address, an ERC-8004 on-chain identity id, an ENS name, or a TLS-served domain. Capability rewards declared capabilities plus a live probe of the agent's endpoint — a bounded ~6-second GET that confirms reachability, TLS validity, and whether the endpoint actually serves a machine-readable surface (skill file, agent card, MCP endpoint). Reputation looks at identity anchors and live signals — for instance, does this endpoint run a paid x402 service, which we treat as "economic skin in the game." Risk inverts those same signals: missing identity, unreachable endpoint, declared capabilities the probe can't confirm, and unexplained mismatches all push risk up.

The four recommendations cut on the final score:

• score ≥ 80 → proceed
• 60 ≤ score < 80 → proceed_with_escrow
• 40 ≤ score < 60 → caution
• score < 40 → do_not_proceed

Because the formula is fixed and the inputs are logged, two clients calling EVIDIQ with the same agent get the exact same number. There is no model temperature, no A/B version, no PM-driven override. We've shipped this as a deliberate feature, not a side effect — auditable beats clever every time. The full pipeline, including the probe, is documented at EVIDIQ docs.

Why proceed_with_escrow Is the One Most Deals Land On

The honest truth is that the proceed_with_escrow bucket is where most real deals in 2026 sit. Fully clean agents — verified identity, live probe passing, confirmed capabilities, paid x402 endpoint — are rare outside the agents we and a handful of other builders run ourselves. Fully fraudulent agents are rare too; the bigger population is the long middle. Agents that exist, do something, and have no reputation because they've simply never been paid before.

That middle tier is exactly where the AI agent escrow risk is real but bounded, and where the recommendation points at a concrete tool: escrow, controlled by the buyer, with release on deliverable. The pairing we expect — and the pairing our scoring steers you toward — looks like this:

• A multisig or smart-contract escrow you or a neutral third party already trust
• Funds locked at deal signature, released only against an objective deliverable hash or an explicit acceptance step
• EVIDIQ's signed trust report attached to the deal record as evidence of what was known at signing
• A defined refund path if the agent fails the deliverable check

This is the middle of the trust spectrum and the middle of the deal spectrum — and treating both middles as the same problem is what good infrastructure does. The EVIDIQ Sentinel docs walk through how the verdict feeds into your orchestration layer. The EVIDIQ Operator docs show how a downstream agent itself can call verify_agent before agreeing to a job.

EVIDIQ Doesn't Hold the Money — Here's Why That's the Point

We deliberately did not build a custody rail. EVIDIQ verifies and recommends — it never holds funds and never grants authority to act on your behalf. That boundary is a feature, not a gap.

When one product both produces trust evidence and moves money, every compromise of that product becomes a compromise of every dollar it has touched. Splitting the roles is the standard way mature financial infrastructure survives failure, and there's no reason an autonomous-agent economy should be less careful. Specifically:

1. Evidence has different threat models than custody. A signed verdict can be cached, re-derived, anchored on 0G Storage, and re-fetched by any party years later. A custody key, once compromised, drains forward in real time — turning a manageable AI agent escrow risk into a total loss.
2. Custody implies authority. The moment EVIDIQ could release escrowed funds on a verdict, we'd also become the arbiter of disputes — a job we have no business doing. We produce the evidence; counterparties pick the protection.
3. A bigger blast radius helps no one. Every additional capability a verifier stacks makes it a more attractive attack target. We'd rather be the smallest useful thing: a deterministic trust score with tamper-evident evidence.
4. Composability beats monopoly. Any escrow scheme — your own contract, a third-party service, an agent-to-agent escrow protocol — can read the same signed report. EVIDIQ is one input into your settlement layer, not the settlement layer itself.

Concretely, what we do produce is anchored and signed:

• The canonical report is hashed with keccak256
• The evidence is anchored on 0G Storage (mainnet), returning an on-chain transaction
• An AI risk analysis can run on 0G Compute with GLM-5.2 inside a TEE, recording the provider address and request id
• The final verdict is signed with the EVIDIQ key (EIP-191)
• Anyone can re-fetch the evidence, re-hash it, and recover the signer

The EVIDIQ Notary docs describe the full anchoring pipeline. The point is that the evidence stands on its own without us — exactly what a trust signal should do, working even when nobody controls the verifier.