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

The Formula, in Full

The EVIDIQ AI agent trust score is a deterministic 0–100 number produced from four labeled sub-scores: identity (0–100), capability (0–100), reputation (0–100), and risk (0–100). The final score is computed as identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Same inputs always produce the same score.

Three numbers multiplied, two added. That's the entire formula.

It looks almost too plain to be the spine of a verification product, but plainness is the point. When two agents in 2026 decide whether to settle a paid task with each other, neither one wants a black-box number that says "just trust me, it's 74." They want a value they can re-derive, on their own machine, from inputs they can re-fetch. That's exactly what the EVIDIQ team ships.

Here's the formula again, written out:

score = identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2

Each sub-score is itself bounded 0–100 and produced from a small, named set of findings — codes we'll decode later in this article. The recommendation tag (proceed, proceed_with_escrow, caution, do_not_proceed) is a banded output of the final score combined with the risk class.

Let's run two agents through it. Both are real on the network today.

Agent A — a long-running service:

• identity: 95 (verifiable EVM address + ERC-8004 id + ENS name + TLS-served domain all confirmed)
• capability: 88 (declared capabilities match what the live ~6s probe serves back as an MCP-style surface)
• reputation: 70 (endpoint runs a paid x402 service, so there's economic skin in the game; no historical ledger yet)
• risk: 8 (TLS present, fresh certificate, no anomalous behavior)

score = 95×0.3 + 88×0.3 + 70×0.2 + (100−8)×0.2 = 28.5 + 26.4 + 14.0 + 18.4 = 87.3

Recommendation: proceed.

Agent B — a brand-new throwaway handle:

• identity: 18 (no address, no ENS, no on-chain id, no domain; just a wallet signature)
• capability: 30 (declared capabilities only, no reachable endpoint to probe)
• reputation: 5 (no anchors, no economic activity)
• risk: 72 (no TLS, served over plain HTTP, response patterns don't match a real agent card)

score = 18×0.3 + 30×0.3 + 5×0.2 + (100−72)×0.2 = 5.4 + 9.0 + 1.0 + 5.6 = 21.0

Recommendation: do_not_proceed.

Same formula, same weights, two opposite outcomes. That's the whole point of making the AI agent trust score reproducible instead of magical.

Why Four Dimensions and Not One Number You Just Trust

The temptation when designing any scoring product is to collapse everything into one number and call it done. Resist that. A single opaque integer invites three failure modes at once:

1. It's gameable. Without sub-scores, a sophisticated adversary can tune exactly the inputs that move the final number, and you can't tell which dimension they gamed.
2. It's unauditable. The caller has no way to disagree with part of the result. Either they take the number or they don't — there is no "I'll accept the capability claim but ignore the reputation reading."
3. It's under-weightable by the caller. Different transactions have different risk appetites. A 30-cent micro-task can tolerate a 60 score; a $10,000 escrow cannot.

Decomposing the AI agent trust score into four labeled dimensions — identity, capability, reputation, risk — solves all three at once. The caller sees exactly which findings moved which sub-score. They can apply their own floor or cap per dimension. And a gaming attacker has to game all four simultaneously, not just one lever.

The weights themselves (0.3 / 0.3 / 0.2 / 0.2) are a default, not a law. The EVIDIQ docs publish them and explain the rationale: identity and capability together carry 60% because they answer "who is this and can it do the thing" — the two questions that matter most before any money moves. Reputation and risk split the remaining 40% as forward-looking signals about whether to expect trouble.

For a full walkthrough of each dimension's signal sources, the EVIDIQ Notary docs spell out exactly what the evidence pipeline records and signs. Worth reading before you wire the score into anything serious.

Reading a Finding Code

Every sub-score is the result of a list of findings. Each finding has a stable dotted code, a severity, and a one-line evidence trail. If you've ever read a linter report, the shape will feel familiar. Here's what the codes actually mean in 2026:

1. id.anonymous — severity HIGH. Triggered when the agent presents no verifiable EVM address, no ERC-8004 on-chain identity id, no ENS name, and no TLS-served domain. The agent may still sign requests with a wallet, but that's not enough to anchor an identity claim. Downstream effect: identity sub-score capped at ~25.
2. id.ens_verified — severity INFO. Triggered when the agent's address resolves to a forward ENS record. Identity gets a clean bump; no penalty if missing.
3. cap.reachable — severity INFO if present, blocks the score entirely if absent. Triggered by the live ~6s probe returning a valid HTTP response from the declared endpoint. Without this, the capability sub-score cannot exceed the declared-only baseline (around 30).
4. cap.mcp_surface — severity INFO. Triggered when the reachable endpoint serves a machine-readable skill, agent-card, or MCP manifest at a known path. Capability gets a further bump.
5. risk.no_tls — severity HIGH. Triggered when the endpoint serves plain HTTP or has an expired or invalid certificate. The risk sub-score jumps by 20+ and can single-handedly push the final recommendation to caution.
6. risk.x402_paid — severity INFO (positive). Triggered when the endpoint responds to a probe with a proper HTTP 402 challenge using the x402 v2 accepts[] envelope. Reputation reads this as economic skin in the game.
7. rep.no_history — severity LOW. Triggered when the agent's identity anchors are fresh and there's no on-chain activity to read yet. Reputation sub-score is intentionally low here — it's not a penalty, it's a correct reading.

The codes are stable across versions and machine-parseable. If you wire EVIDIQ into a downstream policy engine, you don't have to parse English — key off code and severity directly. Each finding in the report also carries the raw evidence URI, so a curious caller can re-fetch and re-check without trusting us blindly.

Where the Score Can Be Wrong

We try to be honest about this. The AI agent trust score is a snapshot, and snapshots lie in specific, predictable ways:

• Probe timeouts look like unreachability. Our probe is bounded at ~6 seconds. If your endpoint is slow on a particular cold-start, we'll record cap.unreachable even though the agent is fine on retry. We're working on adaptive retry budgets for 2026.
• A fresh legitimate agent scores low on reputation by construction. Reputation needs something to read. A new operator who just stood up a real, well-configured agent will see rep in the single digits for the first few weeks. That's not wrong — it's honest. Reputation is allowed to grow as activity accrues.
• Identity anchors are sybil-resistant, not sybil-proof. Owning three ENS names still produces three identity bumps; we don't claim one operator can't farm a few handles.
• TLS freshness is checked, not certificate pinning. We verify the chain and expiry, not whether the cert was pinned by the agent author.
• EVIDIQ doesn't see private state. If an agent has a great reputation inside a closed consortium ledger we can't read, we won't see it. Our reputation reading is intentionally based on identity anchors and live signals — does the endpoint run a paid x402 service, the so-called "economic skin in the game" — not a full historical on-chain reputation registry yet. That broader ledger is on our roadmap.

We'd rather you know the failure modes now than discover them in production. The verification system, EVIDIQ, is designed to be auditable end-to-end — every score can be re-derived from the canonical report, which is hashed, anchored on 0G Storage mainnet with an on-chain tx receipt, and signed with the EVIDIQ key (EIP-191). Anyone holding the report can re-fetch the evidence, re-hash it, and recover the signer.