The five most common ways an AI-built app gets popped in its first week.

Most of the AI-built software we look at is fine. Not great — fine. The problem is that “fine” can hide a single line that takes the whole company down on a Tuesday. The patterns below are not exotic; they are what we find in roughly half the codebases we audit.

1. The service-role key in the client bundle

The single most common high-severity finding we see. The model wired up your database with the highest-privileged key it knew about, and that key now ships in your JavaScript bundle to every visitor. Anyone who opens devtools owns your database.

How to check, in 30 seconds: build your production bundle, search the output for service_role, your vendor key prefix (sk_, eyJ, etc.), and any string that looks like an API token. Anything you find is an emergency.

2. Row-level security off “just for now”

You can find this one without touching the code. Open your app in two browsers as two users. In one, find a record ID. In the other, with devtools open, change the URL or query parameter to that ID. If you can read or modify the other user’s data, your app does not have access control. It has a UI that politely asks people not to.

“We thought RLS was on. The model turned it off in a migration to make a feature work. Nobody noticed for six weeks.” — anonymized founder, post-incident

3. The Stripe webhook that doesn’t verify signatures

If you accept payments, your webhook endpoint must verify Stripe’s signature header against your webhook secret. This is two lines of code. Without it, anyone on the internet can POST checkout.session.completed at your endpoint and grant themselves a paid plan, refund someone else’s payment, or both.

4. The LLM endpoint with no rate limit

Your “ask AI” button calls OpenAI on the server. There is no per-user rate limit. There is no global cap. Someone writes a five-line script that hammers it 200 times a second from a free trial account. You wake up to a $40,000 bill and a polite email from your provider.

The fix has three layers, in order of importance: a hard provider-level spending cap; a per-user, per-day token budget; and a request rate limit on the endpoint itself. Doing only one of these is not enough.

5. “We have backups” — except you don’t

This one is universal. The team genuinely believes they have backups. We ask three follow-up questions:

1. Where are they?
2. When was the last successful one?
3. Has anyone restored from one?

The honest answer is usually “the hosting provider does it, I think,” “I’m not sure,” and “no.” A backup you have never restored from is an unverified claim, not a backup.

What to do this week

If you can only do five things in the next seven days, in this order:

• Find every key in your client bundle. Rotate everything you find.
• Confirm RLS or equivalent server-side authorization on every table.
• Verify webhook signatures on every payment provider.
• Set a hard provider-level spending cap on every API that costs you money.
• Take a backup. Restore it to a scratch environment. Time it.

None of these require an audit, a sprint, or a consultant. They require a quiet afternoon.