The AI Agent Escrow Risk Question: Proceed, Escrow, or Walk Away?

Last Tuesday a treasury operator at a payments startup pinged us with a message we'd seen a hundred times in 2026: 'An agent wants to arbitrage FX across our wallets. The wallet has history. But what do we actually know about it?' She'd already pulled on-chain forensics, ENS resolution, and a couple of X handles. The picture was murky — not obviously fraudulent, not obviously safe. Her real question was the AI agent escrow risk question: is this counterparty the kind we hand assets to, the kind we hand assets to with protection, or the kind we refuse entirely?

Four Verdicts, Not a Yes/No

An AI agent escrow risk verdict is the structured output of evaluating whether an autonomous counterparty deserves funds, deserves funds with conditions, or deserves neither. EVIDIQ produces one of four recommendations — proceed, proceed_with_escrow, caution, do_not_proceed — backed by an explainable 0–100 score and the evidence that produced it. The design choice behind four tiers is deliberate: most real counterparties live in the middle, and a binary answer fails them.

Most infrastructure in the agent economy still ships a binary verdict. Either the API key works or it doesn't. Either the wallet signed or it didn't. That's fine for connectivity — terrible for AI agent escrow risk, because trust isn't a switch. Here's the thing: the vast majority of real agents you'll evaluate in 2026 live in the middle. They've got an EVM address, maybe an ENS, a published skill file, payment accepted. None of that tells you whether the counterparty behind the agent will route your funds honestly. A yes/no verdict forces you to over-trust or refuse. Both are expensive.

So when you call verify_agent over at evidiq.dev/mcp, you don't get a boolean. You get a tier. And the tier encodes a specific posture we recommend you take. The four recommendations are:

• proceed — counterparty looks safe enough to settle directly.
• proceed_with_escrow — counterparty looks legitimate but lacks the historical signal to trust fully. Pair settlement with a protection mechanism.
• caution — significant gaps in identity, capability, or risk profile. Settle only on terms that make the downside tolerable.
• do_not_proceed — the evidence doesn't support handing this counterparty anything.

The treasury operator I mentioned at the top — her agent ended up scoring 67 with risk 41. Composite cleared the proceed_with_escrow floor by twelve points and failed the proceed floor by thirteen. That's a recommendation to settle with a protection mechanism, not a refusal and not a clean approval. The tier is the answer her team actually needed.

The Thresholds, Exactly

Let's get into the math. Our score is deterministic — same inputs, same output, every call. We built it that way on purpose, because the AI agent escrow risk threshold isn't a vibes call. It's a formula:

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

Each subscore is itself 0–100, pulled from real probes and real signals. Identity rewards a verifiable EVM address, an ERC-8004 identity id, an ENS, or a TLS-served domain. Capability rewards declared capabilities plus a live ~6s GET to the agent's endpoint — reachability, TLS, and a machine-readable skill or MCP surface. Reputation currently rewards identity anchors plus economic skin in the game: does the endpoint run a paid x402 service? The full historical reputation registry is on our roadmap, not shipped. Risk is inverted and subtracted because higher risk should lower the composite.

The recommendation tier is then a function of the composite, the risk subscore, and a capability floor:

1. proceed — composite ≥ 80 AND risk < 30 AND capability ≥ 70.
2. proceed_with_escrow — composite ≥ 55 AND capability ≥ 50 AND risk < 60.
3. caution — composite ≥ 30 and not eligible for any tier above.
4. do_not_proceed — composite < 30 OR risk ≥ 80 OR identity < 10.

A few things worth flagging. First, do_not_proceed is reachable through multiple paths: a globally bad composite, a catastrophic risk subscore, or near-zero identity. We wanted the system to refuse a low-identity-but-tempting-scores agent, because the AI agent escrow risk in those cases is concentrated in the unknown counterparty, not in the math. Second, proceed_with_escrow carries its own capability floor of 50 — handing an escrow contract to an agent that can't reliably serve its endpoint is theater. You're protecting funds from a counterparty that can't deliver anyway. Third, the thresholds aren't magic. They're the output of running EVIDIQ against a few hundred labeled agent profiles in 2026 and asking where the false-accept rate gets uncomfortable and where the false-reject rate starts costing real deals. The numbers fell where they fell.

[IMAGE_PROMPT: Flat technical illustration showing a vertical thermometer-style gauge split into four color bands labeled 'proceed' (top, green), 'proceed_with_escrow' (yellow-green), 'caution' (amber), and 'do_not_proceed' (red at bottom). To the right of the gauge, four floating formula tokens reading 'identity * 0.3', 'capability * 0.3', 'reputation * 0.2', and '(100 - risk) * 0.2'. Developer/blueprint aesthetic, thin line strokes, cool blue and slate palette. No text other than the labels on the gauge and the formula tokens. No brand logos.]

If you want to dig into the operational details — how probes are bounded, how evidence gets canonicalized, how the report is hashed and anchored — the EVIDIQ docs walk through the whole pipeline. For the security internals — TEE execution on 0G Compute, keccak256 anchoring, signature recovery — the EVIDIQ Sentinel docs are the right read.

Why proceed_with_escrow Is the One Most Deals Land On

Here's the honest version: most counterparties you'll evaluate in 2026 are neither obviously safe nor obviously fraudulent. They have an identity. They have an endpoint. They've accepted some payments. They have no meaningful history of disputes, refunds, or recovery. That's not a binary profile — that's the middle. And the middle is exactly where AI agent escrow risk concentrates, because the failure modes are the ones you can't see in a static snapshot.

The proceed_with_escrow tier is built for that middle. Its recommendation is the most operationally useful one in our system, and it's the one most call sites will actually consume. The pairing is straightforward in practice:

• Settlement on X Layer in USDT0 via x402's exact scheme with EIP-3009 transferWithAuthorization.
• Funds route into a third-party escrow contract (Safe-based, custom agent-escrow, whatever the parties chose) — not EVIDIQ.
• Release conditions trigger off the counterparty delivering an artifact, an attestation, or a timeout.
• EVIDIQ's signed report sits in the evidence package both parties can cite in any later dispute.

The point isn't that escrow makes the counterparty trustworthy. The point is that escrow makes the unknown survivable. You can settle with an agent you don't fully trust because your downside is bounded by what you've put into escrow, not by what you've put on the line.

We see this tier absorb the realistic operator posture more often than proceed does. A proceed recommendation requires historical signal that most agents simply don't have yet — they were deployed last quarter. do_not_proceed requires evidence of harm or near-total opacity, which most agents don't deserve. The middle is where deals happen, and the middle is where escrow earns its keep.

This is also where EVIDIQ's role inside an EVIDIQ Operator workflow becomes concrete: a treasury bot pulls an agent's identity, runs verify_agent, sees proceed_with_escrow, and routes the settlement through whichever escrow contract the operation has configured. The verifier doesn't pick the escrow, doesn't deploy the contract, doesn't touch the funds. It produces the verdict; the operator executes.

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

This is the design choice that gets misread the most. EVIDIQ is a trust layer, not a custody layer. We don't hold funds. We don't grant authority. We produce evidence and a recommendation; the parties choose their own protection. That's not a missing feature. It's the central architectural decision at EVIDIQ, and it's worth explaining why.

A custody system has a single, very expensive failure mode: the custodian gets compromised, and every party that trusted it loses simultaneously. An evidence-and-recommendation system has a different failure surface: the verifier can lie about a score, but the parties can independently re-fetch the evidence, re-hash it, and recover the EVIDIQ signing key. The verifier's reputation, the evidence anchors, and the signing key are auditable; the custodied funds are not.

The technical shape of this:

• The canonical report gets hashed (keccak256) and anchored on 0G Storage mainnet, which returns an on-chain transaction as the tamper-evidence trail.
• An AI risk analysis can run on 0G Compute with GLM-5.2 inside a TEE, recording both the provider address and the request id.
• The verdict is signed with the EVIDIQ key (EIP-191). Anyone can verify the signature against the canonical hash.
• The x402 payment layer — transferWithAuthorization on X Layer in USDT0 — settles in the open, not into EVIDIQ's wallet.

[IMAGE_PROMPT: Flat split-screen illustration. Left side: a glowing signed document with a keccak256 hash floating above it, an 'anchored on 0G Storage' badge, and a developer-console aesthetic. Right side: an abstract escrow vault with two stylized actors on either side, a release-arrow pointing from buyer to seller, and a small 'no third-party custodian' lock badge. The two halves are separated by a subtle vertical line. Cool blue and slate palette, thin strokes, no real brand logos, no text other than 'keccak256' and '0G Storage' badges.]

Mixing the two roles — verifier and custodian — collapses the trust surface into a single point of failure. Worse, it puts the verifier in a position where its recommendations get biased by its own balance sheet. We recommend proceed_with_escrow is meaningful when the verifier has nothing at stake in the escrow. It is suspicious when the verifier is the escrow.

That's the reason our EVIDIQ Notary docs describe a signing-and-anchoring service, not a custody service. We sign the verdict. We anchor the evidence. The parties — and the escrow contracts they choose — make the actual decision about funds. The recommendation is consumable by any downstream system: a treasury bot, a Safe module, a human reviewer, a court. Whoever holds the keys, holds the risk.