Decoding the AI Agent Trust Score: Inside the EVIDIQ Spec

Picture this: your agent just received a payment request from a counterparty it has never talked to before. The address has four transactions, no ENS, no skill manifest at the advertised endpoint, and a landing page that promises "guaranteed 10x returns." Is it a real service or a one-shot scammer? In 2026, that question is the whole game. Wallet balance tells you nothing about intent. Chat history tells you nothing about the other side's infrastructure. Vibes, definitely, tell you nothing.

That's why we built EVIDIQ's AI agent trust score — a deterministic 0–100 number with a per-dimension breakdown, a set of labeled finding codes, and a tamper-evident report you can re-fetch and re-hash yourself. This post pulls the hood off. No marketing, no hand-waving. We are walking the spec the way an integration engineer would.

The Formula, in Full

An AI agent trust score is the 0–100 verdict EVIDIQ returns after verifying an agent's identity, declared capabilities, live endpoint reachability, and risk surface — combining four sub-scores into one auditable number. It is deterministic: same inputs always produce the same score, and the report is cryptographically signed by the EVIDIQ key.

We chose a weighted sum, not a neural net, on purpose. Auditors need to re-derive the answer. So here is the full formula, exactly as it runs in our service:

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

Each sub-score is an integer in [0, 100]. The result is rounded to the nearest integer and clamped. The weights encode the same tradeoff every risk team eventually converges on: who you are (30%) and what you claim you can do (30%) matter most, with reputation and risk as the tiebreakers.

Let's run two agents through it.

Agent A — "verified-pay-svc": ERC-8004 identity id present, ENS verified-pay-svc.eth, hosts an HTTPS endpoint that serves a valid agent card, accepts x402 payments (real economic skin in the game), TLS 1.3, no findings.

• identity = 95
• capability = 92
• reputation = 70
• risk = 5

score = 95*0.3 + 92*0.3 + 70*0.2 + (100-5)*0.2 = 28.5 + 27.6 + 14.0 + 19.0 = 89.1 → 89

Recommendation: proceed. That feels right.

Agent B — "anon-airdrop-bot": no identity, no ENS, no domain. Endpoint times out on probe. No TLS. Advertises "guaranteed 10x return."

• identity = 5
• capability = 10
• reputation = 5
• risk = 92

score = 5*0.3 + 10*0.3 + 5*0.2 + (100-92)*0.2 = 1.5 + 3.0 + 1.0 + 1.6 = 7.1 → 7

Recommendation: do_not_proceed. Also feels right.

The math is the math. You can re-derive it. That is the point.

Why Four Dimensions and Not One Number You Just Trust

A single opaque score is begging to be gamed. Strip the labels and you get a number that nobody — neither you, nor your auditor, nor a regulator — can interrogate. We score four dimensions on purpose:

• Identity (weight 0.3) — is this entity a real, addressable thing? Anchored by an EVM address, an ERC-8004 identity id, an ENS name, or a TLS-served domain.
• Capability (weight 0.3) — does the agent actually do what it claims? We blend declared capabilities against a live probe of the endpoint (a bounded ~6s GET).
• Reputation (weight 0.2) — does the agent have skin in the game? Today this is signal-based (paid x402 service, observed uptime), not a full historical ledger.
• Risk (weight 0.2) — what is the surface that hurts you if it goes wrong? Wildcard claims, open redirectors, missing TLS, unreachable infra, prompt-injection-shaped agent cards.

Two integration teams can take the same four sub-scores and weight them differently. A high-value B2B escrow flow might cap identity at 0.4. A consumer micropayment bot might cap risk at 0.4. We expose the raw components in every report — see EVIDIQ Sentinel docs for the response shape — so you can re-weight on the receiving side without re-calling us.

The honest reason for decomposition: nobody trusts a black box that says "trust me, 89." Everyone trusts an explanation that says "identity 95, capability 92, risk 5 — here is why each." The report is signed by the EVIDIQ key (EIP-191), the canonical body is keccak256-hashed, and the evidence itself is anchored on 0G Storage. See EVIDIQ Notary docs for the anchoring flow.

Reading a Finding Code

Every AI agent trust score report carries a list of findings. Each finding is a dotted string — a category and a code — plus a severity and an evidence pointer. The codes are deliberately boring. They map to things you can verify yourself.

Here are four you will see often:

1. id.anonymous (severity: high) — triggered when the agent has no EVM address, no ERC-8004 identity, no ENS, and no verifiable domain. It drags identity toward zero. Downstream logic: refuse high-value flows, allow only tiny x402 pings.
2. cap.reachable (severity: info) — the agent's endpoint answered our bounded ~6s probe, TLS handshake succeeded, and the body contained a recognizable machine-readable surface (skill.md, MCP manifest, or agent card). This is a positive finding — it nudges capability upward.
3. risk.no_tls (severity: critical) — the endpoint is plain HTTP, or the cert chain fails verification. EVIDIQ flags this regardless of how nice the rest of the report looks. Plain HTTP means anyone on the path can rewrite the agent card, including the payment address.
4. rep.x402_payer (severity: info) — the endpoint accepts x402 payments and has been observed settling on X Layer. Economic skin in the game, not just talk. This nudges reputation upward.

Three useful patterns for downstream code:

• Treat severity == critical as do_not_proceed, regardless of the headline number. The aggregate score is a summary; criticals override it.
• Treat id.anonymous + rep.x402_payer together as "new but paying" — proceed only with escrow or strict caps. Full details in EVIDIQ Operator docs.
• A single risk.no_tls on an otherwise clean agent means the operator probably stood it up for a hackathon. Wait and retry later, or proceed only over a pinned channel.

The full code list lives in EVIDIQ docs. We add new codes only when the failure mode is concrete enough to encode as a deterministic check, not before.

Where the Score Can Be Wrong

Honest limitations matter. Here are the cases where EVIDIQ's number will be wrong, or at least unhelpful, and what we recommend you do about it.

Probe timeouts. Our live probe is a bounded ~6s GET. If the agent is rate-limiting us, behind a cold-start lambda, or just slow on a flaky mobile uplink, the probe times out and we record cap.unreachable — which is indistinguishable, from the outside, from "this agent does not exist." The right move is to retry after a backoff and treat a single failure as soft signal, not a hard veto. We've burned ourselves on this in internal testing; the report tells you the probe timestamp so you can decide.

Brand-new legitimate agents. Reputation is signal-based today — paid x402 service, observed uptime, identity anchors. A perfectly good agent that registered yesterday has, by construction, no reputation signal yet. Their AI agent trust score will read lower than it deserves. Don't punish newness; pair the report with your own allowance logic. We are working toward a proper historical ledger in our roadmap, but it isn't shipped yet, and we will not pretend otherwise.

Self-reported capability. The agent's agent_card.json says it can do X. We blend that against the probe, but we do not run a full behavioral suite — that is a different product. If the endpoint is a thin wrapper around an LLM that hallucinates capability, our score will not catch it. Use EVIDIQ for identity and surface risk, not for behavioral audits.

Coordinated Sybil attacks. Four addresses, four ERC-8004 ids, four endpoints that all point at the same backend? Today we score them independently. Graph-level sybil detection is on the roadmap but not in the production formula.

Regulatory and compliance signals. EU AI Act alignment, AML checks, KYC attestations — none of these are part of the score today. They are sensible roadmap items, but they are not shipped features, and no report you fetch will claim otherwise.

When in doubt, fetch the report twice. The score is deterministic, so any drift is a real signal — usually our cache invalidating, occasionally upstream evidence getting updated.