Everyone’s Vibe Coding. Nobody Told The Security Team.
Somewhere in your business right now, someone in marketing or operations might be running an app they built themselves last week. Not a spreadsheet. Not a form. An actual working application, connected to real data, built entirely with an AI tool, deployed with a public link, and never once mentioned to IT.
That’s not a hypothetical. It’s the exact pattern security researchers just quantified at scale.
What the research actually found
A firm called RedAccess scanned 380,000 publicly accessible assets built on popular AI app-building platforms, tools like Lovable, Replit, and Base44 that let anyone describe what they want in plain language and get a working application back. Roughly 5,000 of those assets, about 1.3%, contained genuine corporate data.
That’s where it gets concerning. Of those 5,000, 40% had no basic security controls at all. Two thousand of them had no authentication, no access controls, and no audit trail whatsoever, meaning anyone with the link, and in many cases anyone who found it through a normal Google search, could open them. The data inside ranged from financial records and strategic documents to patient conversations and live credentials and API keys.
Gartner’s own forecasting adds a second layer to this. Their “Predicts 2026” report projects that prompt-to-app development will increase software defects by 2,500% by 2028, driven by a new category of bug: code that reads as syntactically correct but has no awareness of the broader system it’s now connected to.
Why this is a genuinely different problem than the shadow IT you already know about
Shadow IT has been a familiar headache for years. Someone signs up for a project management tool without asking, a team adopts a messaging app nobody vetted. That version of the problem is real, but it’s bounded, it’s a subscription, a login, something IT can eventually find and account for.
This is a different shape of risk entirely. The employee isn’t just using an unapproved tool. They’re building a live, functioning application, wiring it directly into production systems like a CRM or a database, and publishing it to the open internet, all inside a single afternoon. The artifact moved from a prompt to a deployed product, and the risk surface moved with it.
This isn’t a story about carelessness
It’s worth being direct about something here. The people building these apps aren’t cutting corners recklessly. They’re competent employees solving a real, immediate problem faster than the traditional path would have allowed. A marketing coordinator needed a way to track campaign approvals. An operations lead needed a simple internal tool that IT didn’t have bandwidth to build for another two quarters. AI made that achievable in an afternoon instead of a ticket that sits for months.
That’s precisely why this keeps happening, and precisely why it won’t be solved by asking people to stop. The underlying need that drives vibe coding is completely legitimate. The gap is that security and governance were never part of the process at all.
Why most security stacks miss this entirely
Traditional shadow IT detection works by watching for employees accessing unapproved services, a secure web gateway or CASB tool can flag that someone’s visiting a file-sharing site nobody sanctioned. That detects access. It does not detect what got built, what data it touches, or whether it requires a login at all.
A live application connected to a company’s CRM, deployed publicly, sits completely outside that kind of monitoring. Security teams aren’t failing to look. They’re looking in the wrong place, because the risk category itself is new enough that most existing tooling was never designed to catch it.
Where a reasonable starting point actually is
This doesn’t require banning AI app-building tools, which would be both unrealistic and a genuine loss for legitimate productivity gains. It requires visibility into what currently exists, a real inventory of what’s been built, where it’s deployed, and what it’s connected to, followed by a lightweight review process for what gets built next, so the next internal tool gets security built in from the start rather than discovered after the fact.
Most businesses have never had a reason to build this kind of process before, because the underlying capability didn’t exist until recently. That’s not a gap born of negligence. It’s a gap born of the technology moving faster than the governance around it typically does.
If your business doesn’t currently have a clear answer to what’s actually been built and deployed with AI tools across your teams, that’s worth finding out. One Request connects you with a specialist who can assess exactly this kind of exposure and help build the lightweight process that keeps it from growing.