Proceed, Escrow, or Walk Away: How EVIDIQ Reads AI Agent Escrow Risk

You wired up an agent to buy compute, scrape a job board, or call a paid translation API. The counterparty looks fine — wallet funded, a clean landing page, even a fancy NFT profile pic. Ten minutes later, 4,000 USDT0 is gone and the other side's RPC endpoint returns 404 forever. That is AI agent escrow risk in 2026, and a binary trust / don't-trust answer is exactly the wrong shape for it.

Four Verdicts, Not a Yes/No

AI agent escrow risk is the gap between a wallet holding funds and a counterparty actually being who they claim to be. EVIDIQ closes that gap by returning a deterministic 0-100 trust score and one of four recommendations: proceed, proceed_with_escrow, caution, or do_not_proceed. The score is auditable, not a black box.

The honest answer to "should I send this agent money?" is almost never a clean yes. Most of the time it is a qualified yes — proceed, but only because you can claw it back. We learned this the hard way watching teams wire funds based on vibes: a pretty agent card, an ENS name, a Twitter thread. Vibes don't survive contact with a malicious counterparty.

So EVIDIQ returns one of four labels, and every label has a defined meaning:

• proceed — settle directly, low expected loss.
• proceed_with_escrow — settle, but only via an escrow leg with dispute rights.
• caution — small ticket size or step-up auth, treat as adversarial.
• do_not_proceed — walk away, do not authorize the transfer.

That fourth one is the part most "trust score" competitors skip. They give you a number and leave the threshold to your gut. We're explicit about it because the only thing worse than a wrong number is a right number with no operational meaning. You can read the full design notes in the EVIDIQ docs and try the labels live on the EVIDIQ playground.

The Thresholds, Exactly

The score is a weighted sum: identity * 0.3 + capability * 0.3 + reputation * 0.2 + (100 - risk) * 0.2. Each sub-score is 0-100. Same inputs always produce the same output — that is the deterministic part, and it means anyone can re-run the formula against the same evidence and recover the same number.

Here is the mapping from final score to label, and the reasoning behind each cut:

1. score >= 75 → proceed. Identity is verifiable, declared capabilities match a live probe, and risk signals are quiet. Direct settlement is fine.
2. score 50–74 → proceed_with_escrow. The agent is real, the endpoint answers, but reputation is thin or risk is non-zero. The math says settle — with a clawback path.
3. score 30–49 → caution. A real counterparty but mismatched declared capabilities, a flaky endpoint, or no economic skin in the game. Only small tickets, with step-up auth.
4. score < 30 → do_not_proceed. Identity unverified, capability probe failed, or active risk flag. No ticket size justifies it.

[IMAGE_PROMPT: A modern flat illustration of a horizontal score gauge from 0 to 100, divided into four color-coded bands labeled proceed (green), proceed_with_escrow (yellow), caution (orange), do_not_proceed (red). A small robot icon slides along the gauge. Developer-tool aesthetic, muted palette with one accent color, soft shadow, no text in image other than tiny band labels. Background is a soft gradient.]

Worth noting: the score is not a "fraud probability." It is a recommendation-grade index. A score of 60 does not mean "60% likely to be safe." It means "based on the evidence, the recommended posture is proceed_with_escrow." We made it that way on purpose, because probability numbers get weaponized in arguments — "the score was 60, that's basically passing." Recommendations don't.

The risk sub-score is the part teams underweight. It includes things like: does the agent's endpoint actually run a paid x402 service? No paid endpoint means no economic stake and a lower reputation contribution. It also flags known-bad TLS issuers, unreachable hosts, and a capability probe that came back with a 200 OK but a body that isn't a real skill/agent-card/MCP surface. For the exact signals we run, the EVIDIQ Sentinel docs walk through the probe step by step.

A wallet balance alone tells you nothing about intent — that is the gap EVIDIQ closes, and the gap that standard AI agent escrow risk heuristics miss.

Why proceed_with_escrow Is the One Most Deals Land On

In practice, if you ran EVIDIQ against the next 50 agents your system is about to pay, more than half would land in the 50-74 band. Not because the agent economy is sketchy — because new counterparties are inherently information-thin. A wallet that just received its first 100 USDC and an agent card that was deployed last Tuesday will pass identity and capability, but reputation has nothing to chew on yet. That isn't fraud. That is just the cold-start problem.

So proceed_with_escrow isn't a euphemism for "don't really trust this." It is the honest middle: the math says proceed, the math also says protect the downside. Pairing the recommendation with a real escrow mechanism is what makes the label useful rather than performative. In practice that means one of three patterns:

• Time-locked refund: funds settle to the seller, but a smart escrow releases only after the buyer's verifier checks the deliverable — or the time-lock expires and refunds.
• Hashed milestone escrow: both sides sign EIP-3009 transferWithAuthorization commitments for each milestone; release happens on milestone signatures, refund on missed deadlines.
• Third-party escrow agent: an independent escrow service holds the funds and arbitrates on a deterministic policy. EVIDIQ is not this service — the score just helps the human or smart-contract escrow decide policy weight.

The score tells the escrow what to weight. The escrow holds the money. The two responsibilities stay separate. That is the whole point of the four-tier design: it forces a real architectural decision instead of hiding "probably fine" behind a single number.

The EVIDIQ Operator docs cover how to wire the verdict into your settlement layer so the escrow leg triggers automatically on proceed_with_escrow and the request blocks outright on do_not_proceed. We've seen teams save themselves with this in production — one builder told us the verdict label caught a counterparty swap mid-session that their own fraud heuristics had waved through.

This is also the most common AI agent escrow risk posture in 2026, and ignoring the band because it feels "in the middle" is how teams lose funds.

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

Read the previous section again and you will notice something: EVIDIQ never appears in the custody path. We don't hold your funds, we don't sign escrow releases, we don't have a key that can move money. The verdict is a recommendation backed by evidence, not an authority backed by a balance sheet.

That boundary is deliberate, and we get pushback on it. "Why won't you just be the escrow?" is the most-asked question we fielded this year. The short version: custody and verification are different trust models, and combining them creates a single point of failure that we are not qualified to operate.

• A custody provider has to be a security company. Pen tests, key management, regulatory posture, insurance. That is a different company.
• A verification provider has to be reproducible. The score has to be auditable by any third party, with the same inputs giving the same output. That is the opposite of "trust us, we hold the keys."

If EVIDIQ both verified and custodied, then anyone attacking EVIDIQ's custody layer would also be attacking the trust signal — and a compromised trust signal is much worse than a lost transaction. Separate the two, and a custody breach doesn't poison the score, and a scoring bug doesn't move funds. We picked the cleaner failure mode.

[IMAGE_PROMPT: An abstract flat illustration of two separated vaults on a soft background — one labeled "Verification" (a transparent glass box showing a score and a signed document) and one labeled "Custody" (a solid steel box with a key icon). A subtle arrow shows evidence flowing from the verification vault to a separate settlement arrow, but no direct connection between the two vaults. Minimal dev-tool aesthetic, muted colors with one teal accent. No real brand logos.]

Here is what EVIDIQ does ship, and it is the part the custody-flavored competitors don't match:

• The verdict report is canonicalized and hashed with keccak256.
• The evidence is anchored on 0G Storage mainnet, with an on-chain tx you can re-fetch.
• An AI risk analysis can be run on 0G Compute with GLM-5.2 inside a TEE — the provider address and request id are recorded, so you can verify which model produced which output.
• The verdict is signed with the EVIDIQ key (EIP-191) and the signer is recoverable from the public key. Anyone, including your auditor, can re-run the formula against the same evidence and recover the same number and signature.

We call this whole pipeline the Notary layer. The EVIDIQ Notary docs have the schema and the verification flow. The point is that EVIDIQ's authority is evidence authority, not settlement authority. We are a witness, not a bank.

Honestly? This is the only honest answer to the AI agent escrow risk question in 2026: separate the verifier from the custodian, and let the developer pick how to enforce the recommendation.