Nobody hacked them. The setting was just wrong.
Researchers scanned 380,000 apps built by AI and found thousands quietly publishing medical notes, financial records and customer lists. Almost none of them were attacked. They were just left open — and the business whose customers those were is the one who answers for it.
In May, security researchers pointed a scanner at the open internet and counted 380,000 applications that had been built by describing them to an AI rather than by writing code.
About 5,000 of them were handing out things nobody meant to publish.
Patient conversations. Medical summaries. Internal financial records. Shipping routes. Customer service histories. Complaint logs — which is to say, a list of your unhappiest customers and exactly what they were unhappy about, readable by anyone who found the page.
And search engines had found the pages. They were indexed. You did not need to be a hacker to read any of this. You needed to be curious.
The part that should worry you
Nobody broke in.
There was no attack, no stolen password, no clever exploit. The tools that built these apps defaulted to public. If you wanted yours private, you had to go and change a setting — one you very likely did not know existed, in a thing you did not build, in a menu you had no reason to open.
That is the entire story. Thousands of businesses leaked their customers’ data because a default was wrong and nobody went looking.
The researcher who ran the scan put it plainly: organisations are leaking private data through these tools without realising it is happening.
It is worth being specific about what that means. Not “could be breached in future”. Already published. Already indexed. Already readable this morning.
A second way it goes wrong
One widely-reported app had its access keys sitting in the page’s own source code — the part of a website anyone can view, by design, in any browser.
Security researchers found 1.5 million authentication tokens and 35,000 email addresses that way, along with private messages. The founder had said publicly that he did not write a single line of the code.
That is not a story about a careless person. It is a story about the gap between I described what I wanted and got something that works and I understand where this put my customers’ data. Those are very different things, and only one of them is obvious from looking at the finished screen.
The app worked perfectly. It looked finished. That was the problem — nothing about it looked wrong.
Why this lands hardest on small businesses
A large company has someone whose actual job is to ask “where does this data live, and who can read it?” That person is annoying, slow, and the reason the company is not in the news.
You do not have that person. You have a Tuesday, a thing you needed, and a tool that produced it in an afternoon. You asked for a booking system, or a customer list, or a little internal tool for the staff rota. You got one. Nobody in that loop was responsible for asking the boring question.
And here is the part that is genuinely unfair: it is still your problem. Consumer-protection regulators are consistent on this point — if a supplier exposes your customers’ data, the business those customers trusted is the one that has to answer for it. “The tool defaulted to public” is an explanation. It is not a defence.
The thing all of these have in common
Look at what actually leaked in every one of these cases.
Not websites. Applications. Things with a database behind them. Things that stored records, had logins, kept a list, remembered who you were.
A website that is only pages cannot leak your customer list, because it does not have one. There is no admin panel to leave public, no database to misconfigure, no access key to drop into the page source. There is nothing to get wrong, because there is nothing there.
This is the uncomfortable, unfashionable conclusion: for most small businesses, the safest system is the one that cannot do anything. Not because simple things are more secure in some vague way, but because the specific failure that put 5,000 businesses on the open web is not available to a page that is just a page.
The fair question
devkoi is also an AI that builds websites. Why would this be different?
Because of what it will not build. devkoi makes plain pages — no server, no database, no logins, no stored records. The pages are uploaded as files and served as files.
That is a limitation, and it is worth saying so honestly. If you need a members’ area, a customer portal or somewhere to store records, devkoi is not the thing, and you should go and get the thing — with your eyes open and the questions below in hand.
But it does mean there is no setting on your devkoi site that can be wrong in this particular way. Not because anyone was clever. Because the parts that leak were never built.
What to do this week
Most of this is not about your website. It is about everything else you have quietly accumulated.
1. Write down every tool that holds your customers’ details. Booking system, mailing list, spreadsheet in the cloud, that little app someone made for the rota. Most businesses find more than they expected. You cannot check what you have not listed.
2. For each one, go and look at whether it is public. Not “assume”. Look. This is the single highest-value hour in this article, because it is precisely the step nobody took.
3. Search for your own business the way a stranger would. The leaked apps were indexed. Put your business name, your address and your owner’s name into a search engine and go three pages deep. If something of yours is out there, better you find it.
4. Stop collecting what you do not need. The safest customer record is the one you never took. Date of birth on a booking form for a haircut is a liability with no upside.
5. Ask what your website is actually for. Most small business sites need to say who you are, what you do, what it costs and how to reach you. That needs no login and no database. If something is pushing you towards an account system, make it justify itself.
“Does anything on our site need a login? If not, take it out.”
6. Know where your contact form sends. A form has to deliver somewhere. On a devkoi site that is either an email to you or an outside form service — and if it is a service, that service is now on your list from step 1.
“Where does our contact form send, and what does it keep?”
7. Keep the public thing boring. Your website is the part the whole world can see. That is a good reason for it to hold nothing worth stealing.
“Put the opening hours, prices and phone number on the site — and keep the customer list somewhere else entirely.”
The uncomfortable truth in that scan is not that AI builds insecure things. It is that it builds finished-looking things, fast, for people who were never given a reason to look underneath.
A working screen used to be evidence that somebody competent had been involved. It isn’t any more. The only remaining way to know whether your customers’ data is safe is to go and check — and for most small businesses the best move is to need far less checking in the first place.