How we check x402
AgentAvow Docs · agentavow.com
An x402 endpoint is a paid HTTP API: an agent calls it, gets a 402 Payment Required with payment terms, pays, and calls again. Before it pays, the agent decides what to call from the endpoint's public listing. We score that listing. We don't see the code behind the endpoint, and every x402 result says so.
What we read
We read Coinbase's public x402 discovery listing (the Bazaar), at https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources. For each listing we read:
- the description;
- the input and output JSON Schemas, with the description of each field;
- the output example;
- the payment terms: network, asset, amount, recipient (
payTo) and the resource being paid for.
Today we send nothing to the listed endpoints. Every result comes from the listing alone. Listings are re-read and re-scored on scheduled runs.
The checks
A listing is the same surface as an MCP tool definition: text an agent reads and acts on. So it gets the same tool-definition checks as an MCP server:
- tool poisoning and hidden instructions;
- encoded instructions;
- exfiltration directives;
- invisible Unicode.
Field descriptions in the output schema are checked at full weight, like input fields. Instructions found only in the output example count one severity step lower, and never critical: an example is what the endpoint says it returns, not a response we saw.
Then the payment terms:
| Check | Severity |
|---|---|
The paid endpoint uses plain http:// (the payment authorization travels in cleartext) | high |
| The payment terms name a different host than the listing | high |
| Two different recipients on one network | medium |
A payTo that isn't a valid address for its network | medium |
| A different recipient on each EVM (or each Solana) network | low |
| The cheapest option costs more than $1 per call | low |
| Settles on a test network only | info |
| Priced in a token we don't recognize | info (the price is shown as "not converted") |
A test-network-only listing can't take real payment, so it is hidden from the default lists. It still shows up when you search for it by name.
What a result means
The answer works as it does for every other tool: a critical or high finding in the listing moves the answer to Review before you connect or Do not connect, and so does a trust score under the review floor; otherwise it reads Safe to connect, with the 0–100 trust score under it.
For an x402 endpoint, Safe to connect means: nothing found in the listing; the endpoint's code isn't visible. It is a statement about the listing an agent reads, not about the service behind it or about what happens when you pay. Medium and low findings lower the trust score and are listed with the result. Read them before an agent pays.
Never Certified, and kept apart
An x402 endpoint is never Certified. Certified needs the code to be read, and here it isn't.
x402 endpoints appear only under their own filter (the x402 endpoints kind in Browse, or surface=x402 on the API). They are never counted in the all-tools lists or in the catalog-wide numbers. A listing-only score is a different kind of evidence from a code scan, and mixing tens of thousands of them in would change what those numbers mean.
Phase 2: reading the 402 response (weekly, not started yet)
Not started yet. The first weekly run starts after this page is published. This page will give the date of the first run when it happens.
Once a week we read each endpoint's own 402 Payment Required response and compare its payment terms with the listing:
- a live
payTothat differs from the listing's on the same network is a high finding,
so the answer becomes Review before you connect. One reading is never enough for Do not connect: it could be a deploy in progress;
- a live price more than 10 times the listing's is a medium finding;
- no
402(a200, a redirect, an error or a timeout) is noted beside the answer and
changes nothing.
What we send, exactly:
- one
GETto the URL exactly as listed, and only to endpoints listed forGETon a mainnet; - no body, no cookies, no authentication, never an
X-PAYMENTorPAYMENT-SIGNATURE
header, and never a payment;
- through our SSRF guard, https only, without following redirects, with a 10-second
timeout and the first 64 KB of the response read;
- at most one request every 2 seconds per host, at most 4 hosts at a time, and at most 50
endpoints per host per weekly run (a host with more is covered over several weeks);
- if a host answers
429or503we wait as itsRetry-Afterasks, and after two of those,
or three timeouts in a row, we leave the host alone until the next run.
User agent
Phase 2 requests identify themselves as:
AgentAvowBot/1.0 (+https://agentavow.com/docs/x402)
Opting out
We read your robots.txt once per run, before any other request to your host. To keep phase 2 requests off your host, or off part of it:
User-agent: AgentAvowBot
Disallow: /
Or email admin@agentavow.com with the host, and we skip it from the next run.
Listing-based scoring uses Coinbase's public listing. If you run an endpoint and want a listing scored again after you change it, or think a finding is wrong, email the same address.
Limits
- We don't see the code behind the endpoint.
- Today we don't see what the endpoint actually returns, only the listing's example.
- We never see what happens after payment.
A Safe to connect answer on an x402 endpoint is about its listing only.
API
x402 rows are in the public catalog under their own surface. No account needed:
GET https://agentavow.com/api/v1/public/scan-catalog?surface=x402
Each row carries the endpoint URL, its trust score, the answer and its reason, the counts by severity (critical, high, medium, low), up to five top findings (top_findings), and the lowest known USD price per call (price_usd). In the summary block, x402_endpoints_total is how many x402 listings were read.
See also: How scoring works and Reading your scan score.
← Back to AgentAvow