Verify AI Agent Endpoint Reachability: What EVIDIQ's Probe Actually Checks

Six Seconds to Learn Something Real

An endpoint reachability probe is a bounded HTTP check that determines whether an AI agent's declared URL is actually live, presents valid TLS, and exposes a machine-readable interface. EVIDIQ runs this probe in roughly six seconds to verify AI agent endpoint reachability as one input to its deterministic 0–100 trust score.

The probe itself is a deliberately small thing. One outbound HTTPS GET, a hard six-second timeout, and three observations written to a small report. Nothing more, nothing fancier. And honestly? That's the point.

When we built EVIDIQ, we had to pick a probe that survived two contradictory pressures. On one side, you want deep evidence — fuzzing endpoints, exercising declared tools, replaying transactions, scanning for known CVEs. On the other side, you need a probe that runs cheaply enough to be invoked on demand, and quickly enough that a calling agent doesn't time out waiting on you while it tries to decide whether to trust a counterparty.

Here's the math: a single x402-paid verify_agent call has to come back with a verdict the caller can actually use to make a downstream decision. If our probe takes thirty seconds, the caller's UX collapses. If our probe takes ten milliseconds, it's worthless. Six seconds sits in the pocket — long enough to do TLS, DNS, and a body fetch; short enough that a paid call feels responsive.

The budget is also explicit. We document it in the EVIDIQ docs and we tell callers exactly what we'll do inside that window. There are no surprise side-channel scans, no recursive crawls, no second-derivative authentication handshakes. You get what fits in the time we agreed to spend, and we publish that contract up front so nobody has to guess.

The Three Things One GET Request Reveals

Inside those six seconds, our probe surfaces exactly three signals. We picked them because they're the cheapest pieces of evidence that meaningfully separate "real endpoint" from "vapor":

• TLS handshake completed. If the agent's URL is https://..., we expect a valid certificate chain, a hostname match, and a non-expired cert. A self-signed cert, a name mismatch, or a handshake that times out at the three-second mark all flip this to fail. The endpoint might still serve traffic in some browser, but it's not what your agent should be trusting without a closer look from a human.
• HTTP status is in the 2xx range. A 200 OK on the advertised path is a pass. 301/302 redirects count, but only if the redirect target also 200s within the budget. 403, 404, 500, or — and we've seen this — a 200 OK that returns a Cloudflare interstitial HTML body all count as a fail. The point isn't to be polite about it; the point is to flag endpoints that aren't actually serving the agent surface they claimed.
• Body content matches a known agent fingerprint. This is the cheap but high-yield check. We scan the response body for markers of a real agent surface: an /.well-known/agent.json or agent-card.json, an MCP manifest, a skill manifest in the format defined at evidiq.dev/skill.md, or a known x402 payment-required header on a discoverable path. A naked HTML homepage is not an agent endpoint. We flag it accordingly.

What does a pass actually look like? A 200 with a valid JSON body containing "capabilities": ["translation", "summarization"] and an MCP tools array. That's a real machine-readable surface and the probe lights up green on all three signals.

What does a fail look like? A 200 from a marketing site, a 403 from an auth-walled endpoint that can't be probed anonymously, or a TLS handshake that dies on certificate validation. All three are common. None of them mean the agent is malicious — they just mean the probe couldn't verify AI agent endpoint reachability, and EVIDIQ will report that honestly in the trust report so the caller can decide what to do next.

A Capability Claim Nobody Checked Is Just a Sentence

Here's a sentence: "This agent translates English to Japanese." Every agent registry in 2026 is full of these sentences. They're cheap to write and they're cheap to lie about. A capability claim with no evidence behind it is just text floating in a JSON field.

What EVIDIQ's probe does is convert that sentence into something testable. When an agent declares capabilities — through the skill manifest, the agent card, or however its surface exposes them — we record those declarations. Then the probe checks whether the endpoint is even alive, let alone capable. The capability score is then weighted by the result. Same inputs, same number. That's the deterministic part of the design.

Concretely, here's how the probe result moves the capability sub-score, which is itself a 0–100 input to the overall trust score:

1. Endpoint live + valid body fingerprint → declared capabilities accepted at face value (capped at 85). The probe can't prove the agent can actually translate, but it proves the agent is up, presenting TLS, and serving a real surface. That's enough to give the declarations meaningful weight, but never enough to max out the sub-score. The remaining 15 points are reserved for evidence we don't have yet, like third-party attestations or on-chain task history.
2. Endpoint live but no machine-readable body → declared capabilities discounted (capped at 40). The URL works, but we couldn't find an agent card, skill manifest, or MCP descriptor. The agent might be brilliant; we just have no machine-checkable way to know. So we heavily discount the capability claim rather than pretending we verified it.
3. Endpoint unreachable / TLS invalid / wrong status → declared capabilities ignored (cap 0). If the probe cannot verify AI agent endpoint reachability, we don't trust the rest of the surface either. The capability claim is treated as unverified text and contributes nothing to the score.

This matters because the overall trust score is computed as identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. If capability collapses to zero because the endpoint didn't pass, the maximum possible trust score drops to 70. That's the math telling you what we believe: an agent whose surface you can't reach is, by definition, less capable of doing business with.

The reputation sub-score rides on similar logic. Endpoints that actually run a paid x402 service — meaning they returned a 402 Payment Required challenge on a real path — get a small boost for "economic skin in the game." Endpoints that don't serve anything probeable get nothing. See the EVIDIQ Operator docs for the exact weight values and the EVIDIQ main page for the public-facing summary.

What This Probe Deliberately Does Not Do

We get this question a lot, often phrased as an accusation: "So you call that a security check?" Fair. Here's the boundary, stated plainly so nobody over-relies on what we ship in 2026.

The probe is not any of the following:

• Not a penetration test. We don't fuzz inputs. We don't try SQL injection. We don't run directory traversal probes. The single GET request is benign and only touches the advertised path or one we discover from a manifest.
• Not a functional test of declared capabilities. If an agent says "I translate English to Japanese," we do not send it a sentence and check the output. That's a separate problem with separate costs. EVIDIQ tells you the agent exists, is up, and looks like an agent. EVIDIQ does not tell you the agent is good at its job.
• Not a guarantee of uptime tomorrow. Reachability is a point-in-time observation. We snapshot it at probe time, anchor it to the trust report, and move on. The agent could go down an hour later. For liveness guarantees, you need a heartbeat system, which is a different product from a different team.
• Not a substitute for on-chain reputation. A clean probe today tells you nothing about how this agent behaved in the past with other counterparties. That's why the reputation sub-score remains a small slice of the formula and why we treat a full on-chain reputation registry as roadmap work, not a shipped feature.
• Not a regulatory or compliance audit. We do not certify agents under the EU AI Act, AML, or any other framework. Those regimes require legal review, documentation audits, and human sign-off that a probe cannot provide.

Where EVIDIQ does help is at the moment of decision: should I transact with this agent now, or should I require escrow, or should I walk away? The recommendation field on the report — proceed, proceed_with_escrow, caution, do_not_proceed — is exactly what a calling agent needs to make that call without having to interpret the score themselves. The full probe lifecycle and report assembly lives in the EVIDIQ Sentinel docs and the notary anchoring flow is described in the EVIDIQ Notary docs. When the probe is meant to verify AI agent endpoint reachability as one piece of a larger trust decision, those docs are where the rest of the machinery shows up.