98% of AI-built apps have a security flaw, and staff are building them faster than IT can see. A light first-pass process for IT teams, and a free IT Review Pack in Verilay to help.
98% of apps built on AI platforms like Lovable and Bolt have at least one security flaw, and 16% have a critical one. (Symbiotic Security, June 2026)
In most companies, the people building those apps now outnumber professional developers four to one. Yet fewer than a third of security leaders say they can see every app their staff have built. (Kanopy Security, April 2026)
Put those together and you get a quiet problem most IT teams already suspect: someone in marketing, finance or operations has built a useful little app over a weekend, it's touching company data, and nobody who knows what a database access rule is has ever looked at it.
In short: a free first check for IT teams
Every Verilay report now includes an IT Review Pack: one printable page that tells you whether an AI-built app looks safe to approve, what to fix first, and what the check didn't cover. Upload the app's code, get the pack, attach it to your approval ticket. It's free, and it's a first pass, not a certificate. See what's in it ↓
The rest of this post covers what the research says, what IT teams can realistically do about it, and exactly what the IT Review Pack checks.
These studies scanned real, public apps built with AI tools. Not predictions or surveys about what might happen.
| What they found | Who found it |
|---|---|
| 98% of 1,072 AI-built apps had a security flaw; 16% had critical ones | Symbiotic Security, June 2026 |
| Across 5,600 public AI-built apps: 2,000+ high-impact vulnerabilities, 400+ exposed keys and passwords, 175 leaks of personal data such as medical records and bank details | Escape |
| About 380,000 public AI-built apps and assets found; around 5,000 contained sensitive company information | RedAccess, reported by VentureBeat |
| 170+ Lovable projects had databases anyone could read or change, because access rules weren't doing their job (tracked as CVE-2025-48757) | Superblocks |
| Business builders outnumber professional developers 4 to 1; over 80% of security leaders lack full visibility of what they build | Kanopy Security survey of 200 security leaders |
One honest caveat: no study I could find measures employee-built apps specifically. The vulnerability studies scan AI-built apps in general, and the visibility survey asks about employee-built apps without testing them. But the AI tools are the same ones, and so are the mistakes. There's no reason to think the app your colleague built is the exception.
Most IT teams already have a way to review software. The trouble is that it's built for two kinds of app:
An app built by a colleague in Lovable over a weekend is neither. It doesn't come with a vendor to question, and it never touches your developers' pipeline. It often lives on a public web address, and it frequently connects to a real database holding real data.
The mistakes AI tools make are also a particular kind. They aren't exotic. They're the basic, boring ones that the person building the app can't see:
.env that ends up in the project anyway.None of these needs a security expert to fix once someone has spotted it. The hard part is spotting it.
Many AI builders now include a security scan, and your colleague may well tell you their app "passed". That's a good start, but it isn't a review.
Here's a public example. In April 2025, Lovable added a security scan to its platform. According to Superblocks' write-up of the incident, the scan only checked whether database access rules existed, not whether they actually worked. Around the same time, a researcher found 303 exposed endpoints across 170 Lovable projects whose access rules weren't doing their job.
I'm a non-developer who builds my own products with AI tools, and I've seen the same pattern first-hand: ask the tool that built an app whether the app is safe, and it tends to say yes. The honest issues usually surface when something else looks: a different tool, or a person reading the result critically.
That's not a criticism of any one platform. It's the reason the pattern matters: when the tool that built the app is also the tool grading it, nobody independent has looked. That's the gap an IT team fills: a second opinion from something that didn't write the code.
You don't need a full security programme to make a real difference. Here's a light process that fits a small IT team:
Steps 1 and 5 are about process. Steps 2 to 4 are where tools help.
Verilay has always been built for the person who made the app: plain English, no jargon, here's what's wrong and how to fix it. What it didn't have was a version for the person deciding whether that app is allowed to run.
So every Verilay report now includes a free IT Review Pack: a single printable page you can attach to an approval ticket. It shows:
Your colleague can upload their project as a ZIP, so it works without GitHub access. The code is read in memory only, and never saved.
The IT Review Pack's banner says "Risk reduced and reviewed — not certified safe", and I mean it. It reads the code. It doesn't:
It's a first pass, and a good one: it catches the boring, common mistakes in minutes, for free. That's where most of the real risk in AI-built apps sits. But it isn't a penetration test or a compliance certificate, and anyone who tells you their automated tool is should make you suspicious.
It's free, and there's no account needed. If you're running this across a team and want something it doesn't do yet, email me at [email protected]. I'm building the next part based on what IT teams actually ask for.
Verilay is open source: github.com/ekbm/verilay. AI-assisted analysis can contain false positives or miss issues, and is not a professional security audit. See the AI disclaimer.