Problem
x402 (and AP2) solve authorization and settlement: an agent can pay a resource server with USDC when it hits 402 Payment Required.
They do not answer: is this counterparty legitimate?
Before the first payment (and on every retry), an agent typically has:
- a resource URL
- one or more
payTo addresses
- maybe a merchant name from an AP2 mandate
Nothing in the protocol checks phishing domains, sanctioned / scam payees, mule patterns, or brand impersonation. The facilitator’s job is “don’t steal the funds,” not “is this seller real?”
That gap is where agents get drained or social-engineered — especially on first contact with a newly listed Bazaar endpoint.
What a fix looks like (shape, not a vendor pitch)
An advisory verify-before-pay step between discovery and settle:
- Agent receives
402 / mandate / checkout context
- Calls a trust check on the extracted URL(s) + payee(s)
- Branches on a structured verdict (
allow / warn / block) + one plain-language reason
- Only then signs / retries payment
complementary to settlement-attestation tools (e.g. TrustBench receipts that prove payment happened): one attests verification before, the other attests settlement after.
Why this belongs on the ecosystem list
Builders browsing this README already see KYB/data APIs (e.g. Strale) and settlement audit layers. The missing middle is a verdict-shaped, agent-callable gate at payment time — MCP + REST — without putting Faro (or anyone) in the custody path.
Happy to refine wording or point at an open recipe (verify_before_pay for x402/AP2/ACP) if useful for the list.
Problem
x402 (and AP2) solve authorization and settlement: an agent can pay a resource server with USDC when it hits
402 Payment Required.They do not answer: is this counterparty legitimate?
Before the first payment (and on every retry), an agent typically has:
payToaddressesNothing in the protocol checks phishing domains, sanctioned / scam payees, mule patterns, or brand impersonation. The facilitator’s job is “don’t steal the funds,” not “is this seller real?”
That gap is where agents get drained or social-engineered — especially on first contact with a newly listed Bazaar endpoint.
What a fix looks like (shape, not a vendor pitch)
An advisory verify-before-pay step between discovery and settle:
402/ mandate / checkout contextallow/warn/block) + one plain-language reasoncomplementary to settlement-attestation tools (e.g. TrustBench receipts that prove payment happened): one attests verification before, the other attests settlement after.
Why this belongs on the ecosystem list
Builders browsing this README already see KYB/data APIs (e.g. Strale) and settlement audit layers. The missing middle is a verdict-shaped, agent-callable gate at payment time — MCP + REST — without putting Faro (or anyone) in the custody path.
Happy to refine wording or point at an open recipe (
verify_before_payfor x402/AP2/ACP) if useful for the list.