An IP address can tell you who runs the network

A request hits your signup route. The user agent looks ordinary, but the traffic arrives in sharp bursts from an address owned by a large hosting network. Is it a person, an agent, or a browser running inside a cloud machine?

WebProbe's ip-asn endpoint gives you a useful first signal.

Send an IPv4 or IPv6 address and get its Autonomous System Number, network organization, and approximate location. The call costs $0.001 in USDC over x402 on Base mainnet. 

POST https://x402.agentutility.ai/ip-asn
Content-Type: application/json

{
  "ip": "8.8.8.8"
}

A successful response has this shape: 

{
  "ip": "8.8.8.8",
  "asn": 15169,
  "asn_org": "Google LLC",
  "country_code": "US",
  "country": "United States",
  "region": "California",
  "city": "Mountain View",
  "postal": "94043",
  "latitude": 37.4056,
  "longitude": -122.0775,
  "timezone": "America/Los_Angeles"
}

The endpoint accepts one field, ip. Invalid addresses get a 400 response, so reject malformed forwarded headers before paying for a lookup.

What an ASN signal actually means

An ASN identifies the network announcing an IP prefix. It doesn't identify the person or process behind a request, and ip-asn doesn't return a magic is_vpn flag.

That distinction matters.

Traffic from a residential access network usually points toward a household or mobile connection. Traffic from a hosting network is more likely to come from a server, CI runner, proxy, hosted browser, or agent runtime. But people use cloud desktops, and agents can run from home connections.

So treat ASN data as evidence, not a verdict.

Useful patterns include repeated signups from one hosting ASN, rapid account creation spread across nearby addresses, the same credential jumping between network owners, and traffic moving across countries faster than a person could travel.

Location fields are approximate. Don't turn a city value into a claim about someone's physical position.

Add the signal at your trusted edge

Take the client IP from the connection metadata supplied by your trusted load balancer or edge service. Don't accept an arbitrary X-Forwarded-For value from the public internet. A caller can write that header themselves.

Then compare the returned ASN with your own watchlist: 

const lookup = await paidPost(
  "https://x402.agentutility.ai/ip-asn",
  { ip: requestIp }
);

const watchedAsns = new Set([64500, 64501]);
const networkFlag = watchedAsns.has(lookup.asn);

const likelyAgentTraffic =
  networkFlag &&
  (looksAutomated(request.headers.get("user-agent")) ||
    requestsLastMinute > 30);

Your watchlist should come from traffic you've reviewed. Store the ASN number beside the organization name, since names can vary while numeric identifiers are easier to compare.

Look for combinations. A watched ASN plus an automation-shaped user agent is stronger than either signal alone. The same applies to a watched ASN paired with an account-creation burst.

Surface the result instead of silently blocking

Hard blocks create painful false positives. Start by attaching a reason code to the request record: 

{
  "agent_infra_signal": true,
  "reason": "watched_asn_and_automated_user_agent",
  "asn": 64500,
  "asn_org": "Example Hosting Network"
}

That field can route the request into a tighter rate limit, require extra verification, or inform a fraud-review queue. It can also be returned to an agent-facing client as a clear policy result.

At $0.001 per lookup, checking 1,000 request IPs costs $1. Cache results by IP with an expiry that matches your risk tolerance. ASN assignments can change, so permanent caching will eventually lie.

And don't spend the call on every asset request. Check the moments that matter: signup, payment setup, credential creation, or a sudden usage spike.