How EVIDIQ Verifies AI Agent Endpoint Reachability in Six Seconds

An agent calls another agent for a translation. The receiving endpoint claims it speaks six languages. The calling agent has no idea whether that claim is real, whether the endpoint is alive, or whether the agent behind it has any identity at all. So it requests a 50 USDC settlement upfront, or it walks away. Both choices are bad, and both happen a million times a day in 2026.

This is the gap EVIDIQ was built to close. Before any agent commits real money or real intent, EVIDIQ issues a small, bounded probe against the agent's declared endpoint and returns a 0–100 trust score plus a recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed. The probe is fast, deterministic, and explainable. It is also — and this matters — honestly bounded. We built it to learn one specific thing, and the rest of this post is about exactly what that thing is.

Six Seconds to Learn Something Real

When EVIDIQ must verify AI agent endpoint reachability, it issues a single bounded HTTP GET against the agent's declared URL with a hard 6-second timeout. The probe checks three signals: TLS validity, HTTP status class, and whether the body contains a skill, agent-card, or MCP fingerprint. A pass contributes to capability and reputation; a fail is recorded as evidence.

That 6-second budget is deliberate. It's not a limitation we apologise for — it's a constraint we designed around. We're not trying to chat with the agent, run a function call against it, or stress-test its logic. We're trying to answer one bounded question: right now, on this network, is this endpoint reachable, served over a valid TLS certificate, and advertising a machine-readable interface? If the answer is yes, we have signal. If the answer is no, we have a different, equally useful signal. Either way, the call returns inside the budget, the caller can move on, and the report is signed and anchored for audit.

We picked 6 seconds because it's long enough to absorb a TLS handshake, TCP retransmits, and a slow cold start on a serverless endpoint, and short enough that a batch of EVIDIQ verifications remains cheap and parallelisable. Anything slower and you're back in the world of "is this thing up?" services that nobody trusts. Anything faster and you start losing real agents to heuristic noise.

Here's the thing: most trust systems in the agent economy in 2026 don't probe at all. They check a wallet balance, count followers, or read a bio. A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes. The probe is the difference between this agent says it does X and this agent says it does X, and at the moment of verification, the endpoint backed that claim up with a live, signed surface.

The Three Things One GET Request Reveals

The probe is one HTTP GET. That's it. No retries, no POST, no websocket handshake, no clever protocol negotiation. From that single call, we extract three independent signals and feed them into the capability and reputation components of the trust score.

1. TLS validity. The probe verifies the server presents a valid, non-expired certificate chain for the domain it claims to serve. A self-signed cert, a cert for the wrong hostname, or a cert that expired yesterday all fail this check. Why care? Because a self-hosted endpoint that the agent operator claims is theirs but the certificate chain attributes to someone else is a classic impersonation pattern. TLS isn't a security guarantee, but the absence of it is a strong negative signal.

2. HTTP status class. A 2xx counts as reachable. A 3xx counts as reachable only if the redirect chain resolves within the budget and the final destination still passes the TLS check. Anything else — 4xx, 5xx, connection reset, timeout — fails. Notice the granularity: we don't just binary-class "alive or dead". We distinguish between a deliberately-locked endpoint (401, 403) and a broken one (502, 503). The first is often fine (the agent may require auth); the second is a red flag.

3. Body-content scan for a machine-readable surface. This is the most interesting check. The probe reads the response body — within a small byte budget — and looks for known fingerprints: an agent-card JSON block, an MCP manifest, an evidiq_skill.md reference, an A2A discovery document, or any other recognised skill/agent-card/MCP surface. If the agent declares "I serve an MCP interface" and the response body contains an MCP manifest, the capability score for that declared capability gets a meaningful boost. If the agent declares the same capability and the body is a generic marketing landing page, the capability score gets capped.

The math is simple: each of the three signals contributes independently to the capability component (0–100) and, in the case of the fingerprint match, to the reputation component as well. Identity and risk stay unchanged by the probe. Same inputs always produce the same score — the formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2, fully auditable in the EVIDIQ docs.

In practice, we see roughly four outcomes from this probe:

• All three pass. Endpoint is real, live, and advertising a machine-readable interface. Highest confidence band.
• TLS + status pass, no fingerprint. Endpoint is live but doesn't expose a structured surface. Most legacy HTTP services land here. Capability score is capped unless the declaration is content-light.
• Status pass, TLS fails. Unusual. Often a misconfigured self-host. Treated as a caution signal.
• Status fails. Endpoint is down, slow, or blocked. Recorded as a fail in the report; the agent can re-verify later.

The whole sequence — TLS check, status read, body scan — completes inside the 6-second budget. The caller never blocks on it.

A Capability Claim Nobody Checked Is Just a Sentence

Picture this: an agent publishes a registry entry that says "supports translation: en, fr, de, es, ja, zh". It links to an endpoint. Someone pays it. The translation comes back wrong, or doesn't come back at all. The payer loses the escrow, the translator keeps the reputation bump on the registry, and the next agent in line has no way to know.

We've watched this loop repeat. We built the probe to break it. Every time EVIDIQ runs to verify AI agent endpoint reachability, this is exactly the gap it's trying to close.

When an agent declares a capability in its registry entry, EVIDIQ's capability score starts at a baseline. The probe then either raises or caps that score depending on what the endpoint actually serves. An agent that declares "translation" and serves an MCP manifest with a translate tool listed gets a strong capability rating for that declared capability. An agent that declares "translation" and serves a blank 404 page gets a low capability rating regardless of what the registry says. The endpoint is the ground truth, not the claim.

This is also why the probe is integrated into the same evidence bundle that the EVIDIQ Notary anchors on 0G Storage — because a capability score that is detached from the probe evidence is just opinion. At verification time, anyone can re-fetch the response body, re-hash it, recompute the score, and recover the EVIDIQ signer from the EIP-191 signature. The verdict is auditable, not a black box.

Honest take: the probe only tells you about the capability at the moment of probe. An agent can rotate its endpoint, take it down, or serve a different surface an hour later. That's why we ship the probe, the score, and the timestamp together — and why EVIDIQ Sentinel is the right tool if you want ongoing monitoring rather than a single point-in-time check.

What This Probe Deliberately Does Not Do

The probe is precise. It is also small. We think it's worth being loud about what it isn't, because over-trust in any single trust signal is how the agent economy ends up building on sand. The probe exists to verify AI agent endpoint reachability, period — and the boundary below is the point.

Concretely, the reachability probe does not:

• Run a penetration test. It does not fuzz inputs, attempt auth bypass, or probe for known CVEs. The TLS check is a chain validity check, not a vulnerability scan.
• Functionally test the declared capability. The probe confirms the endpoint advertises a machine-readable surface. It does not call the declared function with sample inputs and check the output. An agent that declares translation and serves a translation tool manifest still needs a real functional test by the caller before money changes hands.
• Guarantee uptime tomorrow. A passing probe at 14:03 UTC tells you the endpoint was live at 14:03 UTC. It does not promise the endpoint will be live at 14:04, and it does not promise the agent behind it will continue to back its claims. That's what EVIDIQ Operator is for — continuous observation across many endpoints over time.
• Judge the correctness of the agent's behaviour. Even a passing probe doesn't tell you that the agent will do the right thing in a multi-step negotiation. That lives in the risk component, which is fed by other signals, not the probe.
• Replace legal or regulatory assurance. EVIDIQ does not certify AML, KYC, or EU AI Act compliance. None of that is a shipped feature in 2026; it lives on the roadmap. Don't build a regulated workflow on a probe result alone.

The boundary is the point. A trust layer that claims to do everything ends up doing nothing verifiably. A trust layer that claims to do one small thing well, and is honest about the rest, is what an agent economy can actually build on.