A lot of small businesses shipped their first app this year without hiring anyone. You type what you want into a box, wait a minute, and something runs. That part is real. It's genuinely useful, and I'm not here to tell you to stop.
Here's the part nobody mentions at the prompt box.
In early May, an Israeli security firm called RedAccess told Axios it found roughly 380,000 publicly reachable apps built with these AI tools. About 5,000 of them were leaking sensitive business or personal data. Nobody hacked them. The tools defaulted new apps to public, and most people never flipped the setting to private.
Then search engines indexed them. So anyone could stumble onto your stuff by typing the right words into Google.
"It works" and "it's safe to ship" are two different jobs
When the demo runs, it answers exactly one question: does this thing function? That's the job the prompt box is good at. It writes code that does what you described.
The second job is the one that bites. Who can reach the data? What's locked and what's wide open? Does anything check that the person asking is allowed to ask? What happens to this app in three months when a new way to break it shows up and nobody's watching?
That second job is invisible. It doesn't show up in the demo because the demo isn't trying to break in. And the prompt box does the first job well while quietly skipping the second one entirely.
Look at what actually leaked, per the apps Axios verified. A shipping company app that listed which vessels were headed to which ports. A bank's internal financials. A cabinet supplier's full, unredacted customer service conversations. A hospital app with patient complaints and staff schedules. A school app with lesson recordings, student data, and the teacher's calendar.
None of these were built to be public. They were internal tools that did their job. The problem wasn't the code. It was a setting, and a default, and the fact that nobody told the app who was allowed to see what.
It's missing configuration, not bad code
This is the part that surprises people. The AI usually doesn't write malicious or broken code. It writes a working app and leaves the security parts blank unless you explicitly tell it otherwise.
Database locked down so only the right people can read the right rows? Off by default in a lot of cases. Some login check standing between a stranger and your customer list? Only if someone wired it up. And these tools tend to reach for the easiest database connection to set up, which is often the most powerful one, the equivalent of handing every visitor a master key because that was the path of least resistance.
The numbers back this up. Independent testing of one builder found broken access control in 11 out of 12 apps when the generated code shipped without a human configuring the database security. A Q1 2026 study put it at 91.5% of these apps carrying at least one real flaw.
Here's why that matters more than it sounds. About 63% of the people using these tools, per a February 2026 industry tracker, have no coding background. So you've got non-engineers making engineer-level decisions, what data the app can touch, who can reach it, whether there's any login at all, without anyone telling them a decision is even being made. When a tool is sold to people who aren't builders, the default setting becomes the security plan. Whatever the box ships with is what you get.
Who actually owns the code an AI builds
There's a second surprise waiting underneath the first. You might not fully own the thing you generated.
Under current US and UK law, copyright needs a human author. Code written mostly by an AI may not be copyrightable at all, which means it might not be defensibly yours even when the tool's terms of service say it's "assigned" to you. One survey found 72% of startups using AI coding tools, and fewer than 10% with any policy covering who owns the output.
For a weekend side project, fine. For the app running your bookings, your customer data, or your payments, "we're not totally sure this is legally ours" is a strange place to build a business on.
This is the gap your tech team is supposed to own
So put the two jobs side by side. Generating an app that runs is fast, cheap, and now available to anyone. Making that same app safe to put in front of real customers is slow, invisible, and boring, right up until the moment it isn't.
That second job is the whole reason a tech team exists. Not to type the code, the box can do plenty of that now. To own the space between "it launched" and "it's a liability." To make the access-control call the prompt box never made. To check who can reach your data before a reporter or an attacker checks for you. To still be paying attention next month.
If you've built something with one of these tools and it's holding anything you'd hate to see on the open web, the fix usually isn't a rebuild. It's someone competent looking at the defaults, the database permissions, and who can actually reach what. Most of the time the gaps are quiet and very fixable once someone's actually looking.
That's the kind of thing we do for clients. We're Kief Studio, a two-person studio that acts as the tech team a lot of small businesses don't have, and we'd rather catch this stuff before it's a headline than after.
If you're not sure where your app stands, the first conversation is free, no commitment. And if you want to keep getting plain-English breakdowns like this one, subscribe free at kief.studio for the member resources and guides.