Auth and Rate Limiting for AI SaaS
In traditional SaaS, attackers want your data. In AI SaaS, they want your API credits. The threat model is different — and so is the architecture. Here are the four auth mistakes that cost money, the gate sequence that stops them, and a token-aware rate limiter you can drop in today.
The Threat Model Changed. Most Developers Did Not Notice.
In traditional SaaS, the security threat is access to your data. Attackers want to read your users' records, extract your database, or abuse privileged API routes. Your auth model is designed around preventing unauthorized data access.
In AI SaaS, the primary financial threat is different. Attackers do not necessarily want your data — they want to use your API credits for free. An exposed API key or an unauthenticated AI endpoint is a direct line to your provider billing account. There is no audit trail distinguishing your traffic from an attacker's traffic. You get the bill either way.
This changes what you have to defend and when you have to defend it.
The Four Mistakes That Cost Money
Unauthenticated AI endpoints. If an API route calls an LLM without first validating that the caller is an authenticated user, anyone who discovers the endpoint can call it. This includes automated scanners that probe common Next.js and Express route patterns. A single unprotected endpoint is enough.
API key in client-side code. A Next.js environment variable prefixed with NEXT_PUBLIC_ gets bundled into the client. Anyone who opens Chrome DevTools can find it in under three minutes. From there, scripting unlimited calls takes another ten. Multiple developers have reported $10,000+ overnight bills from this single mistake.
No rate limiting. Even authenticated users can abuse an AI endpoint. A user on your free tier who sends 50 requests with 8,000-token conversation histories costs 40x more than a user who sends 50 short messages — but both count as "50 requests" under a request-count rate limiter. Token-based budgets close this gap.
No tier enforcement. Free users should not have access to advanced model endpoints. If your product has both a "basic AI" and a "premium AI" feature, the auth layer must verify subscription tier on every call — not just on login.
The JWT Validation Gate
A JWT (JSON Web Token) is a signed token, issued to the user at login, that proves who the caller is — your server verifies the signature to trust its contents without a database lookup. Every AI request must pass through JWT validation before any AI call is made. Validating the token (what validateJWT() does below) checks the signature and extracts the user_id and plan_tier from it. These are the two pieces of information every subsequent gate needs.
The implementation is the same as any JWT-authenticated route. The difference is discipline: this gate must come before the AI call, not after, and not conditionally. There is no "optional auth" pattern in AI SaaS — the financial risk is too direct.
// This pattern — BEFORE the AI call, always
const token = request.headers.get('Authorization')?.replace('Bearer ', '')
if (!token) return Response.json({ error: 'Unauthorized' }, { status: 401 })
const { userId, planTier } = await validateJWT(token)
The Token-Aware Rate Limiter
Standard rate limiters count requests. AI SaaS needs to count tokens. Two users send the same 50 requests, but one sends 5,000-token histories and the other sends 100-token messages — the first user costs roughly 50x more for an identical request count. A request-count limiter treats them as equals; a token-aware one does not.
The token-aware rate limiter tracks daily tokens_in + tokens_out per user_id against a plan-tier limit. Free tier gets 10,000 tokens/day. Pro tier gets 500,000. The budget resets at midnight.
When a user hits their limit, return a helpful 429 with the reset time and an upgrade prompt. This is your highest-intent upsell moment — the user is actively trying to use the feature and knows exactly what they need.
Three Levels of Rate Limiting
The three tiers protect different attack vectors. IP-level limiting runs before authentication and stops bots from reaching your auth layer. User-level token budgets protect your margin from power users who would otherwise run up costs on a free tier. Plan-level feature gating protects your pricing model — if the advanced model is a Pro feature, every request to that endpoint must verify the user is on Pro.
All three are needed. A system with only user-level limits has no bot protection. A system with only IP limits has no margin protection. Each tier closes a gap the other two leave open.
The BuildChallenge: Token-Aware Rate Limiter
Implement the rate limiter described in this lesson. The interface is a checkAndConsumeTokens function that takes a user_id, their plan tier, and the number of tokens they are requesting. It returns whether the request is allowed, how many tokens remain, and when the budget resets.
Abuse Detection
Beyond rate limiting, watch for these signals in your logs: sudden 10x spike in one user's token usage, requests that consistently hit max_tokens (potential extraction attempts), and requests arriving in burst patterns at unusual hours. These are not proof of abuse — they are signals worth investigating. A per-user daily cost alert at 10x the average catches 90% of real incidents before the month-end bill.
For production auth patterns and the Mission Control security architecture that Knox uses across all connected services, jeremyknox.ai covers the full implementation. The InDecision engine uses this exact three-tier rate limiting stack.