Decoding the AI Agent Trust Score: How EVIDIQ Really Scores Your Counterparty

The Formula, in Full

An AI agent trust score is a 0–100 number that summarizes how trustworthy an autonomous agent is at the moment you need to transact with it. EVIDIQ computes it deterministically from identity, capability, reputation, and risk sub-scores, then returns a proceed, proceed_with_escrow, caution, or do_not_proceed recommendation alongside the number.

You asked for a spec walkthrough. So here it is — the exact arithmetic we run for every verify_agent call, no rounding of intent.

The full formula is:

score = identity*0.30
      + capability*0.30
      + reputation*0.20
      + (100 - risk)*0.20

Each sub-score is itself a 0–100 integer computed from a fixed checklist of finding codes. The weights are not secret — they live in the EVIDIQ docs and in the open source MIT-licensed code at github.com/evidiq/mcp. Same inputs, same score, every time. We have no model in the loop that hallucinates a verdict.

Let's run it twice on very different agents.

Agent A — "librarian.agent.eth"

• identity: 90 — verifiable EVM address, ENS, ERC-8004 identity id
• capability: 85 — declared summarize, cite, search; live probe reachable, TLS valid, serves an MCP manifest
• reputation: 70 — endpoint runs a paid x402 service (economic skin in the game), no dispute history yet
• risk: 15 — fresh TLS, no red flags

score = 90*0.30 + 85*0.30 + 70*0.20 + (100-15)*0.20 = 27.0 + 25.5 + 14.0 + 17.0 = 83.5 → 84 Recommendation: proceed.

Agent B — "anon-agent.invalid"

• identity: 25 — anonymous host header, no ENS, no verifiable address
• capability: 40 — declared one capability; live probe timed out at ~6s
• reputation: 30 — no live signals, no anchors
• risk: 85 — no TLS, mismatched certificate chain, endpoint serves opaque binary

score = 25*0.30 + 40*0.30 + 30*0.20 + (100-85)*0.20 = 7.5 + 12.0 + 6.0 + 3.0 = 28.5 → 29 Recommendation: do_not_proceed.

The math is deliberately boring. That's the point. If a developer can re-derive the number from the evidence we publish, they can trust it.

Why Four Dimensions and Not One Number You Just Trust

A single opaque 0–100 invites a specific failure mode: it gets screenshotted, copied into a Slack channel, and treated as gospel. We have seen this exact pathology with credit scores, with page rank, with every "trust badge" widget that ever shipped. A number without decomposition is a number without accountability.

So EVIDIQ publishes the four sub-scores alongside the final number, plus the list of finding codes that fed each one. A caller can decide that for their use case, reputation matters more than identity (maybe they're paying a brand-new summarizer to do a small job) and weight things themselves on top. Or they can decide risk outweighs everything and refuse anything above 40. Honestly? This is where the AI agent trust score stops being a marketing badge and starts being engineering infrastructure.

This is also why our weighting isn't uniform. Identity and capability get 30% each because they are the floor: if you can't tell who the agent is or whether its claimed capability actually works, nothing else matters. Reputation gets 20% because for any agent launched in the last week — and there are a lot of them in 2026 — it is sparse by construction. Risk gets the remaining 20%, expressed as (100 - risk)*0.20 so that a low-risk agent contributes more, which matches the intuition that risk should be subtracted, not added.

Three more design choices worth flagging:

• We do not multiply sub-scores. A low identity score doesn't zero out a perfect capability score via multiplication — additive composition keeps the failure modes legible.
• We round once, at the end. Intermediate floats stay full-precision in the report so verifiers don't accumulate rounding error across recomputations.
• Every report is canonicalized, keccak256-hashed, and the hash is anchored on 0G Storage mainnet with an on-chain tx you can look up later.

If you want to dig into how the probe itself is implemented — the bounded ~6s GET request that fills in cap.reachable, tls.valid, and the machine-readable surface check — the EVIDIQ Sentinel docs walk through it. For how the operator side runs those probes at scale, see the EVIDIQ Operator docs.

Reading a Finding Code

Every sub-score is built from a list of finding codes. Each code is a dotted lowercase string: <dimension>.<signal>, with a severity tag of pass, warn, or fail. The combination of codes determines the sub-score via a fixed lookup table, and the codes themselves are what you read when you want to know why.

Here are the four you will see on basically every report, with the exact trigger and what downstream logic should do with them.

1. id.anonymous — fail severity. Triggered when we cannot resolve the agent to any verifiable identity anchor: no EVM address, no ENS, no ERC-8004 id, no TLS-served domain. Downstream: treat the agent as unidentifiable. Even if cap.reachable passes, you have no recourse if the agent misbehaves, because you can't even prove who you transacted with.

2. cap.reachable — pass/warn/fail. We issue a bounded GET to the agent's declared endpoint. pass means the probe returned a valid response under ~6s, with valid TLS, and the body served a recognizable skill, agent-card, or MCP manifest. warn means the response was partial — TLS valid but no machine-readable surface, or a soft 5xx. fail means timeout, DNS error, or TLS failure. This is the single most consequential finding code in the system: it directly determines whether the AI agent trust score's capability sub-score can climb past 50.

3. risk.no_tls — fail. Triggered when the agent's endpoint is offered over plain HTTP, or when the TLS chain doesn't validate against a public CA. We treat this as a hard fail regardless of how good the other dimensions look, because plain HTTP on an autonomous-agent endpoint is a man-in-the-middle waiting to happen.

4. rep.x402_economic_anchor — pass. The agent's endpoint actually responds to an x402 payment challenge. This is the strongest "skin in the game" signal we have today: the agent is staking its own uptime and reputation on a paid interaction. It feeds directly into the reputation sub-score.

A few more worth knowing: id.ens_resolved, id.erc8004_registered, cap.manifest_parsed, cap.method_declared, risk.stale_anchor, risk.recent_dispute — full list lives in the EVIDIQ Notary docs. The Notary is the piece that signs each report with the EVIDIQ key (EIP-191) and anchors the canonical hash on 0G Storage.

The opinionated take: a single high-severity fail should always reduce you to caution or do_not_proceed even if the arithmetic would otherwise clear. Our recommendation field bakes that in — the formula alone is necessary, not sufficient.

Where the Score Can Be Wrong

Honest section. Three concrete ways the AI agent trust score we return can mislead you, and how to handle each.

1. Probe timeouts look like unreachability. Our capability probe is bounded — if your network is having a bad day, or the agent endpoint is briefly overloaded, we'll record cap.reachable: fail even though a retry would succeed. This depresses capability by 10–20 points and is the most common reason a legitimate agent scores in the 50s when it deserves the 80s. Mitigation: call verify_agent again after a short backoff, and look at the probe_attempt_count field before acting on a low capability sub-score. We don't currently retry automatically — that's a roadmap item.

2. A fresh legitimate agent scores low on reputation by construction. Reputation today is built from live signals — does the endpoint run a paid x402 service, do we have identity anchors, has it served traffic recently. An agent that launched six hours ago and is technically immaculate can land at reputation: 30 simply because nothing has accumulated yet. This is not a bug, but it's a sharp edge: if you only transact with reputation >= 60, you will systematically exclude brand-new high-quality agents. Use proceed_with_escrow for agents with strong identity and capability but thin reputation.

3. Finding codes are a snapshot, not a guarantee. Anchored evidence on 0G Storage means you can re-fetch the report later and prove what we said at time T. But the underlying agent may have changed owners, been compromised, or rug-pulled between then and your transaction. The score is evidence of what was, not a promise about what will be. Pair it with your own escrow, your own rate limits, your own monitoring. We produce evidence; the protection is yours.

Worth noting too: we currently do not run a full historical on-chain reputation ledger, automated dispute resolution, or regulatory-compliance certification (EU AI Act / AML). Those are roadmap directions for 2026 and beyond, not shipped features. Don't believe anyone — including us — who implies otherwise.