AI-built software
Is AI-generated code secure enough to ship?
AI coding tools have changed how software gets written, in two-person startups and large engineering teams alike. They're fast, and often good. But they write code that works before code that's safe, they don't know which of your data is sensitive, and they rarely say when they've skipped a security step. The result is software that demos perfectly and fails a basic security review.
Rather just ask someone? Talk to usIn short
Not by default. Veracode's October 2026 testing found AI models produced code with a security flaw in 38% of tasks. The usual problems are missing access control, secrets in front-end code, unvalidated input and outdated packages. AI-written code can be secure, but only after someone who knows what to look for has reviewed it.
General information, current as at November 2026, not legal advice. A review lowers risk; it can't guarantee a system won't be breached, and it isn't a certified penetration test or a compliance audit.
- What is vibe coding?
- Building software by describing what you want to an AI tool and accepting what it produces, often without reading the code. It's a genuinely fast way to get to a working product. The security risk is that nobody has checked the parts that don't show on screen: who can read the database, where the keys live, and what happens with unexpected input.
What actually matters
The research is consistent: about a third to half of tasks have flaws
Veracode's July 2026 testing found 44% of AI coding tasks produced vulnerable code; its October update put it at 38%. Cross-site scripting and log injection were handled correctly less than a fifth of the time. Models are improving, but not to the point where review is optional.
Access control is the flaw that leaks data
In 2025 a researcher found 170 of 1,645 apps built with Lovable had databases readable without logging in, because row-level security was missing or weak. In early 2026, Moltbook exposed 1.5 million API tokens through a Supabase key in its front end and no row-level rules. The interface looked fine in both cases.
Secrets end up in the wrong place
GitGuardian found commits co-authored by Claude Code leaked secrets at roughly twice the baseline rate in 2025, and leaked AI-service keys rose 81%. AI tools paste keys where they make the code work, which is often the browser or the repository.
Packages get chosen for convenience
AI tools add dependencies freely, sometimes outdated ones and occasionally ones that don't exist, a gap attackers fill with malicious packages of the same name. Every package added should be one a person has looked at.
Tests prove it works, not that it's safe
AI-written tests check that the happy path works. They rarely check that one user can't read another's records, that an expired session is rejected, or that a crafted request fails. Those are the tests a review adds.
The fix is review, not abandoning the tools
Teams shipping AI-assisted code safely do the same few things: a security review before launch, automated secret and dependency scanning on every change, access rules enforced on the server, and a person who reads the parts that handle money, logins and personal data.
Check these before you launch
If you can't answer one, that's where a review starts.
- Is every database table and storage bucket protected by rules on the server?
- Can a logged-in user read or change another user's records by editing a request?
- Are there any keys, tokens or service-role credentials in front-end code or the repository?
- Do admin pages and API routes check permissions on the server, not just hide buttons?
- Are dependencies current, and has anyone looked at what each one is?
- Is there a log of who did what, and would anyone notice something odd?
Where we'd point you elsewhere
If your app is a prototype with no real users and no personal data, a full review can wait; just keep real customer data out of it. The point to get it checked is before real people, payments or personal information arrive, or before an investor or enterprise customer asks how it was built.
Tell us what you'd like checked
Describe what you run and what's worrying you. We'll suggest a sensible scope and a fixed price, or tell you plainly if a different kind of specialist would serve you better.
Common questions
It can be, once it's been reviewed like any other code. The tools are very capable, but they optimise for code that works, and research consistently finds security flaws in a large share of AI-generated code. Treat it as a fast junior developer's work: useful, and checked before it ships.
The platforms themselves are reasonably secure. The apps built on them often aren't, because security depends on choices the AI made for you, such as database rules and where keys live. Lovable has added security scanning, but a scan doesn't replace someone checking your actual data rules.
You often can't tell from the interface. The common signs are Supabase or Firebase warnings you've dismissed, keys visible in the browser's developer tools, and users being able to reach pages or records by changing a URL. A review checks all of these directly.
No. They're genuinely productive, and we use them. Add the safeguards that make them safe: server-side access rules, secret scanning, dependency checks and a human review of anything touching logins, payments or personal data.
See it working
Software we'd build, running with a fictional business and sample data. Use it, then decide.
Also worth a look
- Leaked API Keys: How to Check and What to Do
- npm, PyPI and Software Supply Chain Attacks
- Code and Infrastructure Security Review
- Already broken or stuck? Fix & rescue
Last reviewed . General information, not legal advice. Figures cited are from the sources named on each page.