Picture this: your autonomous agent is about to send real value to another agent it has never met. The counterparty's profile says it can do translations, summarize contracts, route payments. The claims look fine on the surface. The question that actually matters — "is this thing alive, hosted on a real domain, and speaking the protocol we both agreed on?" — has never been asked. Until now.
In 2026, the autonomous agent economy is no longer a thought experiment. It is a marketplace with paying counterparties, signed receipts, and disputes when things go wrong. The hardest part is not authoring agents. It is figuring out which ones are real before you hand them a task. That's exactly the gap EVIDIQ was built to close, and the verify AI agent endpoint reachability probe is the part of EVIDIQ that catches the most obvious lies first.
Six Seconds to Learn Something Real
An endpoint reachability probe is a bounded live HTTP check that confirms an AI agent's endpoint is reachable, TLS-served, and exposes a machine-readable capability surface — completing in about six seconds. EVIDIQ uses this probe as one input into its deterministic 0-100 trust score. It deliberately avoids heavy functional testing; it answers reachability and surface, not full behavioral claims.
Why six seconds? Not because we couldn't run longer — we've done it in production. Six is the budget where reachability, a TLS handshake, and a body fingerprint can all be observed on a healthy endpoint, and where a broken one fails fast enough to keep a calling agent's decision loop moving. Stretch the timeout and you trade latency for marginal signal. We chose not to.
Worth noting: the budget is not a single number thrown at every URL. EVIDIQ's probe adapts per transport. A pure HTTPS endpoint gets the standard 6s for TLS, headers, and body. Endpoints reachable through an MCP-style JSON-RPC handshake get a slightly different envelope because the first message must round-trip before we can read a body. Same hard ceiling, different choreography inside it.
In practice, that boundary does real work. A caller running EVIDIQ in front of an action wants an answer before its own timeout expires — typically 10 to 30 seconds total in a multi-agent pipeline. Spending six of those on a single reachability check leaves room for retries, scoring, and the actual transaction. The math is simple.
The Three Things One GET Request Reveals
A single bounded GET looks unimpressive on paper. It is the cheapest way we have to surface three independent signals from an agent's endpoint. None of them on their own would be conclusive — together they form the floor of what we use to score a claim.
Here is the exact ordering EVIDIQ runs them in:
-
TLS presence. The endpoint must answer over HTTPS. We capture the cert chain, the issuer, and the expiry. A self-signed cert or a cert expiring inside 24 hours is not a hard fail on its own, but it pulls the score down and flags a caution. The check is binary — is the channel encrypted — and it is the first signal we collect.
-
HTTP status. A 200-class response moves us to the body scan. A 3xx we will follow once. A 4xx or 5xx is a hard fail of reachability and the capability score is automatically capped regardless of what was declared.
-
Body-content scan for capability fingerprints. This is where the probe earns its keep. We look for at least one of the well-known machine-readable capability surfaces — a skill manifest at
/.well-known/agent.json, an A2A-style agent card, or an MCP tool listing. If the body matches one of those signatures, the capability claim shifts from "declared" to "supported by surface." If it doesn't, the claim still counts, but it counts less.
A pass on all three looks like this: TLS issued by a real CA, expiring in 90+ days, returning a 200 with a parseable JSON manifest listing the same capability the agent declared on its identity record. A fail on any one of those is interesting; a fail on two is a strong caution signal. Honestly? Three failures in 2026 means the agent is either dead, lying, or pointing at the wrong URL — and EVIDIQ recommends do_not_proceed in all three cases.
A single bounded check will not catch a sophisticated attacker who serves a perfect JSON manifest and then behaves badly when given real work. The probe isn't trying to. It is trying to filter the cheap fakes out of the population so that the more expensive reputation and behavioral signals have something to attach to.
A Capability Claim Nobody Checked Is Just a Sentence
Here is the thing — "supports translation" without a backing endpoint is barely a marketing line. With one, it is a verifiable surface. The difference matters more than it sounds.
EVIDIQ's capability scoring rewards declared capabilities. A clean declaration — "this agent can do X, Y, Z" — starts you at a reasonable baseline. But the curve from there depends almost entirely on whether the live probe confirms a matching surface. We have watched capability scores swing by 25 to 40 points between "declared" and "surface-observed" on otherwise identical identity and reputation inputs. That is not a rounding error. It is the gap that decides whether a calling agent hands the task over, or routes around it.
Concretely, the formula EVIDIQ uses for capability is approximately:
- 0 signals (no declaration, no surface observed) → capability score around 20.
- Declared but not observed (the endpoint is reachable but the body carries no matching manifest) → 30 to 55 depending on TLS and issuer.
- Declared and surface-observed (manifest matches declaration) → 75 to 90.
- Declared, surface-observed, AND the endpoint charges for access via x402 → 90+, because economic skin in the game is real signal.
The last bucket is the one we find most useful when arbitrating between agents that look identical on paper. Two agents both claim translation. One of them serves a free, unauthenticated manifest and the other serves a paid x402 endpoint that returns receipts. Same declared capability, radically different downstream risk. The probe plus the discovery endpoint documented in EVIDIQ docs is what surfaces that gap.
Want to see this yourself? We made the open EVIDIQ Notary docs so you can replay any report. You pull the evidence, hash it locally, and recover the signer from the EVM signature. That round-trip is the part that turns "I just trust the score" into "I can prove the score."
What This Probe Deliberately Does Not Do
A bounded reachability probe is honest about its limits. We are too. Here is what the probe does not do:
- It is not a penetration test. It does not fuzz inputs. It does not probe for known CVEs. A clean pass does not mean the endpoint is unhackable; it means the front door is open and politely signed.
- It is not a functional test. "Supports translation" being backed by a manifest does not mean the translation works. The probe confirms the surface, not the quality of what that surface does.
- It is not a guarantee of uptime tomorrow. An endpoint that answered cleanly at T0 may 503 at T+1. Treat it as a snapshot. If your calling agent will reuse the counterparty across time, layer a freshness check on top.
- It is not a behavioral pass. A well-served endpoint can still be rigged, adversarial, or run by an operator who simply lies after you hand over funds.
The boundary is exactly the point. Tools that promise "full trust" in one shot tend to be either dishonest about what they checked or unscoped about what they ignored. EVIDIQ's job is to produce evidence and a recommendation — proceed, proceed_with_escrow, caution, or do_not_proceed — and leave the choice to you. We never hold funds, we never grant authority, and we deliberately stopped the probe at the edge where "more aggressive" stops being a reachability check and starts being a different product.
If you want stronger coverage than a probe gives, that's the roadmap direction. On-chain reputation ledgers, automated dispute resolution, and regulated-compliance certifications would all extend the boundary, and we talk about these openly in EVIDIQ docs. None of that is shipped today. We will not pretend otherwise.