Signup abuse protection for AI products
Stop fake signups from burning your AI credits.
Abusers make dozens of accounts with throwaway emails, Gmail tricks and VPNs to farm your free tier. BurnGuard checks each signup in one API call and tells you to allow, limit, review or block, with the reasons.
No credit card. Starts in monitor mode, so it can’t block a real user until you say so.
The problem
Free credits attract farmers.
On a normal SaaS, a fake account is a row in your database. On an AI product, it’s GPU time you pay for. Credit farmers have it down to a routine: a disposable inbox, a +tag on a Gmail address, a fresh VPN exit, a script. Repeat until your free tier is gone.
CAPTCHAs slow down your real users more than the scripts. Homemade blocklists go stale in a month.
How it works
Three steps. About five minutes.
Add the snippet
One script tag on your signup page creates a device token. No cookies, no cross-site tracking.
Call /v1/check at signup
Send the email, IP and device token from your backend. Get a decision, a score and reasons back in milliseconds.
Decide what happens
Grant fewer credits, ask for a card, or block. Your product, your rules.
Try it
Test a signup right now.
Paste an email (and optionally an IP). You’ll get the same email and network signals the API uses: disposable domains, alias tricks, missing mail servers, datacenter, VPN and Tor traffic.
The full API adds device reuse, velocity and clustering across your own signups, which need your traffic to work.
Credit gating
Give away free AI credits without getting farmed.
Blocking is blunt. Most suspicious signups are better handled with a limit: let the account in, but hold back most of the free credits until it verifies a card or a phone, or simply ages a few days.
allow: grant the full free tier.limit: grant a fraction (recommended_credit_fraction) and unlock the rest later.review: require extra verification before any credits.block: refuse the signup.
Stripe Radar’s trial-abuse control only sees trials that collect a payment method. Free credits with no card are exactly where farming happens. Stripe docs
Default thresholds. Tune them per project.
The API
One call. Readable answers.
Every decision comes with reasons you can read, not a black-box score. Wrap it in a short timeout and default to allow, so an outage on our side never blocks your signups.
const res = await fetch("https://burnguard.daniellasek.com/v1/check", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.BURNGUARD_SECRET_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
event: "signup",
email: "j.o.h.n+42@gmail.com",
ip: req.ip,
device_token: req.body.bg_device,
}),
signal: AbortSignal.timeout(1500), // fail open
});
const { decision, recommended_credit_fraction, reasons } = await res.json();
// decision: "limit" recommended_credit_fraction: 0.1
// reasons: plus_or_dot_alias, normalized_email_reuse (6 accounts), datacenter_ipWhat it catches
The farmer’s toolkit, covered.
Disposable domains
Thousands of throwaway inbox providers, plus domains that can’t receive mail at all.
Alias tricks
j.o.h.n+7@gmail.com and john@googlemail.com are the same inbox. We treat them that way.
Device reuse
The same browser creating its 12th account gets noticed, even with a new email every time.
VPN, datacenter, Tor
Real users rarely sign up from a cloud server. Scripts usually do.
Signup bursts
Twenty signups a minute from one subnet is a script, not a launch-day spike.
Clusters
See every account linked by device, IP or normalized email on one screen.
Monitor mode
Watch first. Block when you’re sure.
Every new project starts in monitor mode. BurnGuard scores every signup but always returns allow, so nothing changes for your users. After a week, look at what it would have done. When the results look right, switch to enforce. Mark any mistake as legit and that user is allowlisted.
Dollars, not just scores
See what abuse would have cost you.
Set your cost per free account, or report usage through the API, and BurnGuard shows the credits burned by flagged accounts and the dollars saved. It’s a number you can show your cofounder.
For growth teams
Fake signups break more than your bill.
Bot signups fire your ad conversion events, so your ad platforms learn to find more bots. They inflate activation metrics, fill your CRM with junk and send your emails to inboxes that bounce or never open, which hurts deliverability. G2 One founder watched bots flood their own anti-bot startup with 55,000 fake signups and a bounce storm. HN
Check your signup list for disposable emails →Clean signups fix all of it at once
- Ad platforms optimize on real people
- Activation and conversion metrics you can trust
- Lower bounce rate, healthier sender reputation
- A CRM without
asdf123@mailinator
Pricing
Priced for teams that give credits away.
A check is one call to /v1/check. No overage charges, and going over never blocks your signups.
Early access
Pilot for AI startups
We’re early, and we’d rather build this with you. Get the Growth plan free for 2 months in exchange for one 20-minute feedback call. Ideal if you offer free credits or a self-serve trial and have seen weird signups.
No logos or testimonials here yet. We’d rather earn them.
Questions
Will this block real users?
Not unless you let it. New projects start in monitor mode and always return allow. Every decision shows its reasons, and marking a user as legit allowlists them.
How fast is a check?
Most checks finish within a few milliseconds of server time. The slowest signal, a mail-server (MX) lookup, is cached and has a hard timeout; if it times out we skip it instead of making your signup wait.
What is credit gating?
Instead of blocking a suspicious signup, BurnGuard can return limit with a recommended_credit_fraction (for example 0.1). You let the account in but hold back most free credits until it verifies a card, a phone or simply ages. Real users barely notice; farmers lose the payoff.
What do you collect from my users' browsers?
The snippet hashes a few stable browser properties (such as screen size, timezone and graphics renderer) into an opaque device token. It sets no cookies and does no cross-site tracking. We never see the raw values.
Is it GDPR-friendly?
You are the controller and we are the processor. Fraud prevention is a recognised legitimate interest under GDPR. Raw check data is kept only for your plan’s history window (7–90 days), then deleted. A DPA summary is published; our legal pages are templates pending legal review, and we say so.
What happens if I go over my monthly checks?
Your signups never break because of our quota. Over the limit, the API keeps answering allow with quota_exceeded: true, and we email you to upgrade.
Can’t I just build this myself?
You can, and our guides show how. Teams usually come to us when their homemade blocklist goes stale, or when they want device reuse, clustering and the dollars-saved number without maintaining them.
Does it replace a CAPTCHA?
It does a different job. A CAPTCHA asks every user to prove they are human. BurnGuard checks quietly and lets you add friction only to risky signups, like requiring a card or granting fewer free credits.
What if BurnGuard is down?
Wrap the call in a short timeout and default to allow. Every example in our docs uses this fail-open pattern, so an outage can never block your signups.
Does it work with Supabase, Clerk, Better Auth or Next.js?
Yes. BurnGuard is auth-agnostic: one HTTP call from your backend. The docs include copy-paste recipes for Next.js route handlers, Express, Supabase Auth hooks, Better Auth and Clerk webhooks.
Who is behind this?
A small independent team, currently in early access. Email hello@northlogic.co and a founder will answer.
Find out how many of your signups are fake.
Install in monitor mode today. Look at the numbers in a week.