AI startups like Cursor face fraud before checkout ever happens: stolen tokens and free-trial abuse. Here's how fraud prevention is adapting.
What is token fraud, and why is it different from payment fraud? #
Token fraud happens when someone steals or abuses access to an AI company’s compute or credits, usually before any payment ever occurs. Instead of stealing money in a transaction, fraudsters spin up accounts, claim free trial credits, or run up usage on inference-heavy products with no intention of paying. Traditional fraud tools are built to score transactions. Token fraud largely happens outside the transaction entirely, which means the old tools miss it.
Why can’t traditional fraud detection catch this? #
Most fraud prevention systems, including Stripe’s own Radar product, were built over the past decade to evaluate individual transactions: is this specific card charge, this specific checkout, likely fraudulent? That model worked well for a world where the biggest risk was a stolen credit card being used to buy something. It doesn’t work for AI companies because the abuse doesn’t cluster around a transaction at all.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
According to Emily France, who leads data and ML infrastructure at Stripe, the company learned this directly from Cursor, the AI coding tool. Cursor came to Stripe and said, in effect, that Radar was excellent but wasn’t solving their actual problem. The issue wasn’t fraudulent charges. It was fraudsters creating accounts to claim free credits, or running up usage and never paying when the bill came due. None of that activity looks like a suspicious transaction, because there often isn’t a transaction to flag. There’s just a signup, a free trial, and a bill that will eventually go unpaid.
Why does this hit AI companies harder than traditional software? #
The economics are the reason. Traditional SaaS products have a marginal cost near zero. If a user signs up for a free trial and never converts, the company loses very little. AI products are different: every query, every generation, every agent action burns real inference costs on GPUs. A free trial or a premium tier isn’t just a marketing expense, it’s a loss leader that only makes sense if the user eventually becomes a paying customer.
That math flips entirely with a bad actor. A legitimate free-trial user is a calculated cost of acquisition. A fraudster running the same free trial at scale, or automating account creation to keep claiming new trials, is pure loss with no upside. Because inference is expensive, that loss adds up fast, and it can happen quietly, without ever triggering a transaction-level fraud score, until a company notices a metric going vertical for no obvious reason.
How is fraud prevention being rebuilt for this problem? #
The shift Stripe made with Cursor, and then extended to other AI companies, was moving from scoring transactions to scoring customers, before they ever become a billing event. Instead of asking “is this charge suspicious,” the system asks “is this account likely to be abusive,” and it asks that at the moment of signup or free-trial activation, not at the moment of payment.
This works because of network effects. Fraudsters rarely target a single company. They run the same playbook across many services at once, testing which ones have weak defenses. A company that only sees its own data can’t easily detect a pattern that only shows up across dozens of platforms. But a payments processor sitting underneath a huge share of the AI economy can see that same bad actor showing up on multiple services and flag them before they do damage anywhere.
Stripe says it processes a significant share of global commerce, and a large majority of companies on lists like the Forbes AI 50 run their payments infrastructure through it. That cross-network visibility is what let the company identify patterns Cursor alone couldn’t see: the same abusive accounts hitting multiple AI products, the same behavioral fingerprints showing up across unrelated services.
What did the fix actually look like in practice? #
Per the account given in the source conversation, Stripe didn’t run a lengthy product development cycle. Engineers embedded directly with Cursor’s team and built a working pipeline, exposed as an API Cursor could call, within days rather than months. The system used existing fraud and abuse signals Stripe had already built for individual consumers over roughly a decade of running Radar, and applied them to a new kind of buyer: not a person swiping a card, but an account trying to claim compute before it ever pays for anything.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Once that pattern was proven with Cursor, it was generalized across the AI companies Stripe works with. Those companies weren’t just using Stripe for payment processing. They were relying on the same infrastructure for billing, tax, revenue recognition, and increasingly for real-time data on who’s paying, who’s churning, who has credit risk, and who’s likely committing fraud, all pulled into their own product decisions.
Is this just a Cursor problem, or is it industry-wide? #
It’s industry-wide, and it’s a structural feature of how AI products are monetized. Any company offering free credits, trial tiers, or usage-based billing on top of expensive inference is exposed to the same dynamic. The more generous the free tier (often necessary to compete for users), the bigger the target for abuse. As agentic tools multiply and more software gets built and shipped through AI-assisted platforms, the number of businesses with this exact vulnerability keeps growing.
There’s a second layer to this too: agents themselves are increasingly acting as buyers, not just as targets of fraud. That raises a parallel trust question, one about whether businesses can trust that an agent buying from them is legitimate, and whether users can trust an agent to spend on their behalf within reasonable limits. Tools like Stripe’s Link, originally built as a consumer payment wallet, are being adapted to serve as identity and spending infrastructure for agents, carrying forward the same trust and abuse signals that were built for human shoppers.
What should AI builders take away from this? #
If you’re building a product with free tiers, trial credits, or usage-based pricing on top of AI inference, transaction-level fraud tools alone won’t protect your margins. The abuse that matters most probably isn’t happening at checkout. It’s happening at signup, at trial activation, and in the gap between when someone starts using your product and when they’re supposed to start paying for it. Detecting that requires visibility into account and usage patterns before money changes hands, not just scrutiny of the payment itself.
Frequently Asked Questions #
What is token fraud in AI products?
It’s the theft or abuse of AI compute credits and access, typically through fake accounts claiming free trials or running up usage with no intention of paying. It happens before or outside the actual payment transaction, which is why standard transaction-based fraud detection often misses it.
Why did Cursor need a different kind of fraud protection?
Cursor found that Stripe’s existing transaction-scoring fraud tool, Radar, wasn’t catching the abuse it was actually facing: fraudsters creating accounts to harvest free credits or running up bills they never intended to pay. That abuse doesn’t show up as a suspicious transaction because there often isn’t a transaction to score.
Why is this more costly for AI companies than traditional software companies?
Traditional software has near-zero marginal cost per user, so an abused free trial is a minor loss. AI products run on expensive inference, so every fraudulent free-trial claim or unpaid usage bill carries a real, often significant, cost tied to GPU compute.
How does cross-network data help catch this kind of fraud?
A payments and infrastructure provider that serves many AI companies can spot the same bad actor or bot pattern appearing across multiple platforms, something a single company monitoring only its own data can’t see. Fraudsters typically target many services with the same playbook, not just one.
Other agents ship a demo. Remy ships an app. #
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Does this problem go away as AI companies mature?
No, it likely grows. As more products adopt usage-based billing and generous free tiers to compete for users, and as agents increasingly act as buyers online, the surface area for pre-transaction abuse expands rather than shrinks.