What EVIDIQ Checks to Verify AI Agent Endpoint Reachability

Six Seconds to Learn Something Real

An endpoint reachability probe is a bounded GET request that checks whether an agent's server is alive, speaking HTTPS, and serving a machine-readable surface. EVIDIQ runs a verify AI agent endpoint reachability probe inside a strict six-second budget — three signals, one call, no black box. The output feeds our capability score directly.

Six seconds sounds suspiciously like a number we made up to look fast. Here's the thing: the budget is a deliberate engineering constraint, not a limitation we apologize for. We chose it because an agent control plane that blocks for thirty seconds waiting on one bad endpoint is worse than a probe that never ran. Each call costs the calling agent latency too. A bounded timeout keeps EVIDIQ usable as a gate inside an active transaction flow, which is where our users actually run us. The EVIDIQ Operator docs document the exact retry behavior we expect callers to layer on top.

What can you honestly learn in six seconds? More than you think, less than you hope. TLS handshake, status code, and the first chunk of the body. That's it. Those three signals answer the only questions a probabilistic trust score can responsibly lean on: is the host resolvable, is it speaking HTTPS, is it returning something that looks like an agent? Anything beyond that — schema conformance, prompt-injection resistance, semantic quality of the response — costs real time and real money, and we deliberately punt it to layers that can do it properly.

The Three Things One GET Request Reveals

[IMAGE_PROMPT: A clean flat illustration showing a developer laptop on the left sending a single HTTP GET request arrow toward a server node on the right. The server returns three labeled signal bubbles: a green padlock labeled "TLS", a blue status code "200 OK", and a yellow document with a fingerprint icon. The background is soft dark teal with subtle grid lines. No text other than the labels mentioned. Developer/tech aesthetic, minimal, modern.]

One GET, three signals, one score column. We use a numbered mental model so anyone reading a report knows exactly which input moved which number.

1. TLS presence and validity. A pass here means the endpoint terminated the handshake on a certificate that chains to a trusted root, on the standard HTTPS port. A fail can mean self-signed, expired, wrong hostname, plain HTTP on 443, or the connect never finished before the timer ran out. We do not get fancy with CT log checks or revocation lookups inside the probe — that would burn the budget. The EVIDIQ Sentinel docs cover how downstream callers can layer those checks if they want belt-and-braces TLS.
2. HTTP status code. A 2xx, or a 3xx that resolves cleanly inside the budget, scores as reachable. A 401 or 403 still scores as reachable, because authenticated surfaces are valid agents — we just can't peek at the body without creds. A 404, 502, 504, or DNS NXDOMAIN cannot score as reachable, period. Worth noting: a 200 OK on a homepage with no agent fingerprint below does not become reachable.
3. Body-content scan for machine-readable fingerprints. This is the part most builders forget to ask about. We look at the first ~16KB of the response and pattern-match against known shapes: an /.well-known/agent-card.json, an MCP initialize handshake, an Agent Skill SKILL.md, an a2a card. Hit one, and the endpoint earns a non-zero body fingerprint. Miss all of them, and we still record the probe as reachable if TLS and status passed — but the capability score takes a haircut.

A Capability Claim Nobody Checked Is Just a Sentence

Honestly? A declaration field full of capabilities is just text on a JSON document. We've all seen agents that declare translation, summarization, payment routing, and oracle access — and behind that declaration is a Cloudflare 404 page. The capability score in EVIDIQ's formula — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — uses 30% of its weight on capabilities, so we refuse to spend that weight on words alone.

The capability score blends two inputs. First, the declared set on the agent's identity record. Second, what the verify AI agent endpoint reachability probe actually found. Concretely:

• No declaration, no probe hit: low single digits. We have no signal the agent does anything.
• Declaration present, probe hit the right fingerprint: the score climbs into the 60-90 band depending on which fingerprint matched and how fresh the probe is.
• Declaration present, probe missed every fingerprint: score gets pulled down toward the declaration-only baseline, which is intentionally weaker than a verified declaration.
• No declaration, but the endpoint serves an agent-card anyway: we treat that as a soft signal and bump the score modestly — the agent is doing the work of proving it exists.

This is also why we recommend agents run an MCP server or expose an agent-card.json. The math is simple: a fingerprint is worth more than a sentence. Our own EVIDIQ docs describe the capability scoring in detail for anyone integrating us as a gate.

What This Probe Deliberately Does Not Do

[IMAGE_PROMPT: A flat illustration of a clearly drawn boundary wall with a developer on one side pointing toward a server on the other side. The wall has three small red prohibition signs along it, representing things the probe does NOT do: a bug icon, a clock icon (uptime tomorrow), and a magnifying glass with a question mark (functional/penetration test). The background is a calm muted blue. Clean tech aesthetic, no real brand logos.]

Boundaries matter more than features in a trust layer. Here is what the verify AI agent endpoint reachability probe explicitly does not do, even though we get asked about every one of these.

The probe is not a penetration test. We are not fuzzing input, not probing for SSRF, not testing for injection. An agent that passes our probe can still have a terrible security model behind its public surface. Use a real pen tester for security. The probe only confirms the door is open and looks like an agent door.

Functional verification of declared capabilities is also out of scope. If an agent declares "swaps on Uniswap," the probe does not call swapExactTokensForTokens. We do not have permission to do that, and even if we did, you should not want us to. Functional verification belongs at the protocol layer — the swap, the transfer, the model invocation — to whatever the parties themselves sign and settle. EVIDIQ's Notary docs explain how the evidence we produce is meant to slot into that next layer.

Reachability today is not a promise of uptime tomorrow. The probe ran for six seconds at one timestamp. The endpoint could go down an hour later, in five minutes, or right after the report was issued. Our recommendation is to treat any reachability signal as a freshness-bounded indicator. Re-probe. Don't anchor a long-lived decision to a single sample. The short version: a green today is a green today, not a green next week.

Finally, the probe does not adjudicate disputes, settle funds, or hold assets. We never have and never will. We produce a hashed, signed evidence record and let the caller choose its own protection. For most agents that's direct x402 settlement; for higher-stakes flows that's escrow; for genuinely adversarial flows that's a third-party arbiter reading the EVIDIQ report as one input among several.