Security Risks of AI-Generated Code: A Pre-Launch Checklist

Tools like Cursor, Lovable, Claude, and v0 write code that works, fast — which is exactly why they're now how a huge share of new products get their first version. What they don't do is think about who might misuse what they just built. An AI coding assistant optimizes for "does this feature work when I click through it," not "what happens when someone edits the request before it reaches the server."

That gap doesn't show up in a demo. It shows up the first week real users — and the first automated scanner an attacker points at every newly registered domain — actually hit the product.

The most common finding in our reviews isn't exotic — it's an API key sitting in client-side code, visible to anyone who opens developer tools. It happens because AI tools default to the fastest path to "it works," and hardcoding a key into the frontend gets there immediately.

Committed `.env` files and keys still sitting in git history are the second most common version of the same mistake — deleting a key from the latest commit doesn't remove it from history, and a scanner will find it there just as easily as in the current file.

Row-level security that exists in theory but isn't actually enabled is a close third. So is a permission check that works for the request a developer tested and silently fails the moment someone changes an ID in the URL.

Admin routes are a specific and common case of the same problem: hidden in the UI is not the same as checked on the server, and an AI tool asked to "add an admin page" will happily build the button without ever being asked whether the button is the only thing standing between a regular user and admin-only data.

A login flow can look completely correct — redirect on failure, error messages, a lock icon — while the actual gatekeeping happens only in the browser. Real server-side verification, sensible session handling, and a signup or password-reset flow that can't be abused are the difference between a login screen and actual security, and AI-generated auth code frequently gets the first without the second.

Products with an AI feature carry a category of risk that barely existed a few years ago: a user finding a way to make your model ignore its instructions, or a workflow that lets someone rack up an unbounded token bill on your API key because nothing caps how many requests one user can trigger.

Model output going straight into your database or your users' screens without any check in between is its own quiet risk — the model is not a validated input source just because it's yours.

A written report, delivered within five working days, is the baseline — not a slide deck, but a document that lists every issue found, ranked from critical to low, with the exact file and line for each one and a plain-language explanation of what an attacker could actually do with it.

The useful part isn't just the list — it's the fix. Critical issues come with code, not just a description of the problem, plus a signed-off checklist to work through before launch and a 45-minute call to walk through what matters most. Most reviews turn up five to fifteen real issues, two or three of them serious enough that launching before they're fixed would be a mistake. Occasionally a review finds nothing much, and a report that says so plainly is worth having too.

• Search your entire repository and git history for API keys, not just the current commit
• Confirm row-level security is actually enabled on every table, not assumed from the schema
• Test every permission by changing IDs and roles in the request itself, not just by clicking through the UI
• Verify every check that matters happens on the server, including admin access
• Add rate limits and a hard cap on AI API spend before launch, not after a surprising bill
• Decide what user data you're storing, whether it's encrypted, and whether your logs are quietly capturing more than they should

If a handful of those are already unclear to you, that's the exact gap a security and pre-production review is built to close — before your users, or someone with worse intentions, find it first.