What he said
Simon Willison, in a post about an investigation into the market for reselling access to AI language models, explained why the finding changes how he thinks about running his own AI-powered projects publicly: “I’ve been cautious about exposing my own LLM-driven applications publicly out of fear of abuse leading to big token bills. The existence of this marketplace makes me even more cautious: there’s now an entire ecosystem that can profit from finding a new unprotected endpoint to exploit.” (A “token bill” is the invoice an AI vendor sends for the chunks of text, called tokens, that its model reads and writes on your behalf. The more your app is used, including by strangers, the bigger that bill gets.)
His conclusion is a direct ask of the companies that sell AI model access: “LLM vendors really need to get better at offering strict caps for their API keys. I want my LLM apps to stop working the moment they hit a dollar threshold I’ve set for a period of time.”
Who he is
Willison is an independent open source developer. His about page describes him as working full-time building open source tools for data journalism, centered on Datasette, a tool for exploring and publishing datasets, and SQLite, a lightweight database engine. He also created llm, a widely used open source command-line tool for working with AI models, and co-created the Django web framework, a widely used tool for building websites. He writes frequently and specifically about the security risks of building with AI, which is why other builders and researchers treat his commentary on this topic as informed rather than casual.
What he gets right, and where it’s incomplete
The underlying investigation, credited to Matt Lenhard, describes a real and specific mechanism: resellers run proxy servers (middleman software that sits between a buyer and the real AI vendor, using open source tools called one-api and its fork new-api) that pool together AI model access credentials (“API keys,” the passwords an app uses to bill its AI usage to a vendor’s account) obtained through abused free trials, unprotected support chatbots, or stolen payment cards. Buyers then get AI model access at a discount while the original account holder gets billed. Willison is right that this is a structural incentive problem: as long as an unprotected key or exploitable signup flow exists somewhere, someone will find and monetize it, and open source proxy tools make that easy to scale.
Where the framing runs ahead of the evidence: the excerpt Willison shares describes this as “mostly a thing in China,” based on one investigation and one forum thread as the source. That is a specific, credible data point, not a comprehensive count of how large or global this resale economy actually is. Willison’s own post does not claim otherwise, but it is worth being precise that “an ecosystem exists” is well supported here, while “how big it is” is not.
His proposed fix also only addresses part of the problem. A hard dollar cap on a compromised key limits how much damage a victim can suffer after their key leaks. It does nothing to stop the leak itself, whether that is a scraped support bot, an abused free trial, or a stolen card. Spending caps are victim-side damage control, not a fix for the underlying access-control gaps resellers are exploiting.
Why it’s notable
Most builders think about AI API security in terms of rate limits: how many requests per minute a key can make. Willison’s post is a reminder that request-based limits do not protect against a determined reseller pooling many keys, because each individual key can still look like normal usage while the aggregate cost to the victim climbs. A dollar-denominated cap, not just a request-count cap, is a different and more directly useful protection, which is exactly why Willison is asking vendors for it rather than assuming it already exists.
What it means for builders
If you are shipping a product that calls an AI vendor’s API directly from your own account, check today whether that vendor lets you set a hard spending limit for a specific key, not just a soft budget alert email. Alerts tell you about a problem after the vendor has already billed you; a hard cap that disables the key stops the bill from growing further.
If your vendor only offers monitoring or email alerts, treat that as a real gap: build your own automatic cutoff, code that checks recent spending and disables the key once it crosses a threshold you set, rather than assuming the vendor’s dashboard will catch abuse in time. Also audit anything that can leak a key by design, like a support chatbot that echoes configuration data or a free trial flow with no verification, since those are the specific access points the reseller market Willison describes is built to find.
End of article