AI free tiers

Stop free-tier abuse on your AI app without closing the free tier

Every free account on an AI product costs real inference. Credit farmers open account after account from hosting networks and proxy pools, and some come back through a VPN to get round regional limits. FindIP Shield shows the network behind each signup and each use you report, lets you add friction only there, and gives your server a check to run before free credits are handed out. Start by monitoring; the free tier stays open for everyone else.

Monitor my free tier See a farmed free signup

Free Preview · 10,000 events per site per day · No credit card · Terms apply

Hosting / datacenter Proxy VPN Tor Countries in session Malicious IP
The problem

On an AI product, the free tier is the attack surface.

A free plan on a SaaS app costs some storage. A free plan on an AI app costs GPU time on every message. Stripe found that at AI companies more than one in six signups was linked to multi-account abuse, and the cost lands before anyone reaches a payment screen.

The farming is cheap to run: a script, a disposable inbox, and a proxy pool that gives every new account a fresh address. Per-account limits do nothing when the accounts are free, and per-IP limits do nothing when the addresses rotate.

Blocking every VPN is the wrong fix. Developers and privacy-minded users are exactly who signs up for AI tools. What you need is the network context behind each free account, a response that scales with the risk, and a final check on your server where the credits are actually granted.

One event, explained

What one of these looks like in Shield

Every visit and form submit is recorded with a score, the reasons behind it, the session around it, and what the page did. A hosting network or a VPN is used legitimately every day; the reasons are there so you can judge, not a verdict on a person.

A recorded eventSample data

signup_attempt

84 · critical

/signup · a moment ago

Why this risk score
  • hosting_networkThe IP belongs to hosting infrastructure rather than a consumer access network.
  • proxy_detectedThe current IP is a known anonymizing proxy.
  • signup_attemptA sensitive action: the reasons above weigh more here than on a page view.
Session
Network
AS64500 · hosting · United States
Countries in session
2
Time from first page to submit
19 seconds
Plan
free
What happened
Shield recommended
block
A verdict for your site to use. On its own it stops nothing.
Observed in the page
Let through
This site watches only in the page. Its server verified the session before granting the free allowance, received the block recommendation, and gave the account no credits. No inference was spent.
How Shield helps

From the first free signup to a free tier that is not farmed

The expensive moment is the credit grant, not the signup form. Shield puts the network context in front of that moment.

Start by monitoring

Install Shield on the signup and on the page where people use the free tier. Nothing changes for your users. Every signup and every reported use arrives with its score and the network it came from.

Read the reasons

Credit farming runs on hosting networks and rotating proxies, and region dodging shows up as a session seen from more than one country. Shield names each of those as a reason on the event.

Add your own context

Identify the signed-in user (the SDK hashes the ID in the page) with their plan, and report your own api_request event on the generate or send action. You see the network behind each free account's use; linking accounts stays in your system.

Choose a response per form

Keep the free tier open for ordinary visitors and add a Turnstile check or a slow-down on the signup only for the combinations you have seen farming from. Changeable at any time, every outcome logged.

Verify before you grant credits

Before free credits, messages or an API key are handed out, verify the session from your server with your secret key. Block recommendations get no free allowance; unknown is never treated as safe.

What Shield shows you

The evidence, then the response you choose

Which free accounts come from infrastructure

Hosting networks and proxy pools are where credit farming runs. Shield flags them with the reason, alongside VPN, Tor, relay and malicious-IP signals, on every signup attempt.

Sessions that change country

The server check reports when a session was seen from more than one IP address, network or country, with the counts. That is what region dodging through a VPN looks like.

Usage you report, scored the same way

Report your own api_request event on the generate or send action. It arrives with the same score and network reasons, next to the signed-in user's hashed ID and plan.

Setup

Install on your AI app in three steps

The npm package fits a bundled app, the script tag fits everything else. Both report the same events; the verify call is the same from any backend.

Create a Shield site

Sign in, add the domain you control, and pick a privacy mode. You get a public site key; nothing connects until it is on a page.

Add the snippet

Paste one script tag before the closing body tag, or run npm install @findip/shield and call init() with your site key. Auto page and form tracking is on by default.

Watch the first real event

Submit a test on your own form. The event, its risk score and the reasons behind it appear on the site dashboard moments later.

Monitor my free tier Read the quickstart

Prefer another route? Install through Google Tag Manager without touching the bundle.

In your stack

A client component starts the SDK once; the signup handler sends the Shield session ID to a route handler, which verifies it with the secret key before creating the account. The same shape works for SvelteKit form actions and Astro server pages.

// app/shield.tsx  ('use client')
useEffect(() => { init({ siteKey: process.env.NEXT_PUBLIC_FINDIP_SHIELD_SITE_KEY! }); }, []);

// app/signup/signup-form.tsx — send the session with the signup
await fetch('/api/signup', { method: 'POST',
  body: JSON.stringify({ email, findip_session_id: getSession().sessionId }) });

// app/api/signup/route.ts — the decision that counts
const verdict = await verifyShieldSession(body.findip_session_id, 'signup_attempt');
if (verdict.decision === 'reject') return Response.json({ error: 'signup_declined' }, { status: 403 });
// 'review' (monitor, unknown, or no key yet): create the account and flag it for a look
Runnable Next.js example, with lib/shield-verify.ts

Verify first, grant second. The same gate works for message allowances, token credits and free API keys: nothing is handed out on a block, and a session seen from several countries or networks is flagged for a look rather than refused outright.

// browser: say who is signed in (hashed in the page), then report the expensive action
FindIP.identify({ userId: user.id, plan: 'free' });
FindIP.track('api_request', { custom: { action: 'generate' } });

// server: in the handler that grants the free allowance
const verdict = await verifyShieldSession(sessionId, 'signup_attempt');
if (verdict.decision === 'reject') return deny('free_tier_declined');   // no credits, no key
await grantFreeCredits(account, FREE_TIER_CREDITS);
if (verdict.decision === 'review') await flagForReview(account, verdict.reason);
Server verification reference

One POST from your server with the secret key, before the sensitive action. verified tells you the session is real; recommendation is allow, monitor, challenge or block; risk_status unknown means FindIP had no intelligence for that IP, which you treat as monitor, never as safe.

curl -X POST https://shield.findip.net/v1/shield/sessions/verify \
  -H "Authorization: Bearer $FINDIP_SHIELD_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "<from the browser or the findip_session field>", "event": "signup_attempt"}'

# → {"verified": true, "risk_status": "available", "risk_score": 78,
#    "recommendation": "challenge", "challenge_passed": false}
Server verification reference

Before </body> on every page. Auto-tracking reports page views and form submits (shape only, never values); data-session-field adds a hidden findip_session input to your forms so your server can verify the session.

<script
  src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_your_site_key"
  data-auto-track="true"
  data-privacy-mode="balanced"
  data-session-field="true">
</script>
Runnable plain-HTML example
Boundaries

What a risk score is, and what it is not

An assessment, not proof. A VPN, a hosting network or a changing IP is common for privacy-conscious and corporate users too. Shield explains the reasons so you can decide; it does not pass judgement on a person.
Friction, not a security boundary. Anything decided in the browser can be bypassed by someone who controls it. For decisions that matter, verify the session from your server with your secret key.
Unknown is never safe. Where no intelligence was available the status is unknown. Shield fails open: if a decision does not arrive, the form submits as normal.
Questions

Frequently asked

Score, do not hard-block on one signal. Start in monitor only, look at which reasons accompany the farmed accounts on your app, then add a Turnstile check or a slow-down for those combinations and let your server withhold free credits on the block recommendations. A lone VPN signal is usually not enough to act on.

No. Shield never reads form values, prompts or responses. It reports the network and session around an action, and the context you choose to attach: a hashed user ID, the plan, and custom fields you name.

No. Shield reports network signals per session and the hashed user ID you attach. Deciding that two accounts belong to one person stays in your system, where you have the usage and billing context to do it well.

Yes, anyone who controls the browser can bypass anything decided there, and API clients never load a page at all. That is why the free allowance is granted on your server: verify the session with your secret key first, and treat an unknown status as monitor, never as safe.

10,000 events per site per day, no credit card. Beyond the quota events are refused with a 429 and shown as refused; they are never silently dropped as safe. On a busy app, report api_request on the actions that cost you most rather than on every call.
Keep reading

Related

Stop Free Trial Abuse Before the Account Exists Stop Fake Signups Without Blocking Real Users VPN and Proxy Signup Detection for Websites FindIP Shield overview Guide: visitor risk scoring for signup and checkout

Start by watching one real flow.

Create a free Shield site, install it, and look at the first real event before you decide on any response.

Monitor my free tier

Next: create a free Shield site, install it on the signup, and see the first real event. Add the server check before the credit grant when you are ready; nothing is blocked until you choose.

Free Preview · Informational risk signals · You control enforcement