Six Seconds Is Enough to Verify AI Agent Endpoint Reachability

Six Seconds to Learn Something Real

An endpoint reachability probe is the bounded GET request EVIDIQ issues against an AI agent's declared URL to verify AI agent endpoint reachability in roughly six seconds. It checks TLS presence, returns an HTTP status, and scans the response body for a machine-readable skill, agent-card, or MCP fingerprint.

Six seconds. That's the budget we gave ourselves the first time we sat down to design the live probe that sits inside EVIDIQ's verify_agent call. Engineers love a tight constraint — it forces honesty. You either learn something useful inside the budget, or you admit the budget is wrong. Here's the thing: six seconds is more than enough to learn whether an AI agent's endpoint reachability is real, but it's deliberately not enough to learn everything about it. That second part matters. A lot.

We built EVIDIQ's probe to be boring on purpose. No clever fuzzing, no payload injection, no rate-storming. One GET. That's it. The whole job of the probe is to answer three narrow questions and get out of the way so the rest of the EVIDIQ trust pipeline can do its work — namely, combining identity, capability, reputation, and risk into a deterministic 0–100 trust score with a verdict of proceed, proceed_with_escrow, caution, or do_not_proceed. The probe feeds the capability and risk dimensions; without it, those numbers would be guesses.

If you're new to how the broader product is structured, the EVIDIQ docs are the right starting point. The probe itself lives inside the paid verify_agent MCP tool — it's the part that costs money, because making a real network call costs us money. Everything else (the open skill, the install helpers) is free.

The Three Things One GET Request Reveals

One HTTP GET request sounds laughably small. Honestly? Most of the value of the probe is in the discipline of asking the same three questions every single time. Drift in a probe is how trust systems become unreliable. Here's what we always look at:

• TLS presence and validity. Does the endpoint terminate HTTPS with a non-expired, non-self-signed certificate (where self-signed is a meaningful flag we record but don't auto-fail)? A green padlock in 2026 is table stakes; a missing one is a strong signal of "don't send this agent real work."
• HTTP status family. Anything in the 2xx range is a pass for reachability. 3xx counts as reachable if the redirect chain resolves inside our budget. 4xx and 5xx are explicit fails, and we record the exact code because a 401 versus a 503 means very different things to the calling agent.
• Body-content fingerprint. This is the part most people underestimate. A reachable endpoint that returns nothing a machine can parse is a black box — and a black box doesn't deserve a high capability score. We look for an agent-card.json, a /.well-known/agent document, an MCP tools/list surface, or an SKILL.md-style manifest. Found one? That endpoint just told us, in a way we can verify later, what it's actually willing to do.

A clean endpoint reachability pass across all three is what we call a "clean reachable." A pass on TLS and status but no body fingerprint is a "reachable blind" — we know the server is alive, but we have no evidence it's the agent it claims to be. That's a meaningful downgrade in the capability dimension of the score, and it should be a meaningful downgrade in your own trust decision too. The full mechanics of how this rolls up into a score live in the EVIDIQ Operator docs, which are worth a careful read if you're integrating verify_agent into an agent that pays for services autonomously.

Worth noting: the body scan is a substring and schema check, not a deep semantic parse. If someone returns a JSON file that says {"name": "totally-a-real-agent"}, we'll record it as a fingerprint hit. The probe is not in the business of adjudicating truth from text — that's a separate problem solved upstream by reputation and downstream by your own judgment.

A Capability Claim Nobody Checked Is Just a Sentence

"A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes." We lean on that line a lot internally, and the capability dimension is where it shows up most clearly. An agent can declare anything in its agent-card. It can declare that it translates Japanese, arbitrates disputes, routes shipments, writes Rust, anything. Until somebody checks, the declaration is a sentence in a JSON file.

The probe changes the meaning of that sentence. Here's the practical effect on the trust score, which is deterministic — same inputs, same output, every time:

1. Endpoint unreachable. The capability contribution collapses toward zero for any claim that requires the endpoint to back it up. The agent's declared capabilities are recorded as unverified claims.
2. Reachable but no fingerprint. Same outcome, with the additional note that we couldn't even confirm the surface where the capabilities were declared. The score reflects the gap explicitly.
3. Reachable, fingerprint present, capabilities enumerated. Now we have something real to score against. Each declared capability gets a small bump; capabilities the agent-card does not mention but the fingerprint implies (e.g. an MCP tools/list with ten tools when the card claims three) get flagged for the audit trail.
4. Reachable, fingerprint present, declared capability matches a tool we can call. This is the highest tier. Not because we executed the tool — we did not — but because the surface advertised the capability in a way an honest agent would.

Once you have that ranked list of outcomes, the math is simple: a capability claim with no endpoint reachability backing is roughly a third as valuable in the scoring formula as one with a clean reachable plus a matching fingerprint. We've watched agents try to game this by returning the same canned agent-card on every probe. That pattern is itself a signal we record, and over time — as our reputation layer matures in 2026 and beyond — repeated identical responses will weigh against an agent rather than for it.

If you want to see the exact scoring formula and how the probe result flows into it, the EVIDIQ Sentinel docs cover it from the calling side: what you submit, what you get back, how to interpret the recommendation field, and how to choose between settle-direct, settle-with-escrow, or refuse.

What This Probe Deliberately Does Not Do

Engineers who haven't worked on trust systems before tend to assume "live probe" means something much heavier than what we run. It does not. Here's the boundary, stated clearly so nobody over-relies on it:

• Not a penetration test. We do not send malformed input, attempt auth bypass, or fuzz for SQL injection. The probe is a single polite GET.
• Not a functional test of the declared capability. If an agent claims it can translate Japanese, we do not send it a sentence and grade the output. The probe confirms the surface exists; it does not exercise it.
• Not a guarantee of uptime tomorrow. A green probe at 14:00 UTC tells you nothing about 14:01. We record the timestamp and the TTL we observed; we do not promise persistence.
• Not a substitute for human reputation or dispute resolution. EVIDIQ produces evidence and a recommendation. We never hold funds, never grant authority, and never arbitrate outcomes. The parties choose their own protection.

State the boundary, then state it again. A probe is a snapshot. A snapshot is evidence, not prophecy. If your agent is about to wire real value to another agent based on a single verify_agent call, the recommendation field will tell you whether the situation warrants proceed, proceed_with_escrow, caution, or do_not_proceed — and our strong suggestion is to take "proceed" with the same skepticism you'd take a stranger's business card. The full evidence payload, including the keccak256 hash of the canonical report, the 0G Storage anchor tx, and the EVIDIQ signature, is what makes the result auditable rather than a black box. The verification recipe lives in the EVIDIQ Notary docs.

One more thing for the rest of 2026: a full historical on-chain reputation ledger, automated dispute resolution, and regulatory certifications are all on our roadmap. None of that is shipped today. The probe and the score are. Be honest with yourself about which one you're holding in your hand.