The Security Pass Every AI-Built SaaS Needs

Why AI-Built Software Ships Fast and Insecure

I build SaaS products with AI assistants, and I build them fast. Concept to working product in days, not months. That speed is real and I won't pretend otherwise. But the same speed that gets a product live also leaves predictable holes, and if you want a secure AI built SaaS, you have to go looking for them on purpose.

Here's the honest version of what's happening under the hood. AI coding assistants optimize for one question: does it work? They do not optimize for a different and harder question: can a stranger drain it? Those are not the same thing. A route that returns the right data when you test it as the logged-in owner can also return data to anyone who guesses the URL. The happy path passes. The attack path was never on the assistant's radar.

After building and operating several SaaS products this way, I see the same four holes show up every time. Routes reachable without a session. No per-object ownership check, which is the IDOR problem. Expensive AI endpoints with no metering. And OAuth callbacks that accept unsigned state. These aren't exotic. They're the same five security holes that show up in every AI-built app, and they're boring precisely because they're so common.

This article is not a breach postmortem. Nothing got drained. This is the deliberate pass I run before a product takes a dollar, because speed has a tax and the tax comes due the moment money is involved.

That's the real fear behind the buyer's question. Is AI-built software a liability? It isn't. Not if security is a gating step instead of an afterthought. The difference between an asset and a lawsuit is whether someone ran this pass first.

The Rule: Security Is a Gate Before Money, Not a Patch After

Let me make the principle explicit, because it's the whole thing.

The Four-Part Security Gate Before Monetization

Before any of my SaaS products took a single dollar, I ran one hardening pass. Not after launch. Not after the first user complained. Before the payment integration went live and real money started moving.

The trigger is not a calendar date. It's not a launch party or a sprint deadline. The trigger is one specific moment: the moment money is about to change hands. That's when the security pass becomes non-negotiable.

Why does that timing matter so much? Because the same bug means two completely different things on either side of a paywall.

A free demo with a hole in it is embarrassing. Someone pokes around, finds something, you fix it, you move on. Annoying, recoverable.

A paid product with the same hole is negligence. Now you've got customers who paid you, trusted you with their data, and you shipped them something a stranger can read. That's a refund queue, a churn spike, and in regulated industries, a reportable incident. The bug didn't change. The stakes did.

So I treat the payment switch as the gate. Nothing monetizes until it clears four checks. Every route sits behind a session. Every object gets an ownership check. Every expensive AI call gets metered. Every OAuth state gets signed and host-validated.

This is repeatable, not heroic. I'm not relying on a flash of genius or a security consultant flying in. I run the same four-part pass on every product I ship, in the same order, every time. It takes a few hours. It's the cheapest insurance in the entire build.

The rest of this article is that checklist.

Gate Every Route Behind a Session

The default AI builds leave open

When an AI assistant scaffolds your backend, it generates routes that read data, write data, and call your billing and AI endpoints. A surprising number of them ship with no session check at all.

I mean that literally. The handler reads a request, does the work, returns the result. It never asks: is this person even logged in? Anyone who knows the URL can hit it.

The example I see most often is an AI generation route. The assistant builds an endpoint that takes a prompt and returns generated output. It works perfectly in testing because you're logged in while you test. But the route itself doesn't require a session. A stranger with the URL gets the same response you do, and they get it on your API bill.

The default for AI-scaffolded routes is open. That's backwards.

How I gate it

The fix is a single guard that runs before every handler. Middleware that rejects any unauthenticated request with a 401 before the route logic ever executes.

Fail Closed vs Fail Open Route Defaults

The critical design choice is that the default is locked. Every route requires a session unless it's explicitly opted out. You don't add auth route by route and hope you didn't miss one. You lock everything, then open the handful of genuinely public routes: login, signup, the marketing pages, password reset. Everything else is closed by default.

This inverts the failure mode. If I forget to configure a route, it fails closed (locked) instead of failing open (exposed). A forgotten route returns a 401, not your customer's data.

Then I test it. This part is not optional. I hit every endpoint with no session attached and confirm each one returns a 401. If a single route responds with data, the gate has a gap and I find it before anyone else does.

A proper saas route auth gate is the floor. It's the thing that has to be true before any of the other checks even matter, because there's no point verifying ownership on a route a stranger can already reach.

Check Ownership Before Every Read and Write (IDOR)

A session is not enough

Here's the trap that catches people who think they're done after gating routes.

A session-gated route still leaks if it doesn't verify the logged-in user actually owns the thing they're asking for. The session proves who you are. It does not prove you're allowed to touch this specific object.

Picture User A. They log in with a perfectly valid session. Then they request object ID 1,042, which belongs to User B. The route checks the session, sees a logged-in user, and hands over User B's data. Auth passed. The wrong data went out the door.

That's IDOR, insecure direct object reference, and it's the hole that does the most damage in multi-tenant SaaS. One bug doesn't expose one customer. It exposes every customer, because the same broken pattern applies to every object in the system.

Enforce project and object ownership

The fix is that every read and every write checks ownership before it does anything else. Before you return a record, you confirm it belongs to the requesting user's account or project. Before you update a record, same check.

IDOR Attack: Incrementing Object IDs

The most common version I see is a request that takes an integer record ID. An attacker increments it: 1042, 1043, 1044, walking straight through your database one customer at a time. If your query is "select where id = X" with no ownership filter, every increment is a fresh data leak.

The correct query is "select where id = X and project_id = current_user's_project." Now incrementing the ID returns nothing, because the ownership filter never matches.

Two rules make this work. Do the check server-side, every time. And never trust a client-supplied owner field. If the request body says "owner: me," ignore it. The owner comes from the authenticated session on the server, not from anything the client sends. A client-supplied owner field is just an attacker telling you who to pretend they are.

I wrote a full breakdown of why IDOR is the vulnerability AI developers never think about, because it deserves its own deep dive. It's the one that quietly turns a small bug into a total breach.

Meter Credits on Every Expensive AI Call

AI endpoints cost real money on every single call. An unmetered one is two problems at once: a money leak and an abuse vector.

Credit Metering Order of Operations

The money leak is obvious once you see it. Even a fully authenticated, legitimate user can loop a generation endpoint. Maybe their script retries on error. Maybe they're just curious. Either way, every call hits your most expensive model and you eat the cost.

The abuse vector is worse. Free-tier users farm your most costly model because nothing stops them. You built a generous free tier to acquire customers and instead you built a faucet that pours money out of your account.

The example is the same AI generation route from before, now session-gated and ownership-checked, but with no per-user limit and no credit deduction. It's secure in the access sense and bankrupt in the cost sense.

The fix is to meter credits before the AI call fires. Check the user's balance, deduct the credits atomically, then make the expensive call. If the balance is empty, reject the request before spending a cent on the model.

Order matters. You deduct first, then call. If you call first and deduct after, a user who disconnects mid-request gets the result for free.

I'll be honest about the tradeoff. Metering adds a transaction step to every call, and you have to handle the race condition where two calls fire at the same moment and both think there's enough balance. You solve that with an atomic decrement at the database level, not with a read-then-write you do in application code. It's a bit more work. It's worth it.

There's an upside too. The same metering that protects your margin is the foundation of usage-based pricing. I price some of my products by the credit, not by the seat, and that's only possible because every expensive call is metered at the source. Security and your pricing model end up being the same plumbing.

Sign Your OAuth State (CSRF and Account Takeover)

What a bare OAuth callback accepts

OAuth is where AI-generated code gets quietly dangerous, because the flow looks complete while skipping the part that actually protects you.

The pattern I find: the assistant builds an OAuth flow that passes a state parameter, but the callback never verifies it. Sometimes the state is a random string the callback ignores. Sometimes it's missing entirely. Either way, the callback accepts whatever the provider hands back without confirming it issued that state in the first place.

That opens CSRF on your OAuth flow. In the worst case it opens account takeover, where an attacker attaches their own connected account to a victim's session. Now the attacker's OAuth connection lives inside the victim's account, and depending on what that connection grants, that can be game over.

Signed, session-bound state plus host validation

The fix has three parts.

Signed OAuth State Three-Part Defense

First, sign the state. Generate it server-side, sign it with a secret, and bind it to the current session. The state is no longer a throwaway value. It's a cryptographic claim that says "this session started this exact flow."

Second, verify on callback. When the provider sends the user back, check the signature and confirm the state is bound to this session. If the signature is wrong or the session doesn't match, reject the callback. This is what makes oauth csrf signed state actually do its job: an attacker can't forge a state your session issued, and they can't replay one from a different session.

Third, validate the redirect host against an allowlist. If the callback URL has been tampered with to point somewhere you don't control, reject it. Never redirect to a host you didn't explicitly approve.

I broke the full attack down in detail, because unsigned OAuth state opens the door to account takeover and it's worth seeing exactly how the takeover chains together. It's the most technical of the four holes, and the one most likely to get skipped, because the broken version looks identical to the working version until someone attacks it.

The Repeatable Pass, and Who Should Run Yours

Here's the whole pass, in four lines you can hold any builder accountable to:

• Every route is session-gated. Locked by default, public routes opted out explicitly, tested with no session for a 401.
• Every object is ownership-checked. Server-side, on every read and write, never trusting a client-supplied owner field.
• Every AI call is metered. Credits deducted atomically before the call, rejected when empty.
• Every OAuth state is signed and host-validated. Bound to the session, verified on callback, redirect host on an allowlist.

Let me reframe the buyer's doubt one last time. AI-built software is not inherently insecure. But it ships with predictable debt, and the four holes above are that debt almost every time. A builder who treats security as a gating step before monetization is the difference between owning a liability and owning an asset.

I'll be honest about the limits, because that's the point. This pass is the pre-monetization minimum, not a full security audit. It doesn't cover rate-limiting every public endpoint, secrets rotation, dependency scanning, or a dozen other things a mature product needs over time. What it does cover is the set of holes that will hurt you the most, the fastest, the moment you start charging.

If you've shipped an AI-built product, or commissioned one, and it's about to take money, this is the pass to run first. I run it on my own products before any of them monetize, and I'll run this pass on your product too.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together