Is AI-generated code secure? How we review it
AI-generated code is not secure by default: it is unreviewed code, produced quickly. It becomes safe to run when an engineer decides the structure, reads every change, tests what should be forbidden and scans for known problems. This article shows the gaps we find most often and the five layers of review we use to close them.
By cklicky.com · Published · Updated
The short answer
AI-generated code is not secure by default, and it is not insecure by nature. It is code that nobody has reviewed yet. Whether it is safe to run depends on what happens between the moment the AI writes it and the moment it goes live.
The same is true of code written by a person. The difference is volume: AI produces far more code per day, so a team without a real review process falls behind much faster. This article explains where AI-written code tends to go wrong, and the review we apply before anything ships.
Why AI-written code fails in predictable ways
An AI coding tool is given a request such as "add a page where users see their invoices". It produces code that does exactly that. Three things are missing from the request, and so they are often missing from the result:
- Who must not see it. The request describes the user who should see the invoices. It says nothing about the other users who should not, so the check is easy to leave out.
- What happens off the happy path. Closed tabs, repeated clicks, expired sessions and malformed input are not part of a demo.
- What the rest of the system assumes. The tool sees part of the project. A rule enforced elsewhere can be bypassed by a new piece of code that does not know about it.
The outcome is code that works when used as intended and fails when used otherwise. Attackers, by definition, use it otherwise.
The gaps we find most often
These are not rare or advanced problems. They head the industry's standard risk lists.
| Gap | How it shows up in AI-written code | What catches it |
|---|---|---|
| Broken access control | First in the OWASP Top 10 for 2025. The page checks that you are logged in, not that the record is yours | A reviewer who asks "who else can call this?" for every endpoint |
| Access by record ID | First in the OWASP API Security Top 10. Changing an ID in a request returns someone else's data | A test that logs in as one user and requests another user's record |
| Database rules left open | In Supabase projects, tables without Row Level Security. Supabase says to enable RLS on every table in an exposed schema | Reading every policy, and testing with a normal user's key |
| Secrets in the browser | A secret key that bypasses every RLS policy placed in frontend code to make something work | A secret scan on every change, and replacing anything that leaked |
| Payments trusted too early | The purchase is unlocked on the success page. Stripe says the landing page alone cannot be relied on | Fulfilment from a webhook, with the signature verified |
| Vulnerable dependencies | Packages added because they solved the problem, with no look at their history | An automated dependency scan |
How we review AI-generated code
Our rule is that the AI may draft anything and a person is responsible for everything. In practice that means five layers, each catching what the previous one misses:
- Architecture decided by an engineer. Where the rules live is settled before features are written, so a new screen cannot easily bypass them.
- Every change read by a senior engineer before it is merged. For login, payments and access rules the review is line by line.
- Automated tests on the critical paths, including tests that try to do what should be forbidden.
- Automated scans for known vulnerabilities in dependencies and for secrets in the code.
- Manual testing before release, on real devices and browsers, by someone trying to break it.
The full process, with who does what at each step, is on our how we work page.
What you can check yourself
You do not need to read code to learn a great deal about how safe an app is:
- Log in as one user and try to open another user's record by changing the ID in the address.
- Search the frontend code and built files for the words "secret", "service_role" and "sk_live".
- Make a test payment and close the tab before the success page loads. Was the order still recorded?
- Ask whoever built it: who reviewed this code, and what is covered by tests?
If any of these gives a worrying answer, the longer audit on our fix a vibe coded app page is the next step. The server-side baseline we work to is listed with our backend development services.
What review cannot promise
No process makes software perfectly secure, and anyone who promises that should not be believed. Review, tests and scans reduce the number of mistakes that reach production and shorten the time before the rest are found. That is the honest claim.
A common question is whether a second AI can review the first. Automated checks do find real problems, and we use them. They do not replace a person, because an AI reviewer shares the first one's blind spot: it does not know your business rules unless somebody has written them down.
Two things keep the remaining risk small: monitoring, so that problems are seen quickly, and a habit of fixing security issues before building new features. Both matter more than which tool wrote the first draft.
Three questions to ask before you trust AI-built software
- Who read this code before it went live? A name and a process, not "the AI checks itself".
- What happens when I try something I should not be allowed to do? Ask to see a test that proves it fails.
- How would we find out about a problem? Monitoring and a contact who responds.
If you would like those answers about a product you are planning, write to us through the contact form.
Sources
Every external claim in this article links to its source. Checked in November 2026.