Your agent just got back a 73.9. Or a 22. A single integer between 0 and 100, generated by a system you've never audited, about an agent you've never met. Are you supposed to ship a transaction on that?
We built EVIDIQ because that exact moment — when one autonomous agent decides whether to trust another — is where the agent economy either works or quietly doesn't. The AI agent trust score is the output of that decision, and in this post we're going to pull it apart line by line.
This is a spec walkthrough, not a launch announcement. We'll show the formula, the four sub-scores, the finding codes that justify them, and the honest places where the score can still be wrong.
The Formula, in Full
An AI agent trust score from EVIDIQ is a deterministic 0–100 rating that combines four sub-scores — identity, capability, reputation, and (inverted) risk — using fixed weights, then pairs it with a recommendation (proceed, proceed_with_escrow, caution, or do_not_proceed). Same inputs always produce the same score, and every report is signed and anchored on-chain.
The score is built from four sub-scores, each in 0–100, combined with fixed weights. There are no hidden model calls and no LLM-in-the-loop judgment on the final number — given the same inputs, the same score comes out every time. Anyone can re-derive it from the EVIDIQ docs.
trust = identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2
Identity and capability each pull 30% of the weight. Reputation and the inverted risk sub-score split the remaining 40%. The weighting is fixed on purpose: the score means the same thing to every caller, even though callers can pick their own thresholds above it.
Example A — a verified, live merchant agent:
- identity: 95 (verified EVM address + ENS + ERC-8004 id)
- capability: 88 (declared capabilities match the probed skill manifest)
- reputation: 70 (identity anchors + active x402 settlement)
- risk: 15 (TLS, sane headers, no red flags)
Score = (95·0.3) + (88·0.3) + (70·0.2) + (85·0.2) = 28.5 + 26.4 + 14.0 + 17.0 = 85.9
Example B — an anonymous, unreachable handle:
- identity: 20 (nothing verifiable)
- capability: 40 (declared but endpoint failed the probe)
- reputation: 10 (no anchors, no live service)
- risk: 75 (no TLS, mismatched contact)
Score = (20·0.3) + (40·0.3) + (10·0.2) + (25·0.2) = 6.0 + 12.0 + 2.0 + 5.0 = 25.0
A 60-point gap, fully explained by what's underneath. That's the design.
Why Four Dimensions and Not One Number You Just Trust
A single opaque score is a casino chip. The same number can come from an agent that knows nothing, or an agent that knows everything and got unlucky on one probe. Without sub-scores, you can't tell which. We decomposed EVIDIQ's trust score into four labeled dimensions because each one answers a different caller question:
- identity — who is this agent, and can a third party prove it?
- capability — what did it say it can do, and is the live endpoint actually serving it?
- reputation — does it have economic skin in the game yet?
- risk — what's the worst that's likely to happen if we proceed?
Callers can weight these differently. A high-value escrow workflow might demand identity ≥ 80 before unlocking funds; a low-stakes discovery crawl might accept any score above 30 with a proceed_with_escrow recommendation. The fixed weights in the headline number are a default — not a contract.
If you're building the agent that receives a score, the decomposed view also tells you how to improve. Hitting 70 on capability while sitting at 20 on identity tells you exactly which knob to turn. A single opaque score would have buried that signal — and a wallet balance alone tells you nothing about intent. That's the gap EVIDIQ closes.
The two surfaces that consume this score are documented in the EVIDIQ Sentinel docs (the consumer side) and the EVIDIQ Operator docs (the agent side that wants to know how it's being seen).
Reading a Finding Code
Sub-scores aren't magic. Every point of movement on a sub-score is justified by a finding code in the report — a short, stable string that names exactly what was observed. Here are four you'll see in the wild, and what each one means for downstream logic.
-
id.anonymous— Triggered when the agent has none of: a verifiable EVM address, an ERC-8004 on-chain identity id, an ENS name, or a TLS-served domain it can be tied to. Severity is high, because there is no third party who can attest to who this entity is. Downstream: any action involving value transfer should treat this as a hard stop or require escrow. -
cap.reachable— Triggered positively when our ~6s bounded GET probe succeeded: TCP connect, valid TLS, and a machine-readable surface (skill manifest, agent card, or MCP endpoint) was returned. Severity is informational in the positive direction and medium when absent. Downstream: missingcap.reachablecaps the capability sub-score and pushes the recommendation towardcautionordo_not_proceed. -
risk.no_tls— Triggered when the agent's advertised endpoint serves over plain HTTP. Severity is high. Even if the body is fine, you can't prove it wasn't tampered with in transit, and you can't prove it's the same endpoint tomorrow. Downstream: treat as a deployment-quality failure, not a content failure. -
rep.x402_live— Triggered positively when the endpoint is currently settling real x402 payments — economic activity, not a static page. Severity is medium in the positive direction, meaning it nudges reputation up but cannot single-handedly push a high-risk agent into trust. Downstream: presence is a strong signal of intent; absence is not a penalty, just neutral.
Findings are deterministic too: same inputs, same codes. They live alongside the score in the report so a caller can write policy like "reject if risk.no_tls is present regardless of total." That's exactly the kind of rule a single-number score cannot express.
Where the Score Can Be Wrong
Honest limits matter more than confident numbers, so here's where we admit the AI agent trust score can be wrong, and what we tell callers to do about it.
Probe timeouts look like unreachability. Our live probe is bounded at roughly six seconds. If an agent's endpoint is slow because of network jitter, a cold container, or a regional CDN miss, cap.reachable will be absent even though the endpoint is fine on retry. We surface the timeout in the report so callers can decide whether to re-probe, but the headline number won't double-count a retry automatically. Treat a single low capability score as evidence to verify, not a verdict.
A fresh legitimate agent scores low on reputation by construction. Reputation today is built from identity anchors and live signals — there is no shipped historical on-chain reputation ledger yet, no automated dispute resolution, no regulatory compliance certification (EU AI Act / AML), none of that. A brand-new agent that does everything right will still sit low on the reputation sub-score until it accumulates activity. That's the right behavior for the system as designed, but it means a low reputation score is not a moral judgment — it's a "we have not seen this one yet" signal. Worth noting for anyone comparing two new agents head-to-head.
Risk is a snapshot, not a forecast. We check TLS, headers, mismatch between declared contact and probed contact, and a small list of known-bad patterns. We don't observe the agent's runtime behavior over time. An endpoint that passes today can be compromised tomorrow. Treat the score as a TTL-bounded signal — we publish a valid_until for exactly this reason, and downstream code should respect it.
Capability matching is structural, not semantic. We confirm that declared capabilities correspond to a reachable machine-readable surface. We do not LLM-judge whether the agent's tool calls are correct for a given task — that's a different problem, and a harder one. If you need task-level evaluation, run it on top of our score, not instead of it.
We're listing these not to soften the score but to set the right expectations. A trust infrastructure that hides its failure modes is one we wouldn't ship ourselves.
