In May, Axios confirmed that internal financial information for a Brazilian bank was sitting on the open web, publicly accessible. So were unredacted customer service conversations for a UK cabinet supplier, a health company's list of active UK clinical trials, and a shipping company's schedule of which vessels were due at which ports (Axios).
None of it took a hack. Every one of those apps had been built with vibe-coding tools, and every one was public.
The findings came from Red Access, a security firm that sells shadow AI discovery tools. It reviewed about 380,000 publicly reachable assets built on Lovable, Base44 and Replit or deployed through Netlify. By its own count, about 5,000 were built for corporate purposes, and roughly 40% of those, around 2,000 apps, exposed sensitive data (Red Access). Its reported examples include a hospital app holding summaries of doctor-patient conversations and a security company's triage of live customer incidents.
Some early coverage said about 5,000 held sensitive data. Red Access's own figure is lower, and it is still big enough.
The platforms say it is working as designed
The vendors' response deserves attention, because it is mostly correct.
Replit's CEO said public apps being reachable on the internet is "expected behavior," and that privacy is a one-click setting (Security Boulevard). Base44 said two of the apps cited had been deliberately set to public by their owners. Base44 and Lovable both said Red Access's reports lacked the URLs they would have needed to check its findings, and Replit said it got less than 24 hours' notice before Red Access went to the press (Axios). Red Access has a product to sell and has not published its methodology in a form we could review.
Take all of that at face value and the problem gets clearer. The apps that leaked were not broken. Some platforms made new apps public unless the builder changed the setting, and search engines indexed many of them. Red Access's CEO describes the builders as competent employees solving real problems faster than their organization could (TechTarget). They connected something useful to real data and published it, outside anyone's inventory, so nobody decided who should be able to see it.
That is shadow IT. The spreadsheet macro and the departmental Access database had the same problem. What changed is the on-ramp. Red Access describes the path from idea to a publicly reachable system as taking under an hour.
It is also not fringe behavior. In Retool's survey of 817 of its own customers and builders, 60% said they had built software outside IT oversight in the past year, and 51% said they had built production software their teams use today (Retool). In late 2025, SaaS management vendor Torii found Replit in use at 68% of the companies in its data and Lovable at 64%, with most Lovable use unsanctioned (Torii). Both are vendor samples, but they point the same way.
The platform is a vendor you never assessed
There is a second layer most coverage skips. Even a builder who does everything right is trusting a platform that procurement may never have reviewed.
In April, a researcher showed that a free Lovable account could read other users' source code, database credentials, AI chat histories and customer data on projects created before November 2025. The researcher had reported it through Lovable's HackerOne program 48 days earlier, and it was marked as a duplicate. Lovable first said it "did not suffer a data breach" and called the code visibility "intentional behavior," then apologized. It also said that in February it had accidentally re-enabled access to chats on public projects (The Register). Apps built on Lovable often hold keys for services like Supabase, Stripe and Google APIs, so an exposure there can reach connected systems too (Computing).
In July 2025, Wiz found a flaw in Base44 that let anyone with an app's public ID register on private, SSO-only apps, including internal HR and knowledge-base tools. Wix fixed it within 24 hours and found no evidence that customers were affected (Wiz).
If an employee pasted a production database password into a prototype last year, your company took on a third-party risk it never evaluated. TechTarget's write-up of the Red Access research notes that some organizations passed compliance audits while these exposures stayed live (TechTarget). Audits cover the systems you know about.
The cost is showing up in breach data. IBM's 2026 Cost of a Data Breach report, as summarized by law firm Baker Donelson, found that incidents involving shadow AI, meaning staff using unsanctioned AI tools, more than doubled to 43%, up from 20% a year earlier. Those incidents cost an average of $5.39 million. Of organizations with an AI-related incident, 68% had no AI governance policy (Baker Donelson).
A typical path from prototype to production
Here is a hypothetical scenario, but a familiar one.
A claims supervisor is tired of waiting for a reporting change. On a Friday afternoon she builds a dashboard on a vibe-coding platform, using her personal account. To make it useful, she connects it to a copy of the claims database with a read-write key she got from a colleague. It works. By Wednesday, three teams use it daily and someone has added a form that writes notes back to customer records.
Six months later, nobody in IT knows the app exists. It has no tests, no backups and no access controls beyond a URL. If the supervisor leaves, so does the only person who understands it. The app is now part of how the business runs, and it has none of the support a production system needs.
Banning the platform would not have stopped her. It would have pushed her to a different one.
Gartner has started planning for this. It predicts that by 2028, 60% of vibe-coded applications will be retired because they don't deliver predictable business value. It also expects 30% of software engineering teams to feel material capacity strain from maintaining apps built by citizen developers (Gartner via Tray.ai). The ones that survive land on engineering's desk, often without warning.
Give people a governed way to ship
Our first post argued that people come first, then process, then tools. Vibe coding is that argument at full speed. The people are capable and motivated. The tools are fast. The missing piece is the process between a prototype and a supported system. ConductorOne CISO Will Bengtson, speaking to TechTarget, calls it building "the paved path."
What a reader could start on Monday:
Find what already exists. Look for lovable.app, replit.app, base44.app and netlify.app subdomains in your DNS and proxy logs, and check expense reports for platform subscriptions. Then ask staff to register what they've built. TechTarget's recommended first step is a workforce-wide inventory within 30 days, framed as a request rather than an audit.
Close the obvious exposures first. Anything public that touches customer, patient or financial data gets authentication or comes down this week. Rotate any credential that has been pasted into a prototype.
Pick approved platforms and set the defaults. Corporate accounts under SSO, private by default, no personal accounts for work data. Treat each platform as a vendor and put it through the same review as any other SaaS tool.
Keep production credentials out of prototypes. Give builders sandboxed or masked data to work with. Real access comes after review.
Define when an app graduates. Set a clear trigger, such as handling regulated data, being relied on by more than one team, or writing back to a system of record. Past that point, the app moves to an engineering-owned stack with a named owner, access controls, tests, backups and monitoring.
Budget for the rebuild. The prototype proved the need. Hardening it into a supported system is real engineering work. Plan for it before an incident sets the timeline for you.
We help teams assess what their staff have already built and turn the prototypes worth keeping into supported systems. If that's on your list, talk to us at midrasolutions.com.