You wire an AI agent into a payment flow. It claims it can translate documents, fetch on-chain prices, or notarize evidence. You hand it a job and it 404s. Or worse — it returns a 200 with a marketing page that has nothing behind it.
We built EVIDIQ's probe to fail fast on exactly this. Here's the honest, line-by-line walkthrough of what runs when you call verify_agent, and — more importantly — what we deliberately don't promise.
Six Seconds to Learn Something Real
EVIDIQ's verify AI agent endpoint reachability probe is a bounded ~6-second live check that runs when you call verify_agent. It confirms TLS, captures the HTTP status, and scans the body for a machine-readable surface like a skill file, agent card, or MCP endpoint. A deliberate constraint — enough signal to act on, fast enough to never block a transaction.
Six seconds isn't a budget we picked by accident. A trust check that takes longer than the transaction it gates is, in practice, an unused trust check. If you're paying an agent through x402 and every call drags in a 30-second audit, you'll route around the audit on day one. We've watched this happen with KYC services on web2 rails. So the probe is capped.
What that budget buys you:
- TLS handshake — is the certificate valid, and is the chain trusted by a mainstream CA store? Not a pin, not a custom CA — mainstream. If the agent hands you a self-signed cert, the probe fails that part.
- HTTP status capture — a literal
response.status_code. Anything in the 2xx range is "the host is alive and answering"; anything 4xx/5xx fails this layer. - Body fingerprinting — a regex pass over the first ~64KB of the response looking for a known surface marker.
That's it. No DNS tricks, no uptime sampling over hours, no payload fuzzing. Just three checks, all in one GET. The whole point is that the probe is reproducible: same agent, same inputs, same outputs. We treat the verify AI agent endpoint reachability call as a deterministic primitive, not a heuristic.
If you want to run it yourself before you ever spend a cent, the install path is open at EVIDIQ's Agent Skill and the full probe wiring lives in the EVIDIQ docs.
The Three Things One GET Request Reveals
Once the probe fires, you get back three pieces of evidence. Each one is independently scored — none of them is decorative, and a failure on any one pulls the overall trust score down.
-
TLS layer. This is the cheapest check and the first to fire. The probe resolves the host, completes a handshake, and verifies the chain against the public WebPKI. A green lock is not a guarantee of identity — anyone can get a cert for their own domain — but a missing or expired cert is a strong negative signal. We treat it as such.
-
HTTP layer. A clean 200, 204, or 301 tells you the server is actually answering. 401 and 403 are interesting — the host is alive but it's gating you, which is itself information. The probe records the code verbatim so the EVIDIQ Notary can later attest to the exact response.
-
Body fingerprint layer. Here's where most agents slip. We scan the first chunk of the response for any of these markers:
/.well-known/agent.json/skill.md/mcporMCP-Serverheaders- an
AgentCardJSON-LD block - a
text/x-mcpcontent type
A hit means the operator bothered to publish a machine-readable surface. That's not a feature — it's evidence the agent was built to be invoked by software, not just by humans clicking a landing page.
Here's the thing: a pass on all three doesn't make an agent trustworthy. It makes it reachable, and it makes it self-describing. Those are necessary, not sufficient.
A Capability Claim Nobody Checked Is Just a Sentence
Walk up to any agent registry in 2026 and you'll see claims like:
- "Supports cross-chain swap routing"
- "Multilingual document translation"
- "On-chain reputation lookup"
- "Can co-sign EIP-712 messages"
A claim is a string. A checked claim is a number. The probe is what turns the first into the second.
Inside EVIDIQ's scoring formula, capability is one of four inputs — combined as identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. The capability component has two halves:
- Declared — what the agent or its operator says it can do. Weights lift when the declaration is signed, anchored to an identity, or cross-referenced against the agent's own published skill manifest.
- Probed — what the probe just saw. A reachable endpoint with a real machine-readable surface bumps capability significantly. An endpoint that's reachable but serves nothing machine-readable caps the probe half at a low ceiling.
The split matters. An agent can declare every capability under the sun and still score poorly on capability if its endpoint doesn't back any of it up. Conversely, an agent with modest declared capabilities and a clean, well-formed MCP surface can outscore a louder, sloppier competitor.
This is where the verify AI agent endpoint reachability call earns its weight — it lifts the probed half of capability from "we assume the operator is telling the truth" to "the operator is at least running a real surface."
Our take: a wallet balance alone tells you nothing about intent — that's the gap the probe closes on the capability side. Identity says who you are talking to; capability says what this agent is actually wired to do. The probe is the only mechanism in the score that touches the wire.
What This Probe Deliberately Does Not Do
We get asked about this a lot, so let's be direct.
The probe is not a penetration test. It does not send malformed payloads, test for injection, or attempt to enumerate routes. Anyone who tells you a single GET is "security audit" is selling you something.
It is not a functional test of the declared capability. If an agent claims translation, the probe does not throw a string at it. It verifies that the translation service exists and is reachable. Whether the translations are any good is a separate question, and EVIDIQ does not pretend to answer it from one request.
It is not a guarantee of uptime tomorrow. A green probe at 10:00 UTC says nothing about 14:00 UTC. The score is a snapshot, not an SLA. Repeated probing changes that, but a single call is honest only about the moment it was made.
It is not a content review. We do not fetch the skill file and judge its quality, accuracy, or honesty. We confirm it exists and is parseable. The verifier trusts that humans and downstream agents will read the contents.
It is not an on-chain reputation lookup today. The reputation component of our score is built from identity anchors and live signals — like whether the endpoint runs a paid x402 service, which is "economic skin in the game." A full historical reputation ledger, automated dispute resolution, and regulatory-compliance certifications (EU AI Act / AML) are roadmap work, not shipped features. We won't claim otherwise.
Knowing the boundary is the whole point of the design. A trust score that's honest about its limits is more useful than one that overpromises and quietly underperforms.
For a full picture of what the verifier returns — including how the recommendation field (proceed, proceed_with_escrow, caution, do_not_proceed) is derived from the same inputs — read the EVIDIQ Sentinel docs. If you're wiring EVIDIQ into your own agent stack, the EVIDIQ Operator docs walk through the integration end to end.