PAYMENT GUARD

Before your AI agent sends money, ask one question.

Agents are already moving real funds — x402 has pushed $600M+ across ~500k AI wallets (now a Linux Foundation standard backed by Visa, Stripe, Anthropic, Coinbase). The #1 risk: paying a sanctioned or tainted address unknowingly. Payment Guard is the one call an agent makes before a transfer.

FreeDeterministic — no LLMOFAC + scam lists + on-chain + ENSHTTP + MCP

Screen a recipient

verdict appears here…

Try a sanctioned/scam address and it returns block.

The tools

EndpointWhat it does
/api/screen-addressThe guard. Address or ENS name → OFAC-sanctioned? scam/abuse-listed? on-chain risk (brand-new/unused, contract)? → a verdict
/api/screen-paymentVet an x402/payment endpoint or merchant URL (punycode, lookalikes, new domain, redirects)
/api/check-sanctionedFast OFAC sanctions check for an address / ENS name
/api/resolve-nameResolve an ENS name → address and screen it (catch non-resolving names + spoofs)

Use it from an agent (MCP)

{ "mcpServers": { "payment-guard": { "command": "npx", "args": ["-y", "payment-guard-mcp"] } } }

Why it exists

Compliance giants screen sanctions for enterprises — but nobody ships a free, in-loop, agent-native "should I pay this?" guard for the x402/crypto world. The money is flowing now; the guardrail wasn't built. Data is public and read-only: OFAC SDN, ethereum-lists + ScamSniffer, public RPC, ENS. Same input → same output.