On 7 May 2026, the cybersecurity firm RedAccess revealed that thousands of applications built with "vibe coding" tools such as Lovable, Replit, Base44 and Netlify were open to anyone, data included: medical records, financial figures, strategy presentations. Vibe coding security is not decided inside the tool, but before you open it. Your prototype can go live on the day you have decided who should see which data, and checked that this is actually the case.
Key takeaways
- RedAccess says it found 380,000 publicly accessible apps and assets built with Lovable, Base44, Replit and Netlify, of which about 5,000 contained sensitive corporate data.
- According to WIRED, around 40% of the unprotected apps the researchers examined exposed sensitive data, close to 2,000 of them.
- The platforms reply that a public app is the user's choice, not a flaw. They are partly right, and that is exactly the problem.
- An AI writes the code you ask for. If nobody has decided who may see what, it will not decide for you.
- Before going live: a requirements document that says so, then a simple test from a private browser window.
What is happening: vibe coding security caught out
Vibe coding means building an application by describing it to an AI, without writing the code yourself. These tools let a marketing manager, a salesperson or a non-technical founder put a tool online in an afternoon.
The team led by Dor Zvi, co-founder of RedAccess, found these apps with plain Google and Bing searches. It was easy: Lovable, Replit, Base44 and Netlify host their users' apps on their own domain names. The researchers shared their findings with WIRED and Axios, which published them on 7 May 2026.
The two outlets do not describe the figures in the same way, so I would rather give you both versions:
- Axios: RedAccess found 380,000 publicly accessible assets built with these four tools, including about 5,000 containing sensitive corporate data.
- WIRED: more than 5,000 apps had virtually no security or authentication; around 40% of them, close to 2,000, appeared to expose private data.
In both cases the examples are the same: a hospital's work assignments with doctors' personal data, a company's detailed ad purchasing, a go-to-market strategy, a retailer's complete chatbot conversations with its customers, names and contact details included. Some apps only required signing in with any email address. In a few cases, according to Dor Zvi, they would have allowed him to gain administrator rights. The landing page of the RedAccess report gives the same order of magnitude: 40% of the corporate AI-built assets reviewed exposed sensitive data.
The limits must be reported too. WIRED could not confirm that all the data was real; some apps may have been tests filled with fake data. And the platforms disputed the method. For Replit, "public apps being accessible on the internet is expected behavior". Lovable points out that how an app is configured "is ultimately the creator's responsibility". Wix, which owns Base44, speaks of "a user configuration choice, not a platform vulnerability".
A researcher quoted by WIRED, Joel Margolis, sums up the core issue: AI coding tools "do what you ask them to do. And unless you ask them to do it securely, they're not going to go out of their way to do that."
What it means for you
For a small business, these tools are a real opportunity: an internal tool that used to take weeks of development can exist in a few hours. But they move the decision to publish. It no longer goes through an IT person asking who has access to what; it is made in one click, by the person who needs the tool.
RedAccess actually describes this as a new form of shadow AI: after employees who paste client files into ChatGPT, those who build applications, connect them to company data and publish them without anyone knowing.
Two practical consequences:
- You may not know what is running. A sales dashboard, a job application form or a site tracker built by a colleague may be online, at an address anyone can find through a search engine.
- The responsibility stays with you. The platforms say so plainly: the visibility setting belongs to the creator. If the app holds customer or employee data, your company is accountable for it, as for any other file.
And for the founder who has an AI-generated prototype and wonders whether to launch it, the honest answer is: not yet, as long as you cannot answer the question "who sees what".
What I learned from it
I built TSFind, a service provider directory, with the help of Claude Code, an AI programming assistant. One of the project's central problems was precisely this one: exposing public data, the listings and reviews, without exposing private data, the proofs, contacts and subscriptions.
At first I let the browser query the database directly, protected by rules that decide, row by row, who can read what. The richer the data model became, the harder these rules were to keep right: it took several successive fixes to clear the database's security warnings one by one. In the end I changed the architecture: all reads and writes now go through the server, which chooses exactly what it returns, and the rules stay active as a second line of defence.
What I take from it: AI saved me a lot of time on the code, but none on that decision. I had to understand the risk, decide on the architecture and check the result. An AI delivers what you describe; it does not ask, on its own, what must stay private.
It is also the advice I gave Justin Gary, game designer and CEO of Stone Blade Entertainment, during an AI hackathon: start with a requirements document, a PRD. He told the story in his article: 45 minutes to write the PRD with Claude, 15 minutes to review it, then 2 hours to get a working prototype with Lovable. The requirements document is where you write, among other things, what data the app stores and who should access it. It is the method I apply to my application projects: requirements first, code second. I was already writing about it, before AI, regarding no-code tools and improvisation.
What to do in practice
1. Take an inventory
Ask your teams which apps they have built with an AI tool, on which platform, and with what data. Promise there will be no blame: you want a complete list, not culprits.
2. Run the private window test
Open each app's address in a private browser window, without being signed in. If you can see data, everyone can. Then create a second test account: if it can see the first account's data, the app does not keep its users apart.
3. Write down who should see what
For each app, one page is enough: what data it holds and, for each item, who is entitled to it (everyone, signed-in users, only their owner, the administrator). This is the heart of the requirements document. If it does not exist, write it now.
4. Fix the settings, or take the app down
Make private whatever does not need to be public, require real authentication, and check that no secret key sits in the code sent to the browser. If the app holds real data it cannot protect, take it offline until it is fixed.
5. Decide what stays a prototype
A prototype with fake data is an excellent discussion tool. A tool that handles customer data deserves a designed architecture, a review by someone other than its author, and a named owner. Decide, app by app, which side it is on.
Frequently asked questions
Can I put an AI-built app into production?
Yes, if you know what data it holds, who should access it, and you have checked it yourself, at the very least with the private window test and a second account. Where the code came from matters less than the check.
Are vibe coding platforms responsible?
They provide visibility and access settings, and consider their use to be the user's business. Whatever you think of that, you are the one accountable for your customers' data: do not rely on the default settings.
Should these tools be banned at work?
No. They are useful, and a ban pushes people to use them in secret. A simple rule works better: prototype freely with fake data, and nothing touches real data without a requirements document and a check.
Going further
I design and build custom applications and automations, starting with the requirements, and I can also review an existing prototype before it goes live. To discuss your case: a 20-minute call.
Sources
- Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, Andy Greenberg, WIRED, 7 May 2026.
- AI vibe-coding apps leak sensitive data, Sam Sabin, Axios, 7 May 2026.
- Report: The Shadow Builders Inside Your Organization, RedAccess, 8 October 2026.
- A Game Designer's Guide to Vibe Coding, Justin Gary, Substack, 3 June 2025.
Cover photo: Kelly Sikkema / Unsplash, Unsplash license.
Tags: vibe coding, application security, generative AI, data protection, requirements document, custom applications