But the tools have got much better, surely?

At writing code that works, yes, enormously. At writing secure code, the measured pass rate has not moved. And the vendors themselves have been shipping security scanning features into their platforms, which tells you what they think the risk is. Their product decisions are evidence for the concern, not against it.

My app passed all its tests. Does that mean it is secure?

No, and this is the single most important thing on this page. Broken access control passes every automated test, because the code does exactly what it was asked to do. The tests check that the feature works. They do not check whether a stranger can read your customers’ records by changing a number in the address bar.

What actually goes wrong most often?

API keys and secrets left in the browser where anyone can read them, missing access controls so any logged-in user can see everyone’s data, no input validation, and no spend caps. These are not exotic attacks. They are basics the AI was never asked to include, so it did not include them.

Does this mean I should not build my own tools?

No. Building your own is often the right call and it is getting genuinely easier. It means the build is the easy half. Budget for someone to check it before it holds real customer data, the same way you would not wire a consumer unit yourself and just hope.

What should I check before going live?

Four things: no secrets or API keys in anything the browser can see, proper access controls on everything holding customer data, every input validated, and spend caps set so a bug cannot run up an unbounded bill. If that list sounds like a lot, that is the honest signal to get a second pair of eyes.

Who is liable if AI-written code leaks customer data?

You are. "The AI built it" is not a defence under UK GDPR — you are the data controller, and the obligation to have appropriate technical measures in place sits with you regardless of who or what typed the code.

Do you build with AI yourself?

Yes, extensively — I have shipped more than twenty products. I also run automated dependency and code scanning on every repository, review everything before it goes near real data, and avoid the fully agentic tools that chase errors across a dozen files at once. Using AI properly and using it blindly are different activities.

Plain-English guide

Is AI-generated code
safe to put live?

More business owners are building their own tools by describing what they want to an AI, and it genuinely works. But the AI writes the feature, not the safety. Here is what the research actually shows, what goes wrong in practice, and what to check before your tool holds a single real customer record.

AI-generated code is usually functional but frequently insecure. Veracode found AI introduced security vulnerabilities in 45% of security-sensitive coding tasks across more than 100 models, a figure that had not improved by Spring 2026. The core problem is that broken access control passes every automated test, so working software and secure software are not the same thing.

Mick StevensonForty years across trades, construction, property and plant hire before software. RPII-registered Operational Inspector. Builds and secures AI tools for Cornish businesses.

Published 4 September 2026

The short answer

Not without someone checking it. And I say that as someone who builds with AI every day and has shipped more than twenty products with it — this is not a warning from the sidelines.

The difficulty is that AI-generated code almost always works. You describe what you want, you get a thing that does it, you click around and it behaves. Every signal available to a non-developer says success. None of those signals have anything to do with whether a stranger can read your customer list.

That gap between "it works" and "it is safe" is the whole subject. Everything below is about how wide it is and how to close it.

The evidence

What the research shows

Three findings worth knowing, all from people with no product to sell you on the back of them.

45%

of AI-generated code introduced a security vulnerability, across more than 100 models and 80 security-sensitive coding tasks. Veracode, 2025 — and unchanged in their Spring 2026 update.

publicly disclosed vulnerabilities traced directly to AI-generated code in March 2026 alone — up from 15 in February and 6 in January. Georgia Tech's Vibe Security Radar.

380k

AI-built applications found publicly accessible on the web by security researchers, with thousands leaking corporate or personal data.

The Georgia Tech number is the one I would pay most attention to, and not because 35 is large. It is small. What matters is the shape of the line: six, then fifteen, then thirty-five, in three months. The researchers behind it also estimate the true figure is five to ten times what they can detect, because most AI tools leave no trace in the commit history for them to follow.

These are confirmed, catalogued vulnerabilities in real software, not a laboratory exercise. And they are the ones that got found.

The thing to take away

Green does not mean secure

If you remember one line from this page, make it that one.

Consider the most common serious flaw in web applications: broken access control. Your app has a page showing a customer's job details at an address like /jobs/1042. A logged-in customer changes 1042 to 1043 and sees somebody else's job, their address, their phone number.

Now ask what any automated test would make of that. The page loads. It returns data. It renders correctly. It is fast. Every check passes, green across the board, because the code is doing exactly what it was asked to do. Nobody asked it to check whether this user is allowed to see that job, so it does not, and nothing anywhere reports a problem.

That is why "it all works, I've tested it" is not reassurance. The tests answer "does the feature function", and the security question is "who else can reach it". They are different questions and only one of them gets asked by default.

What it looks like when it goes wrong

In January 2026 a social platform called Moltbook launched. Its founder said publicly that he had not written a single line of code — the whole thing was built with AI tools. It worked. People used it. By every visible measure it was a success story for building software without being a developer.

Within three days, security researchers found the production database exposed: around 1.5 million API authentication tokens, tens of thousands of email addresses, and private messages. The cause was ordinary and dull — a database key sitting in the browser-side code, with the row-level access rules never switched on.

Nothing was broken. The application ran perfectly the entire time. It was a configuration nobody knew to check, because the AI never mentioned it and the founder had no reason to know it existed. That is the failure mode in one story: not a dramatic hack, just a gap between what the tool did and what nobody asked it to do.

The four things that actually break

In my experience of looking at these, the same four come up over and over. None are sophisticated. All are invisible from the outside.

1. Secrets in the browser

API keys, database credentials and tokens ending up in code the browser downloads, where anyone can read them with a right-click. This was the Moltbook failure, and it is the most common one.

2. Missing access controls

Any logged-in user can reach any record by changing a number. Passes every test. Exposes everything.

3. Unvalidated input

Whatever someone types goes straight into the database or the page. The classic route into a system, and the AI will not add the checks unless you asked for them.

4. No spend caps

Not a security flaw, but it empties bank accounts. A loop that calls a paid AI service with nothing capping it can run up thousands overnight. Set the limit on day one, in the provider's dashboard.

"But the tools have improved"

They have, enormously, and I would not want to argue otherwise — I use them daily and they are far better than they were a year ago. But that improvement is in producing code that works. It is worth being precise about which thing got better.

Veracode reran their testing into 2026 and found the security pass rate essentially unchanged, despite newer and more capable models. Their explanation is uncomfortable and convincing: models learn from the vast body of existing public code, and that code contains decades of insecure patterns. A model trained on thousands of examples of a dangerous shortcut will reproduce the shortcut. Getting better at writing code means getting better at writing code that looks like what already exists.

There is a second piece of evidence people miss. The AI coding platforms have themselves been building and shipping security-scanning features into their products. That is not a company covering itself. It is a company that can see what its users are deploying. Their own product decisions are the strongest available confirmation that the risk is real — the vendors are agreeing with the concern, in the most expensive way a company can.

What to check before you go live

If you have built something and it is about to hold real customer data, this is the minimum.

01
No secrets in anything the browser can see. Ask your AI tool directly: "list every API key, secret or credential that ends up in client-side code." Then check it yourself rather than taking the answer on trust.
02
Try the number trick. Log in as one user, find a record, change the number in the address bar. If you can see someone else's data, you have broken access control and it is not ready.
03
Set spend caps today. In the dashboard of every paid service the tool uses. This is ten minutes and it has saved people thousands.
04
Turn on automated dependency scanning. Free on GitHub. It will not find your access-control problems, but it catches known vulnerabilities in the libraries you are pulling in, which is a real category of risk for nothing.
05
Get a person to look before real data goes in. Not after. The costs are wildly different either side of that line.

None of this means do not build. Build. It is the most useful thing a small business can do with these tools, and I would rather you built something than not. Just do not confuse the demo working with the thing being finished, because I would rather be the one who knows than the one who's finished.

Where this comes from

This is plain-English guidance for small businesses, not formal legal advice. Where something genuinely needs a solicitor or a data-protection specialist, I'll tell you straight.

Straight answers

Is AI-generated code safe to put live?: Not without review. Veracode tested more than 100 models across 80 security-sensitive coding tasks and found AI introduced a vulnerability in 45% of cases. Their Spring 2026 update found that figure had not improved despite newer models. The code usually works — that is precisely the problem, because working and secure are different things.
But the tools have got much better, surely?: At writing code that works, yes, enormously. At writing secure code, the measured pass rate has not moved. And the vendors themselves have been shipping security scanning features into their platforms, which tells you what they think the risk is. Their product decisions are evidence for the concern, not against it.
My app passed all its tests. Does that mean it is secure?: No, and this is the single most important thing on this page. Broken access control passes every automated test, because the code does exactly what it was asked to do. The tests check that the feature works. They do not check whether a stranger can read your customers’ records by changing a number in the address bar.
What actually goes wrong most often?: API keys and secrets left in the browser where anyone can read them, missing access controls so any logged-in user can see everyone’s data, no input validation, and no spend caps. These are not exotic attacks. They are basics the AI was never asked to include, so it did not include them.
Does this mean I should not build my own tools?: No. Building your own is often the right call and it is getting genuinely easier. It means the build is the easy half. Budget for someone to check it before it holds real customer data, the same way you would not wire a consumer unit yourself and just hope.
What should I check before going live?: Four things: no secrets or API keys in anything the browser can see, proper access controls on everything holding customer data, every input validated, and spend caps set so a bug cannot run up an unbounded bill. If that list sounds like a lot, that is the honest signal to get a second pair of eyes.
Who is liable if AI-written code leaks customer data?: You are. "The AI built it" is not a defence under UK GDPR — you are the data controller, and the obligation to have appropriate technical measures in place sits with you regardless of who or what typed the code.
Do you build with AI yourself?: Yes, extensively — I have shipped more than twenty products. I also run automated dependency and code scanning on every repository, review everything before it goes near real data, and avoid the fully agentic tools that chase errors across a dozen files at once. Using AI properly and using it blindly are different activities.

Is my business ready for AI? A ten-point check

Score yourself in ten minutes. Where you already stand, what is missing, and what is worth fixing first.

Can I put customer information into ChatGPT?

The single most common way small firms leak data. When it is fine, when it breaches UK GDPR, and how to make it safe.

Built something and want it checked?

A short security review before you go live is far cheaper than a breach afterwards. I look for the things automated tests never catch: exposed keys, missing access controls, unvalidated inputs, uncapped spend. Fixed price, plain English, and I'll tell you honestly if it's already fine.

Ask about a security review

Is AI-generated codesafe to put live?

On this page