Your agent just received a $50,000 payout request from another agent it has never seen. The other agent claims to be a "high-frequency arbitrage bot, 99.4% win rate, audited." Sound familiar? That string of claims tells you nothing. No on-chain identity, no machine-checkable capability proof, no reputation you can verify. You have a wallet address and a story.
That gap is exactly what EVIDIQ closes. Our service takes any agent identifier, runs a battery of deterministic checks, and returns a single 0-100 AI agent trust score plus the evidence behind it. We don't hold funds. We don't grant authority. We produce a signed verdict and let the caller decide how to act on it — proceed, escrow, caution, or refuse.
This article is the spec walkthrough we wished existed when we started building it. No marketing varnish. Just the formula, the finding codes, and the honest limitations.
The Formula, in Full
An AI agent trust score from EVIDIQ is a deterministic number between 0 and 100 that reflects an agent's verifiable identity, declared capabilities, available reputation signals, and observable risk — combined into a single recommendation by the formula identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Same inputs always yield the same score.
Here is the whole thing, no abbreviation:
score = identity * 0.30
+ capability * 0.30
+ reputation * 0.20
+ (100 - risk) * 0.20
Each of the four sub-scores is itself a number between 0 and 100. The final number is then mapped to one of four recommendations:
proceed— score ≥ 80proceed_with_escrow— 60 ≤ score < 80caution— 40 ≤ score < 60do_not_proceed— score < 40
To make this concrete, let's run the formula twice.
Agent A — "ArbiKing" (claimed)
| Dimension | Sub-score |
|---|---|
| Identity | 92 (verified EVM address + ERC-8004 id + ENS arbiking.eth) |
| Capability | 88 (declared, live endpoint reachable, serves a valid agent-card) |
| Reputation | 75 (endpoint runs paid x402 service — "economic skin in the game") |
| Risk | 8 (TLS 1.3, fresh cert, no anomalous patterns) |
92*0.30 + 88*0.30 + 75*0.20 + (100-8)*0.20 = 27.6 + 26.4 + 15.0 + 18.4 = 87.4
Verdict: proceed. Signature: EIP-191, anchored on 0G Storage.
Agent B — "shadow_bot_42"
| Dimension | Sub-score |
|---|---|
| Identity | 5 (no verifiable anchor — id.anonymous) |
| Capability | 40 (reachable but serves no machine-readable surface) |
| Reputation | 10 (no history, no paid service) |
| Risk | 70 (TLS 1.0, self-signed cert, recent domain registration) |
5*0.30 + 40*0.30 + 10*0.20 + (100-70)*0.20 = 1.5 + 12.0 + 2.0 + 6.0 = 21.5
Verdict: do_not_proceed.
Same arithmetic. Same formula. That's the point — an AI agent trust score is auditable, not a vibe.
Why Four Dimensions and Not One Number You Just Trust
A single opaque score invites gaming. If the only output is "82/100," an attacker can probe the verifier, hill-climb on whatever they think is being measured, and game it. We learned that lesson the hard way designing v1 — and we scrapped it. The current design decomposes the verdict so the caller can see why, not just how much.
Here is why four dimensions and not one number:
- Identity tells you who is asking. Is there an EVM address? An ERC-8004 identity id? An ENS name? A TLS-served domain?
- Capability tells you what they can actually do, versus what they claim. We do a bounded ~6s live GET against the agent's endpoint and check for a machine-readable skill/agent-card/MCP surface.
- Reputation tells you what others have paid you to do. Today that's primarily economic signal — does the endpoint accept x402? That's "skin in the game" without needing a full historical ledger we don't have yet.
- Risk tells you what red flags fired. TLS version, cert age, anomalous header patterns, blacklists.
Each dimension can be weighted differently by the caller's own policy. A high-value transaction caller might weight identity at 0.5 and reputation at 0.1, while a low-stakes discovery caller might weight capability at 0.5 and risk at 0.1. The shape of the formula stays the same — the weights shift. We expose this in our EVIDIQ Operator docs.
Here's the thing: four labeled sub-scores also let you log which dimension dragged a borderline verdict down. That's debugging information a single number can't give you. And because each sub-score is bounded 0-100 with explicit triggers, the score is reproducible across runs, across operators, across jurisdictions.
Reading a Finding Code
Every AI agent trust score report comes with a list of finding codes — the atomic evidence bits the formula consumed. Each code has a namespace, a name, a severity, and a human-readable explanation. We treat them like compiler diagnostics: terse, structured, machine-parseable.
A few real ones you'll see in the wild:
id.anonymous— fired when no identity anchor was found. No EVM address, no ENS, no domain. Severity is high because it caps the identity sub-score at 20.id.ens_resolved— fired when the agent's ENS name resolves to the claimed EVM address. Severity is info. This adds a flat +10 to identity.cap.reachable— fired when the live probe completed within the ~6s budget and got a 2xx response. Severity is info. Without it, capability is capped at 50.cap.no_machine_card— fired when the endpoint responds but does not serve anagent-card.json,skill.md, or MCP-style tool listing. Severity is medium. Capability drops by 15.risk.no_tls— fired when the endpoint serves plain HTTP. Severity is high. Risk sub-score floored at 60.risk.self_signed_cert— fired when the TLS chain does not validate against a public CA. Severity is medium.
Downstream logic should treat these as gating events, not just scores. A risk.no_tls finding means the risk dimension alone disqualifies the agent from proceed, regardless of how good identity looks. That's by design. You can also pull the full code list from our EVIDIQ docs, and the full remediation playbook lives in the EVIDIQ Sentinel docs.
Our internal philosophy: codes are an API, not prose. We engineered them to be grep-friendly. If you can grep the report for risk. you can build a hard rule on top of any verifier's output. Your policy, your rule, our evidence.
Where the Score Can Be Wrong
We'd be lying if we said the score is infallible. It isn't. Here are the failure modes we know about, stated plainly because pretending otherwise would defeat the whole point.
- Probe timeouts look like unreachability. The live probe is bounded to ~6 seconds. If your agent is behind a slow cold-start, the probe returns
cap.unreachableeven though a retry would succeed. Retry the probe — or pre-warm the endpoint before asking for an AI agent trust score. - A fresh legitimate agent scores low on reputation by construction. Reputation today rewards existing identity anchors and live paid signals. A brand-new agent that has never accepted a single x402 payment will score near zero on reputation even if its identity and capability are immaculate. That's not a bug — it's an honest signal of "no track record yet." Calibrate your weight on reputation accordingly.
- TLS issuers we don't yet trust. The risk dimension penalizes self-signed certs. If you're running a private CA in a lab and pointing at it from a public agent endpoint, you'll be flagged. Use Let's Encrypt or similar. We're not the bad guys here — the network is.
- Cross-chain identity. ERC-8004 ids on chains we don't index show up as
id.partial. We add chain support on a rolling basis. Check the EVIDIQ Notary docs for the current supported set. - Sybil-resistant reputation is roadmap, not shipped. We do not yet have a smart-contract reputation ledger or automated dispute resolution. If your risk model requires historical behavior at scale, treat our reputation sub-score as a floor, not a ceiling, until that ships. EU AI Act and AML alignment sit on the same roadmap path.
Honest? We think the deterministic AI agent trust score is more useful precisely because its limits are specifiable. You can build around them. You can't build around a black box.