Should Your AI Agent Pay That Counterparty? A Policy Check Walkthrough

An agent framework deciding whether to let an autonomous agent pay a counterparty needs one thing: a decision, not two separate reports to reconcile. Policy Check combines an ERC-8004 identity/reputation lookup with an x402 payment-challenge validation into a single allow / warn / block call, backed by a transparent, itemized score. This post walks through five real calls against real, currently-registered agents — not hypotheticals — to show exactly what the decision looks like in practice.

The Shape of the Decision, Briefly

Every check produces three things: a categorical decision, a score out of 100 where every point traces back to a named check (never a hidden formula), and a set of hard gates that override the score entirely when something is unambiguously broken — an unregistered identity, or a payment challenge that can't be parsed at all. The full rubric lives on the Policy Check page; this post is about what it actually returns, not a restatement of the feature list.

Example 1: A Clean Allow

Checking agent ID 1 on Base — a real registered agent called "ClawNews," a news-aggregation platform built for AI agents — against a live, valid x402 payment endpoint:

{ "decision": "allow", "score": 95 }

This agent has real weight behind it: 20 distinct clients have left reputation feedback, its metadata resolves and declares itself active, and the payment challenge is clean with no spec-hygiene warnings. Only the endpoint-consistency check (5 of the 100 points) didn't fire, because ClawNews's own metadata doesn't declare a specific x402 endpoint to cross-check against.

Example 2: Allow, But the Score Tells You Something Extra

Agent ID 1 on Base Sepolia is a test registration whose metadata explicitly declares an x402 endpoint (https://example.com/api). Checking it against a different endpoint than the one it declares:

{
  "check": "x402_endpoint_consistency",
  "points": 0,
  "maxPoints": 5,
  "detail": "Agent declares a different x402 endpoint (https://example.com/api) than the one being checked"
}

Overall decision was still allow at a score of 90 — nothing else was wrong — but this is exactly the kind of signal a score-only summary would hide. If you're about to pay an agent at an endpoint it doesn't itself claim to use, that's worth a second look even when everything else checks out.

Example 3: A Warn, Not an Allow or a Block

Agent ID 1 on Arbitrum ("ClawSearch," an agent-native search engine) is real and well-formed. Checking it against a URL that returns a normal 200 response instead of a 402 challenge:

{ "decision": "warn" }

This isn't treated as a failure. A 200 where you expected a payment challenge is genuinely ambiguous — it could mean the resource is free, or it could mean you checked the wrong URL. Policy Check surfaces it rather than guessing, which is the whole point of warn as a distinct category from allow and block.

Example 4: Block — No Identity to Vet

Checking an agent ID that has never been registered:

{ "decision": "block" }

This is one of exactly two conditions that hard-block regardless of score. There's no identity here to attach any trust signal to at all — reputation, metadata, and wallet checks all have nothing to evaluate. No number of points elsewhere could offset that.

Example 5: Block — The Target Is Genuinely Unreachable

The second hard-block condition looks similar from the outside but is a different failure mode: a real registered agent, paired with a payment endpoint that resolves in DNS but never answers the request. Checking a known real domain that's currently unresponsive:

{
  "decision": "block",
  "score": 30,
  "payment": { "status": "no_challenge", "warnings": ["Could not reach the target URL"] }
}

Worth noting how this differs from passing a domain that doesn't resolve at all — that case fails even earlier, at basic URL validation, before Policy Check's scoring logic ever runs, and returns a plain input error rather than a scored decision. This block is specifically for "the URL is valid and the domain exists, but nothing answered" — a state you can only detect by actually trying the request, which is exactly what happened here.

What Five Examples Don't Cover

Reputation in all of these examples is scored on presence and breadth alone — how many distinct clients gave feedback — never the feedback value's magnitude, because ERC-8004 doesn't standardize a value scale across registrations. A warn or even an allow here is a floor, not a ceiling: a low score means "we didn't find much," not "we found something bad." And none of this touches ERC-8004's Validation Registry, since no canonical contract address for it is published yet.

Try It

All five of these are real, reproducible calls — the agents and endpoints above are genuinely registered on their respective networks today. Policy Check is a Pro feature, callable from the dashboard or via the /api/v1/policy-check API for automating the same decision from an agent framework before it authorizes a payment.