Inside the EVIDIQ Trust Report: How the AI Agent Trust Score Really Works

Imagine your agent just paid $4,200 USDC to another agent for "GPU inference credits." Five minutes later you find out the counterparty was a freshly spun-up wallet with no identity, no reachable endpoint, and a domain registered last Tuesday. The transaction settled. The work didn't happen. You have a signed x402 receipt and a hard lesson: a wallet balance tells you nothing about intent.

That's the gap EVIDIQ closes. Every request to our verify_agent tool returns a single number — an AI agent trust score from 0 to 100 — plus the evidence behind it. We've published the math on purpose. Here's how it's actually built.

The Formula, in Full

The AI agent trust score from EVIDIQ is a deterministic weighted sum of four sub-scores — identity, capability, reputation, and risk — combined into a single 0–100 number with an explicit recommendation (proceed, proceed_with_escrow, caution, do_not_proceed). Same inputs, same score, every time. It's auditable, not a black box.

The formula, exactly:

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

Each sub-score is independently 0–100. The weights are fixed in code, not learned, not tuned per-caller. Let's run two real-shaped examples through it side by side.

Agent A — "NimbusCompute" (well-formed, mature):

• identity: 90 (verified EVM address + ERC-8004 id + ENS nimbuscompute.eth)
• capability: 85 (declared gpu.inference; live probe returned 200, valid agent-card, TLS A)
• reputation: 70 (endpoint has been resolving for 8 months; serves a paid x402 endpoint — economic skin in the game)
• risk: 15 (no disallowed patterns, valid TLS, no sanctions hits)

trust = 90*0.3 + 85*0.3 + 70*0.2 + (100-15)*0.2
      = 27 + 25.5 + 14 + 17
      = 83.5  → recommendation: proceed

Agent B — "ghost-infer-94f3" (fresh, opaque):

• identity: 10 (no EVM sig, no ENS, no on-chain id; only a claimed wallet)
• capability: 40 (declared capability set present, but endpoint probe timed out at ~6s)
• reputation: 5 (no prior signal, no paid endpoint)
• risk: 80 (no TLS, claim mismatches, recently-registered domain)

trust = 10*0.3 + 40*0.3 + 5*0.2 + (100-80)*0.2
      = 3 + 12 + 1 + 4
      = 20    → recommendation: do_not_proceed

Same formula. Same weights. Completely different call you make afterward. That difference isn't magic — it's decomposition.

Why Four Dimensions and Not One Number You Just Trust

A single opaque number is the easiest thing in the world to game. One composite "trust" field invites two failure modes: the vendor tunes it to whatever their biggest customers want to see, and the bad actor reverse-engineers the threshold they need to clear. Both are real, and both break the moment an agent starts moving real money.

Four labeled sub-scores break that. When we return the AI agent trust score from verify_agent, we also return the four components plus the finding codes that drove each. A caller building a high-value settlement flow can weight risk more heavily; a caller doing cheap, reversible API discovery can lean on capability and ignore identity. The recommendation field is opinionated; the sub-scores are raw inputs you can re-blend for your own appetite.

There's a second reason. The four dimensions fail independently. An agent can have perfect identity but an unreachable endpoint. It can have great reputation and a freshly-laundered risk profile. When a dimension tanks, you can see which one — and crucially, why. A score of 23 with a risk.no_tls finding tells you a very different story than 23 with id.anonymous. Same number, opposite fixes.

The four dimensions, in plain terms:

1. Identity (0–100) — how verifiable is the agent's claimed self? EVM signature, ERC-8004 on-chain id, ENS name, TLS-served domain.
2. Capability (0–100) — does the agent do what it says? Declared capabilities plus a live bounded probe (≤6s GET) checking reachability, TLS, and a machine-readable skill/agent-card/MCP surface.
3. Reputation (0–100) — does the agent have skin in the game? Currently anchored on identity signals plus live economic signals like serving a real paid x402 endpoint.
4. Risk (0–100, inverted in the formula) — what red flags did we observe? Higher is worse; subtracted from 100 before weighting.

If you're orchestrating payments across many agents, our EVIDIQ Operator docs walk through how to plug sub-scores into your own routing policy. If you're a single agent deciding whether to call another, the EVIDIQ Sentinel docs show the drop-in skill pattern. Either way, the numbers are yours to act on, not ours to hide.

Reading a Finding Code

Every sub-score in an AI agent trust score is annotated with one or more finding codes — short, machine-readable strings that say exactly what triggered a deduction. We've kept them stable across versions so your routing code can branch on them. Here's what the common ones actually mean:

• id.anonymous — The agent presented no verifiable identity anchor. No signed EVM address, no ERC-8004 on-chain id, no ENS, no TLS-served domain. Identity sub-score capped at 30. Trigger: this is the default state for any agent that has not yet claimed itself. It's not a verdict of malice; it's an absence of evidence.
• id.erc8004 — Positive signal. The agent's claimed address resolves to a valid ERC-8004 identity registry entry on a supported chain. Adds to identity score.
• cap.reachable — Capability probe succeeded. We issued a bounded GET (≤6s, ≤512KB) to the agent's declared endpoint and got a parseable skill/agent-card/MCP surface back. Adds to capability score.
• cap.probe_timeout — The probe didn't return within the time budget. The endpoint may be fine — we just couldn't reach it from our vantage in this call. Capability sub-score gets a deduction; risk gets a small bump. Caller should consider retrying before treating it as a verdict.
• risk.no_tls — Endpoint is reachable but not over HTTPS, or the certificate chain failed validation. Hard bump to risk. Most regulated flows won't proceed past this; some sandboxed flows might.
• rep.x402_paid_endpoint — Positive signal. The agent's endpoint serves a real, payable x402 resource (i.e. it returns 402 with a valid accepts[] block). We treat that as economic skin in the game — someone has paid to keep it live. Reputation sub-score gets a meaningful lift.

The codes are meant to be branched on. A typical integration might look like:

1. Pull the trust number. If ≥ 75 and recommendation is proceed, settle directly.
2. If 50–74 or recommendation is proceed_with_escrow, route through escrow; require id.erc8004 or id.ens to be present.
3. If 25–49 or recommendation is caution, hold and request an out-of-band verification step.
4. If < 25 or do_not_proceed, refuse the call and log the finding codes for audit.

The order matters. Score first, branch on the codes that drove the score.

Where the Score Can Be Wrong

Honest section, because the spec is only useful if you know where it bites you.

A probe timeout looks identical to unreachability. Our capability probe is bounded to roughly 6 seconds from our vantage point. If your vantage differs — geographically, or behind a different egress — the agent may be perfectly reachable for you and unreachable for us. We mark that cap.probe_timeout rather than cap.unreachable, but the AI agent trust score still reflects what we observed. Retry first; treat the low score as a soft signal, not a verdict.

A brand-new legitimate agent scores low on reputation by construction. Reputation is the slowest-moving of the four dimensions. A solo developer spinning up a clean agent today has no track record, no paid endpoint, no anchors — and will post a reputation sub-score in the single digits for weeks. That's not a defect, it's the cost of "reputation" meaning anything. If you're evaluating new agents, lean on identity and capability, and use the EVIDIQ docs page on reputation ramp to plan a re-check window.

Identity is also asymmetric. Adding a verifiable anchor (sign with your EVM key, register an ERC-8004 id, point an ENS name at your endpoint) lifts your score. Removing that anchor drops it. Spoofing an anchor is detectable — the signatures have to verify against the chain — but it costs the attacker gas and a real address. That's the bar we want.

Worth noting: the risk dimension is heuristic. We're not a sanctions engine, not an AML provider, not certified against the EU AI Act. We surface what we can observe and we don't claim coverage we don't have. For regulated flows, the AI agent trust score is an input, not a substitute for your compliance layer. We'd rather you know that now than at audit time.