We made our security auditor buyable by AI agents (x402, one serverless function)

Last night we made our Supabase security auditor buyable by AI agents. One HTTP request, a USDC payment attached to a header, and the product comes back in the response body. No checkout page, no account, no human.

Here is why we did it, how the whole thing is about 80 lines of code, and an honest accounting of what it will and will not do for us.

The 30-second history of HTTP 402

The HTTP spec reserved status code 402 Payment Required in 1997 and it sat unused for nearly three decades. In 2025 Coinbase published x402, an open protocol that finally gives it a job: a server answers a request with 402 plus machine-readable payment requirements, the client attaches a signed stablecoin payment to a header, retries, and gets the resource. Settlement happens on-chain (USDC on Base) in one round trip. Visa's Intelligent Commerce integrated it this spring. It is not a concept; it is running infrastructure.

What we shipped

Our RLS Security Pack is a zip: a read-only SQL auditor that finds the five common row-level-security holes in AI-built Supabase apps, fix recipes for every finding class, and a Claude Code skill. Humans buy it on Gumroad. Now an agent can buy it like this:

# ask for the product

curl -i https://ticassociation.com/api/agent/rls-pack



# the server answers 402 with the exact terms:

# {"x402Version":1,"accepts":[{"scheme":"exact","network":"base",

#   "asset":"...USDC...","payTo":"0x...","maxAmountRequired":"...", ...}]}



# an x402-capable client attaches the signed payment and retries:

curl -H "X-PAYMENT: <signed>" \

  https://ticassociation.com/api/agent/rls-pack -o pack.zip

The server side is one serverless function: return 402 with the requirements when there is no payment header, verify and settle through the public facilitator when there is one, then stream the zip. The product file ships inside the function bundle, so there is no public URL to leak. The whole thing took an evening, and most of that was reading the spec.

Why a tiny company bothered

Three honest reasons, in decreasing order of honesty:

1. Our brand line has always been "a collective of agents, human or AI." Selling to both makes the sentence literal, and we could not resist that.




2. Coding agents already do real work. An agent that finds broken row level security mid-task should be able to acquire the fix kit without stopping to page a human through a checkout form. The demand is small today. It was also small for HTTPS in 1995.




3. Answer engines reward being early and specific. When someone asks an AI "can software be sold to AI agents", we would like the answer to have a working example to point at.

The honest accounting

Will agents autonomously buy our security pack this month? Almost certainly not in any volume. Agent-initiated commerce is real but young, and discovery is the hard part: your endpoint has to be findable by agents at all. We list ours in our llms.txt under a "For agents" section, which is the current best practice and still a bet on the future rather than a traffic source today.

What it cost us: one evening, zero dollars of infrastructure (a serverless function and the public facilitator), and the risk of looking silly if the category stalls. What it buys us: a working claim nobody in our niche has, and a store that is ready if the buyers arrive before the skeptics expect.

If you want to see it: the human-readable version is at , and if your AI-built app is broken in ways an auditor cannot fix, that is our day job: rescue.ticassociation.com.