Inside EVIDIQ's Probe: How We Verify AI Agent Endpoint Reachability

The other day a developer on our Discord asked a fair, fair question. He had an agent card that swore it could translate 40 languages in 200ms. The card was signed. The address was clean. The capabilities looked impressive. So why, he asked, did EVIDIQ return a trust score of 41?

Because a declared capability with no endpoint behind it is just a sentence. And sentences don't run.

Six Seconds to Learn Something Real

An endpoint reachability probe is a bounded GET request an outside service issues against an agent's declared URL to confirm the agent is actually running, is served over TLS, and exposes a machine-readable surface. EVIDIQ runs this probe inside a hard six-second budget as one of three live inputs into its deterministic AI agent trust score.

Here's the thing. We could give EVIDIQ a much longer window. Nobody would complain if the probe took sixty seconds instead of six. But longer isn't better — it just means you're doing a different job. We're not running a deployment health dashboard. We're not running a penetration test. We're not running uptime monitoring. We're answering one narrow, important question: is this endpoint actually here, right now, with something a machine can read?

So six seconds. Deliberate. Bounded. Repeatable. The same probe, run twice in a row, has to return the same answer. That's the whole point of feeding this endpoint reachability check into a deterministic score. If the probe is racy, the score is racy, and you've broken the contract we make with every caller: same inputs, same number.

The probe also has to be cheap. EVIDIQ charges per verify_agent call, settled in USDT0 on X Layer via x402. If probing took thirty seconds and twenty outbound requests, the economics stop making sense for the caller and for us. Six seconds is where the cost stays sensible and the signal stays strong. You can read the exact request shape in our EVIDIQ docs if you want to follow the wire.

The Three Things One GET Request Reveals

[IMAGE_PROMPT: A modern flat illustration showing a single magnifying glass hovering over a small server icon, with three output rays labeled TLS, HTTP, and BODY in subtle gray. Clean blue and slate palette with a single green checkmark inside the lens. Developer/tech aesthetic, geometric shapes, subtle grid background, no text, no logos.]

Inside that six-second budget, we're looking for exactly three signals to verify AI agent endpoint reachability. One GET request. Three checks. Here they are:

• TLS presence. Does the URL answer on https:// with a valid, non-expired certificate chain? A fail is a fail. No TLS, no probe pass, no debate. We don't downgrade to plain HTTP because the whole point is to model what an honest, production-grade operator would do. Serve it without TLS and you're telling the score you're not that operator.
• HTTP status. A 2xx in the response window means the endpoint is actually serving traffic. A 401 or 403 is interesting — it means the host is alive but the path is gated. We record that as a partial: reachability is real, but the agent's own discovery surface isn't reachable anonymously, which downgrades the capability signal later. A 5xx or a connection error is a clean miss and the probe returns null for that call.
• Body-content fingerprint. This is the part that earns its keep. We scan the response body for known machine-readable surfaces: an Agent Card JSON object (the name/capabilities/url schema from the open agent card spec), an MCP manifest, or the EVIDIQ skill markdown served at /skill.md. If we find one, we hash it and keep it as evidence. If we find none of the above, the endpoint may be a marketing page. Marketing pages don't get capability credit.

That's the whole probe. Boring on purpose. The discipline is in what we don't add.

A Capability Claim Nobody Checked Is Just a Sentence

Now here's the part the Discord developer had been missing. EVIDIQ's capability score isn't just "what does the agent claim." It's "what does the agent claim and can we confirm at least one piece of it is reachable and structured correctly." The probe is what closes that gap.

To make this concrete, here's roughly how the capability branch behaves after a probe, in priority order:

1. Probe finds a valid Agent Card or MCP manifest at the declared URL. Capability score gets the full weight of the declared list. We treat the manifest as the source of truth.
2. Probe finds a reachable endpoint but the body has no machine-readable surface. Capability score is haircut. We know the operator is alive. We don't know what they actually do. The score for this branch typically lands in the 30–55 range.
3. Probe returns null — endpoint is down, gated forever, or doesn't exist. Capability score drops hard. The agent is now indistinguishable from a string of unsigned text on a webpage. The trust score reflects that.

The point isn't to punish anyone. The point is that an agent's declared capability is one of three pillars inside the formula — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — and an unverified declaration silently collapses to almost nothing. The probe is what keeps that pillar standing. We wrote it that way on purpose. We've seen too many "I can trade any token" claims to treat self-report as evidence.

If you're shipping an agent and you want to be on the right side of this score, the practical advice is short: serve a real Agent Card, sit on TLS, keep the response under six seconds. The EVIDIQ Sentinel docs walk through the exact response shape our probe expects.

What This Probe Deliberately Does Not Do

[IMAGE_PROMPT: A modern flat illustration of a dotted boundary line with a magnifying glass on one side labeled PROBE and three faded question-mark icons on the other side. Minimal flat style, indigo and warm gray palette, subtle grid background, no text, no logos.]

Boundaries matter more than features in trust infrastructure. The probe is intentionally narrow, and we want callers to know exactly where the fence is. Specifically, here's what it does not do:

• It is not a penetration test. We send one GET. We do not probe for SQLi, SSRF, auth bypasses, or any other vulnerability. If you need a security audit, hire one — and don't expect verify_agent to substitute.
• It is not a functional test of the declared capability. We confirm the agent advertises translation across 40 languages. We do not translate anything. An attacker who serves a perfectly structured Agent Card claiming to be a wallet drainer will still pass the probe; the other pillars (identity, reputation, risk) are what should catch that. We surface it in our risk analysis on 0G Compute for that exact reason.
• It is not a guarantee of uptime tomorrow. Reachability is a snapshot. It is not an SLA. A pass today does not entitle you to assume a pass next Tuesday. If you want continuous uptime monitoring, point your own watchdog at the endpoint. EVIDIQ re-probes on every verify_agent call, but those calls are caller-driven, not scheduled by us.
• It is not a regional intelligence export. We don't claim to know what an endpoint does from jurisdictions we can't reach. The probe runs from a small set of well-known egress points and reports what those points observe. If you need country-specific endpoint reachability, that's a different product and we don't sell it.

Honest infrastructure names its limits. If you want the rest of the verification picture — identity anchoring, ERC-8004 ids, ENS resolution, the tamper-evident evidence chain on 0G Storage, and the EIP-191 signature you can independently verify — start with the EVIDIQ Operator docs. The endpoint reachability probe is one input — it's not the whole system.