How the EVIDIQ AI Agent Trust Score Actually Works

You paste an agent's address into a tool and get back a number. Then what? If that number came from a black-box model trained on vibes, you have no way to defend the call you made on top of it. That's the failure mode we built EVIDIQ to eliminate. Every AI agent trust score we issue is deterministic, explainable, and tied to evidence you can re-fetch yourself. This is the walkthrough of what that actually means under the hood.

If you're shipping an agent that pays other agents — or accepting calls from agents you didn't write — you need a number you can audit. Not a vibe. Not a learned heuristic. A score that comes out the same every time, with receipts.

The Formula, in Full

An AI agent trust score in EVIDIQ is a weighted blend of four sub-scores, each in the range 0-100, produced by the same inputs every time. The full formula:

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

That's it. Identity (0-100) + capability (0-100) + reputation (0-100) + risk (0-100, then inverted), each multiplied by a fixed weight and summed. Same inputs, same score, every caller, every time. The arithmetic is auditable in the EVIDIQ docs — no hidden weights, no model in the loop.

Let's compute it for two contrasting agents so you can see the spread.

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

• identity = 95 (verifiable EVM address, ERC-8004 identity id, ENS name)
• capability = 90 (declared capabilities match the agent-card; live probe of the endpoint succeeded under 6s, TLS valid, served a machine-readable MCP surface)
• reputation = 80 (endpoint runs a real x402 paid service — economic skin in the game)
• risk = 10 (no flagged patterns)

score = 95*0.3 + 90*0.3 + 80*0.2 + (100-10)*0.2 = 28.5 + 27 + 16 + 18 = 89.5 → rounded 90, recommendation: proceed.

Agent B — anonymous, unprobed, no anchor:

• identity = 10 (no EVM address, no ENS, no domain)
• capability = 5 (declared capabilities present but the endpoint didn't respond to the probe)
• reputation = 0 (no identity anchors, no paid service)
• risk = 70 (probe inconclusive, no TLS observed)

score = 10*0.3 + 5*0.3 + 0*0.2 + (100-70)*0.2 = 3 + 1.5 + 0 + 6 = 10.5 → rounded 11, recommendation: do_not_proceed.

Same formula, same weights, wildly different answers — and the caller can see exactly why.

Why Four Dimensions and Not One Number You Just Trust

Here's the thing: a single opaque score is a target. If a malicious operator knows that anything above 70 unlocks escrow, they will tune for 71. They will spoof identity. They will rotate addresses. They will game whatever single signal dominates the model.

Four labeled dimensions don't make the system game-proof, but they do make gaming expensive. To move the final number, an attacker has to push on every dimension simultaneously — identity, capability, reputation, and risk — and each one is checked against a different surface. Identity checks on-chain anchors and ENS. Capability checks a live probe of an endpoint. Reputation checks economic skin-in-the-game signals. Risk checks the probe's TLS posture and response patterns.

Worth noting: the weights are not fixed by your risk appetite. We chose identity0.3 + capability0.3 + reputation*0.2 + (100-risk)*0.2 because identity and capability are the hardest to fake. But you as the caller can re-weight. If you only care about whether the endpoint is reachable and not about on-chain anchors, you can compose your own score from the same sub-scores. The decomposition is the API. Our EVIDIQ Operator docs show how to consume the sub-scores directly and apply your own weights.

The recommendation — proceed, proceed_with_escrow, caution, do_not_proceed — is derived from the final score, but the four sub-scores are also returned so a caller can build a different policy on top. A wallet balance alone tells you nothing about intent. That's the gap EVIDIQ closes.

Reading a Finding Code

Every score ships with a list of finding codes. Each one is a stable identifier, a severity (info / warn / fail), and a short message explaining what the probe observed. They are the receipts that justify the numbers.

A few real ones you'll see in production:

• id.anonymous — severity: warn. Triggered when the agent has no verifiable EVM address, no ENS, and no TLS-served domain. It does not mean the agent is malicious; it means we cannot anchor its identity to anything cryptographically checkable. Downstream logic: treat as low identity score and require additional friction.
• cap.reachable — severity: info. Triggered when the bounded ~6s GET to the agent's endpoint returns 2xx with valid TLS and a machine-readable skill, agent-card, or MCP surface. Downstream logic: confidence boost on the capability sub-score.
• risk.no_tls — severity: fail. Triggered when the endpoint either has no HTTPS, has an expired certificate, or has a certificate that does not match the hostname. Downstream logic: hard cap on the risk sub-score; recommendation should not be proceed.
• rep.paid_x402_service — severity: info. Triggered when the endpoint advertises a 402 challenge and the scheme resolves to a valid x402 v2 payment requirement (accepts[].amount present). Downstream logic: positive signal on the reputation sub-score — the operator has economic skin in the game.

The full registry is published in our EVIDIQ Sentinel docs, and we extend it as new patterns emerge. Codes are stable strings, not natural language, so you can write policy against them directly.

Where the Score Can Be Wrong

We're honest about this: the score is a snapshot, not a verdict of character.

1. Transient probe failures look like unreachability. If the endpoint is healthy but our probe hits a 6s timeout because of a flaky route, cap.reachable will not fire and the capability sub-score will be low. The agent isn't bad; the network was bad. We expose the raw probe latency and status code in the report so a caller can retry. But the score as published reflects the observation we made, not the world.
2. A fresh legitimate agent scores low on reputation by construction. Reputation today is built from identity anchors and live signals (paid x402 service, declared domain). A brand-new agent that is genuinely well-built but hasn't yet accumulated any of those signals will land at a low reputation sub-score. That's correct behavior for the system, but it can produce a misleading low number for a perfectly trustworthy new operator. The recommendation will typically be caution, not do_not_proceed, which is the right gradient.
3. Risk sub-score is heuristic. It catches known bad patterns — missing TLS, suspicious response shapes — but it is not a full security audit. A clever attacker who serves valid TLS and a clean agent-card will still pass the risk dimension. Reputation and identity are the load-bearing walls, not risk.

If you need a score you can trust in adversarial conditions, the way to use EVIDIQ is not "fetch once and act forever" — it's "fetch, observe, and re-fetch on a schedule." The EVIDIQ Notary docs explain how to anchor the evidence receipt on 0G Storage so the report itself is tamper-evident.