Inside the EVIDIQ Trust Report: How the 0-100 AI Agent Trust Score Is Actually Computed

You pull a report on an unfamiliar agent. A single number sits at the top: 67. Proceed, or walk away?

That's the question a trust report is supposed to answer. But here's the thing — a number alone tells you nothing about why. The whole point of EVIDIQ's report is that the number is decomposed, auditable, and reproducible. Let me walk through exactly how the AI agent trust score is computed, what every finding code means, and where we know the math can still be wrong.

The Formula, in Full

An AI agent trust score from EVIDIQ is a deterministic 0-100 number produced by combining four independent sub-scores — identity, capability, reputation, and risk — each also on a 0-100 scale. The exact weighted formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2, and the same inputs always produce the same score.

The math fits on a sticky note, which is the point. We didn't build a model. We built a function.

trust = id*0.3 + cap*0.3 + rep*0.2 + (100 - risk)*0.2

Each input is itself a 0-100 derived from concrete findings — not vibes, not embeddings. Let's compute two contrasting cases so you can see the formula do its job.

Agent A — a well-anchored, reachable, paid service:

• identity: 95 — verifiable EVM address, ENS name, ERC-8004 identity id
• capability: 90 — declares image_gen and summarize, serves an MCP surface, TLS valid
• reputation: 80 — runs a paid x402 endpoint (economic skin in the game), fresh identity id
• risk: 10 — valid TLS, no risky headers, no impersonation patterns

trust = 95*0.3 + 90*0.3 + 80*0.2 + (100-10)*0.2 = 28.5 + 27.0 + 16.0 + 18.0 = 89.5 → 90. Recommendation: proceed.

Agent B — an anonymous, barely reachable, undocumented endpoint:

• identity: 5 — no EVM address, no ENS, no domain
• capability: 20 — endpoint returns 200 but serves no skill or agent-card
• reputation: 10 — no payment trail, no ERC-8004 anchor, no economic stake
• risk: 70 — self-signed cert, mismatched TLS hostname, slow response

trust = 5*0.3 + 20*0.3 + 10*0.2 + (100-70)*0.2 = 1.5 + 6.0 + 2.0 + 6.0 = 15.5 → 16. Recommendation: do_not_proceed.

Same formula, same weights, two completely different calls. That's the auditability property — anyone running the same inputs gets the same number. We documented the full schema in the EVIDIQ docs so integrators don't have to reverse-engineer it.

Why Four Dimensions and Not One Number You Just Trust

A single opaque trust score is a black box. And black boxes get gamed.

If EVIDIQ returned just trust = 73, an attacker could brute-force which inputs lift the number and tune their agent to game it. By exposing four labeled sub-scores, we make the scoring decomposable. A caller can read the report and answer questions like "is this agent cheap to trust on identity but weak on capability?" or "is the risk dimension dragging it down?" That's how you do risk-based routing in 2026 — and it's why our recommendation field isn't just a threshold but a label tied to the dominant sub-score.

Weights are also tunable per caller. Our default is 0.3 / 0.3 / 0.2 / 0.2 because, across the agents we've probed in 2026, identity and capability matter most to first-contact decisions. Your risk appetite might differ:

1. High-value settlement flows might weight risk at 0.4 and reputation at 0.3.
2. Micro-payment routing might weight capability at 0.5 and accept a wider identity spread.
3. Regulated workflows would want reputation to dominate until we ship the on-chain reputation registry (roadmap, not shipped yet).

You see the components and you decide. The end-to-end verification story is in the EVIDIQ Notary docs — the same canonical hash and signature we publish is what you re-derive on your side.

[IMAGE_PROMPT: A flat developer-aesthetic diagram showing four labeled rounded rectangles — "Identity 30%", "Capability 30%", "Reputation 20%", "Risk 20%" — with arrows flowing into a central gauge dial reading "0-100". A small code-snippet window in the corner shows the formula id*0.3 + cap*0.3 + rep*0.2 + (100-risk)*0.2. Clean modern muted teal and slate palette, no logos, no text outside the diagram labels.]

Reading a Finding Code

Every sub-score is built from a list of finding codes. These are the atomic units the report emits — strings like id.anonymous, cap.reachable, risk.no_tls — each tagged with a severity (info, warn, fail) and a numeric delta that lifts or drops its parent dimension.

Four you'll see often and what they actually trigger:

• id.anonymous — severity fail, large negative delta on identity. Fires when an agent provides no EVM address, no ENS, no ERC-8004 identity id, and no verifiable domain. Without some anchor, identity starts near zero.
• id.ens_resolved — severity info, positive delta. Fires when the declared ensName resolves to a primary record whose addr() matches the declared EVM address. Clean cryptographic check.
• cap.reachable — severity info if the probe gets a 2xx inside roughly 6s, fail otherwise. The probe is bounded on purpose — we aren't load-testing your service, just confirming the surface is alive and serving something machine-readable.
• risk.no_tls / risk.tls_mismatch — both fail, both on the risk dimension. The first fires when the endpoint is plain HTTP or the cert chain is untrusted; the second when the SAN on the cert doesn't match the host. Either should make a downstream caller pause.

A report can carry dozens of findings. The sub-score is the net after positive and negative deltas, clipped to [0, 100]. So a finding like rep.x402_paid_endpoint (positive, economic skin in the game) can lift reputation even when identity is mediocre.

If you're wiring EVIDIQ into a runtime, the EVIDIQ Sentinel docs walk through how the Operator pipeline reads each finding and picks between proceed, proceed_with_escrow, caution, and do_not_proceed.

Where the Score Can Be Wrong

Honest answer: the formula is deterministic, but the inputs are snapshots.

Here's what that means in practice.

Probe timeouts aren't outages. Our probe is bounded at roughly 6 seconds. If your endpoint is having a slow day — cold start, transient network blip — cap.reachable flips to fail and your capability score drops. The trust score drops with it. The agent might be perfectly fine. We can't tell from one snapshot. We surface this in the report (probe.timeout_ms is included) but it still costs the agent points until the next refresh.

A brand-new legitimate agent is reputation-poor by construction. Reputation today is scored from identity anchors and live signals — payment history, ERC-8004 presence, economic skin in the game. A legitimate agent that's been live for ten minutes has none of that. Its reputation starts near zero. That's correct behavior, but it means the AI agent trust score for a fresh, well-built agent is lower than it "should" be, and only improves over time. We're upfront about this — a future on-chain reputation ledger is on our roadmap, not in production.

Identity rewards what we can verify, not what's "good." An agent with a verified domain scores high on identity. An agent that has earned trust through thousands of successful settlements but never set up an ENS still scores low on identity today. The fix is the same reputation work, but until then identity is a check on what you can prove cryptographically, not on track record.

Risk is heuristic. We check TLS, header hygiene, hostname mismatches, and a handful of known-bad patterns. We aren't fuzzing. We aren't doing deep adversarial analysis. Risk is a smoke alarm, not a security audit.

If you want the runtime story — how the Operator uses these reports to gate transactions — that's covered in the EVIDIQ Operator docs.

[IMAGE_PROMPT: A flat illustration of a magnifying glass hovering over a stylized trust report card with four stacked horizontal bars showing subtle flaws — a faded reputation bar, a small warning triangle on the risk bar, a tiny probe-timer icon next to the capability bar. A clipboard with checklist motif sits in the corner. Clean developer aesthetic, soft amber and slate palette, no logos, no readable text outside labels.]