Proceed, Escrow, or Walk Away: Reading AI Agent Escrow Risk with EVIDIQ's Trust Score

Four Verdicts, Not a Yes/No

Most "trust" APIs answer one bit: yes, transact; no, don't. That binary breaks the moment a counterparty is neither obviously safe nor obviously fraudulent — exactly where most AI agent escrow risk lives in 2026. EVIDIQ, the trust layer for the autonomous agent economy, returns four explicit recommendations — proceed, proceed_with_escrow, caution, do_not_proceed — so builders can match protection to actual risk.

A buyer fires up an MCP client and points it at a service they've never seen. The agent claims it can rewrite a smart contract, settle invoices in stablecoins, or do retrieval over a private corpus. The buyer's wallet is one signature away from being drained. What should the verdict be?

If you only get "trust" or "no trust," you've forced yourself into a binary that lies. A wallet balance tells you nothing about intent. A domain name tells you nothing about uptime. An ENS handle tells you nothing about whether the agent at the other end even answers HTTP. The honest middle is where most real AI agent escrow risk actually sits, and a binary answer punishes you for being honest.

So we built EVIDIQ around four explicit recommendations instead of one. Each verdict is tied to a numeric 0–100 trust score, but the score alone isn't the answer — the verdict is. A score of 78 with "proceed" is a different decision than a score of 78 with "caution," because the same number can mean different things depending on what the live probe saw and which component dragged the average around.

The Thresholds, Exactly

Here's where the rubber meets the road. Our scoring formula is deterministic and explainable — same inputs, same score, every time. The combined score is:

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 identity id, an ENS name, or a TLS-served domain. Capability rewards declared capabilities plus a live ~6-second probe checking reachability, TLS validity, and whether the endpoint serves a machine-readable skill, agent card, or MCP surface. Reputation today is built from identity anchors and live economic signals — most importantly, whether the endpoint runs a paid x402 service, which we treat as economic skin in the game.

Now the cutoffs that map a combined score into a verdict. We document these openly in our EVIDIQ docs so anyone can re-derive them:

1. do_not_proceed — combined score below 25, OR risk component above 85 with no identity anchor. Either condition alone is sufficient.
2. caution — combined score 25–49, or any single component below 20 even if the total looks acceptable.
3. proceed_with_escrow — combined score 50–79, with no component below 30.
4. proceed — combined score 80+, all four components individually at or above 60.

Those numbers are not aspirational. They are the function we run on every verify_agent call. A caller who reads the report sees the band, the components, and the raw inputs — nothing is hidden. If you don't like a verdict, you can poke at the inputs and see exactly which anchor we counted and which we didn't.

Two things worth pointing out, because developers ask. First, the risk component has an inverse relationship in the formula — high risk pulls the combined score down by 20%. That's deliberate: risk alone can't veto a strongly anchored agent, but a weak anchor plus high risk pushes you straight to do_not_proceed. Second, the per-component minimums are what separate "proceed" from "proceed_with_escrow." If your identity is solid but capability probed to zero because the endpoint returned 522 three times in a row, you don't get a clean proceed, even with a great reputation.

Why proceed_with_escrow Is the One Most Deals Land On

Now we get to the honest middle. Out of the four verdicts, proceed_with_escrow is the one we see most often in real traffic — and it's the verdict the rest of the industry is worst at handling. Why? Because "proceed with caution" is what humans say when they don't actually want to make a call, and most agent infrastructure quietly falls back to that.

The reality of AI agent escrow risk in 2026 is that the median counterparty is not a scammer and not a Fortune 500 service. It's a small team that shipped an MCP server last month, registered an ENS a week ago, hasn't accumulated on-chain reputation yet, and is honestly trying to do work. We don't want to refuse them. We also don't want to send your wallet to a stranger with no protection.

proceed_with_escrow is our answer. The verdict tells the caller, in plain language: this counterparty is real enough to deal with, but the protection profile is thin, so put a barrier between settlement and delivery. Here's what that pairing actually looks like in code flow:

• The verifier returns verdict: "proceed_with_escrow", combined_score: 64, escrow_recommended: true.
• The calling agent reads escrow_recommended: true and routes the transfer through a third-party escrow contract — Safe multisig, an OATH module, or whatever the chain offers — instead of paying direct.
• The agent hands over the deliverable; on confirmation, the escrow releases. On dispute, the locked funds give both sides time to negotiate without anyone running off with the bag.

We pair this verdict with structured hints: which component is weakest (often reputation, for new agents), whether a TLS probe failed and might recover, and whether the endpoint actually accepts x402. The point isn't to do the escrow for you. The point is to tell you, "we'd transact with this counterparty, but we'd want a buffer." That's exactly what an escrow mechanism is for.

A binary trust API would have either waved the deal through or blocked it. Both outcomes are wrong. The 50–79 band is where most of the agent economy actually lives, and our system is built to be useful there, not just at the extremes. If you're wiring this into your own routing logic, the EVIDIQ Operator docs walk through exactly how to consume the verdict object.

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

Now the part that surprises new callers. When the verdict says proceed_with_escrow, we don't open an escrow. We don't custody. We don't sign anything that moves funds. EVIDIQ produces evidence and a recommendation. The parties — that's you and the counterparty — choose your own protection: direct settlement, third-party escrow, milestone-based release, whatever your threat model requires.

Why is this a deliberate design choice rather than a missing feature? Because custody and evaluation are different trust models, and mixing them creates one giant single point of failure. If we held the money, we'd be the highest-value target in the entire agent economy. Every verify_agent call would be a potential payout we'd have to defend. Every dispute would be a liability we'd have to staff. Every regulator would have to talk to us. And every developer integrating us would be deciding whether they trust EVIDIQ more than they trust the counterparty they actually want to transact with — which is a worse question than the AI agent escrow risk question they came in asking.

What we do instead is make the recommendation tamper-evident. Each verified report is canonically hashed (keccak256), the evidence is anchored to 0G Storage mainnet, an AI risk analysis can run inside a TEE on 0G Compute, and the verdict is signed with our EVIDIQ key using EIP-191. Anyone can re-fetch the evidence, re-hash it, and recover the signer. The auditor's question becomes "does this signature match this evidence?" — which is answerable in milliseconds, not legal days.

This split is exactly what the EVIDIQ Sentinel docs walk through. Sentinel is the side that talks to callers, asks for payment over x402 (EIP-3009 transferWithAuthorization, settled on X Layer in USDT0), and returns the signed report. It never holds funds and never grants authority. The Notary side — covered at EVIDIQ Notary docs — is the part that anchors evidence to 0G and seals the verdict. Operator is the workflow surface, in the EVIDIQ Operator docs, where teams actually wire verdicts into their own routing logic.

We took this design seriously because we want to be the trust layer, not the bank. A bank has to be licensed, audited, and insured. A trust layer has to be open, verifiable, and cheap to call. The two jobs are different and we deliberately picked the second one. If you want escrow, pick an escrow primitive you already like. If you want dispute resolution, use a service with arbitrators. We will tell you, with evidence, which verdict fits the counterparty in front of you. That's the whole job — and doing only that job well is what makes it possible to call us tens of thousands of times a day without flinching.