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

Pull up any EVIDIQ report and the headline number is the same shape: a single value between 0 and 100, plus a recommendation verb — proceed, proceed_with_escrow, caution, do_not_proceed. That verb is the part that should drive your automation. The number on its own is the part humans quote in screenshots.

But here's the part most people skip past: the score is computed, not guessed. Same inputs in, same score out, every time. In 2026 that's a feature, not a footnote — because "trust" in an autonomous-agent economy has to be auditable, or it's just marketing.

In this walkthrough we're going to crack open one of our own reports and look at the moving parts. No handwaving. If you've ever wanted to know why an agent scored 71 and not 84, this is for you.

The Formula, in Full

An AI agent trust score is the deterministic 0–100 number EVIDIQ produces by combining four labeled sub-scores — identity, capability, reputation, and risk — into a single weighted value, then pairing it with an explicit recommendation the caller can act on directly in their orchestration logic.

The exact formula our reports use:

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

Each sub-score is itself 0–100. The weights aren't secret, they're on the report and in our docs. We picked them so that identity and capability carry the most weight — you can't trust an agent you can't identify or reach — with reputation and risk acting as modifiers.

Let's run it on two contrasting agents side by side. First, the high-trust case:

Agent A — "AtlasIndexer"

• identity: 95 (verified EVM address + ENS atlas.eth + ERC-8004 id 0x4f…1a)
• capability: 90 (declares 3 capabilities, all probed live and reachable over TLS, serves a valid agent card)
• reputation: 80 (paid x402 service live, endpoint uptime > 99%, identity anchors stable)
• risk: 15 (no TLS issues, no deprecated primitives, declared surface matches served surface)

score = 95*0.3 + 90*0.3 + 80*0.2 + (100-15)*0.2 = 28.5 + 27 + 16 + 17 = 88.5 → rounds to 89, recommendation: proceed.

Now the opposite end:

Agent B — "anon-crawler-7"

• identity: 10 (no EVM address, no ENS, no on-chain id, no domain)
• capability: 25 (declares 2 capabilities, only 1 probeable, TLS ok but no machine-readable skill)
• reputation: 5 (no paid service, no history, no anchors)
• risk: 75 (declared surface larger than served surface, capability "web scraping" overlaps risky category)

score = 10*0.3 + 25*0.3 + 5*0.2 + (100-75)*0.2 = 3 + 7.5 + 1 + 5 = 16.5 → rounds to 17, recommendation: do_not_proceed.

Same formula, same arithmetic, no hidden model. That's the whole point of going deterministic. When you recompute it from the inputs we publish in the report, you should land on the same number every time.

Why Four Dimensions and Not One Number You Just Trust

A single opaque score is how you get rugpulled. Four labeled sub-scores are how you reason.

[IMAGE_PROMPT: A flat modern developer-aesthetic illustration of a four-quadrant dashboard panel floating on a soft dark background. Each quadrant is a labeled gauge — Identity, Capability, Reputation, Risk — with a colored needle pointing at a numeric value. Thin connecting lines converge at a central rounded badge showing the number 89 in bold. The color palette is muted teal, amber, and slate gray with subtle neon accents. No text other than the quadrant labels and the central number. No brand logos.]

The reason we decomposed it isn't aesthetics. It's that different callers weight risk differently. A read-only information retrieval agent with no payment authority is a fundamentally different exposure than an agent that holds escrow. If the report only showed you "89", you'd have no way to know whether the 11 missing points were reputation (probably fine for a young agent) or risk (much scarier).

So the report surfaces all four numbers. You can apply your own overlay:

1. A consumer agent routing small tasks might floor capability at 60 and ignore reputation under 20.
2. A treasury agent moving real funds might multiply risk by 2x and require identity ≥ 90.
3. A research agent crawling public data might cap risk at 30 and not care about reputation at all.

The recommendation verb is EVIDIQ's default read; the sub-scores are the actual contract. Treat the verb as a default, not a verdict. A single opaque AI agent trust score is convenient; four labeled sub-scores are safe.

This is also why we publish our verifier and the EVIDIQ Operator docs — anyone can recompute the AI agent trust score from the same inputs and check the arithmetic themselves. Black boxes don't survive audit.

Reading a Finding Code

Every sub-score on a report is backed by a list of finding codes — short, machine-readable strings like id.anonymous, cap.reachable, or risk.no_tls. Each finding is either a positive contribution to a sub-score or a risk warning that drags it down.

Here are the four you'll see most often:

• id.anonymous — Severity: high. Triggered when the agent has no EVM address, no ENS, no ERC-8004 on-chain id, and no verifiable domain. This single finding caps identity at 25 by itself. It doesn't mean the agent is malicious — it means the trust anchor is missing. For our 17-scoring Agent B above, this was the dominant finding.
• id.erc8004 — Severity: informational, positive. Triggered when we find a registered ERC-8004 identity id on-chain. Adds +20 to identity on its own and unlocks reputation lookups once that registry is wired in.
• cap.reachable — Severity: informational, positive. The probe (a bounded ~6s GET request) successfully reached the endpoint, validated TLS, and got a 2xx response. Without this finding, capability is capped at 40 — we won't vouch for what we couldn't talk to.
• risk.no_tls — Severity: critical. Triggered if the declared endpoint is plain HTTP, has an expired cert, or fails TLS validation. One of the few findings that pulls risk above 70 automatically and flips the recommendation toward do_not_proceed regardless of other scores.

Did you notice how severity is qualitative, not just numeric? That's intentional. risk.no_tls isn't worth 5 points — it's a structural break. The risk sub-score reflects that. You can read the full finding catalog in the EVIDIQ docs, but the takeaway is: treat finding codes like log lines, not like decorations.

Where the Score Can Be Wrong

Honest list of failure modes we've seen in 2026, in order of how often they happen:

1. Probe timeout masquerading as unreachability. Our probe is bounded at ~6 seconds. If your endpoint is rate-limiting us at the moment of the call, you'll come back as cap.unreachable even though you're fine on retry. We've added a single automatic retry on timeout, but a perpetually slow server will still look unreachable.
2. Fresh legitimate agents scoring low on reputation. Reputation today is anchored on identity strength and live signals (e.g. does the endpoint operate a paid x402 service — "economic skin in the game"). A brand-new agent that's actually brilliant but hasn't yet done any paid work will score near zero on reputation. That's by construction. Don't reject new agents for low reputation alone.
3. DNS propagation lag. We resolve the domain at probe time. If you pointed a new CNAME at your endpoint five minutes before the call, the probe may resolve against the old record and mark the wrong surface as unreachable.
4. Endpoint serving a human landing page instead of a machine-readable skill. If your agent's URL returns a beautiful marketing page with no /agent-card.json, no MCP manifest, no /.well-known/agent, we treat that as no declared surface — which caps capability even if the agent is fully working. Fix: serve one of those files.

The deeper point: a trust score is a snapshot. We refresh on demand via verify_agent and you can also run your own check via the EVIDIQ Sentinel docs. Anything you decide to do based on a stale report is your problem, not ours.

[IMAGE_PROMPT: A flat technical illustration showing a magnifying glass hovering over a glowing document labeled TRUST REPORT. Around the document, small floating tags show status labels like PROBE TIMEOUT, LOW REPUTATION, DNS LAG, NO AGENT CARD connected by thin lines. The color palette uses muted coral, soft blue, and warm amber against a deep navy background. Modern flat design, no logos, no readable text beyond the document label and the four tag labels.]