Vibe coding has made software creation feel effortless. Describe the app, generate the interface, connect a database, and publish it in minutes. For prototypes and experiments, that speed is genuinely impressive, but for regulated corporate data, it is dangerous.
The problem is not creativity. Control is what matters. When an employee can build and publish an application handling real operational data before IT, security, compliance, or leadership knows it exists, the organization has not modernized its operations. Instead, it has created a new form of shadow infrastructure. In regulated industries, shadow infrastructure is not an innovation strategy. It is a compliance risk.
What Happened in May 2026
In early May 2026, Israeli cybersecurity firm RedAccess found 380,000 publicly accessible assets built with tools from Lovable, Base44, Replit, and Netlify, including about 5,000 containing sensitive corporate data. Around 40 percent of those apps exposed sensitive data, including medical information, financial data, corporate presentations, strategy documents, and detailed logs of customer conversations with chatbots.
Verified exposures included a shipping company app detailing vessel schedules, internal financial information for a Brazilian bank, unredacted customer service conversations for a cabinet supplier, patient conversations at a long-term care facility, and hospital doctor-patient conversation summaries. Remarkably, all of it sat on the open web.
Some vibe coding tools defaulted to making apps publicly accessible unless users manually changed the setting. Many of these applications also appeared in Google search results, making them discoverable by anyone.
RedAccess CEO Dor Zvi put the underlying problem plainly: "I don't think it's feasible to educate the whole world around security. My mother is vibe coding with Lovable, and no offense, but I don't think she will think about role-based access."
That is the point. These tools are not malicious. However, speed without governance is not innovation in regulated environments. It is exposure waiting to happen.
The Real Risk Is Not the Tool
Platforms involved in the May 2026 findings pushed back, and their pushback was technically accurate. Users choose to make apps public. Anyone can change privacy settings. Public accessibility on the internet is expected behavior for tools designed to share content.
All of that is true. None of it matters to a healthcare organization explaining to a regulator how patient conversation summaries ended up on the open web.
The distinction regulators care about is not whether the platform offers security features. It is whether the organization can demonstrate controlled access, protected data, logged modifications, and applied oversight. The OWASP Citizen Development Top 10 Project identifies the most pressing risks that arise from citizen development of software built with AI-assisted coding technologies, including broken access control, authentication failures, sensitive data leakage, and asset management failures. Notably, security scanning built into the tool does not eliminate these risks. They materialize the moment an employee deploys a system handling corporate data without review.
NIST guidance on secure software development practices establishes that AI-generated systems still require disciplined governance across the full development lifecycle, not just at the code generation stage. Consequently, generating code faster does not eliminate the obligation to govern what the code produces.
Furthermore, this is not a new problem. It is the spreadsheet problem at a higher level of consequence. For years, teams built unofficial trackers, approval lists, and client databases in spreadsheets because official systems were too rigid or too slow. Vibe coding can look like the next evolution of that behavior. In regulated environments, however, it repeats the same mistake with a more powerful interface and a wider attack surface.
The Questions Regulated Teams Must Be Able to Answer
Before regulated corporate data enters any application, the organization must be able to answer the following. Who owns this system and who approved it? Where does the data live? Can access be restricted by role, department, or field? Is every change logged? Can the system retrieve previous versions, trace approvals back to a specific individual, and produce audit evidence when a regulator asks for it?
If the system cannot answer these questions, it is not ready to manage regulated data. Speed of creation does not change this obligation.
This is not a position against AI-assisted development. Rather, it is a position about sequencing. The Kohezion Intelligent Infrastructure Model describes this sequencing precisely: structure the data before deploying it, govern who can access it before opening it to operational use, trace every action before relying on the record, and validate high-stakes decisions before treating outputs as authoritative. Then activate intelligence on top of a foundation that earns trust rather than assumes it.
AI belongs inside governed infrastructure, not around it.
Where Vibe Coding Does and Does Not Belong
Vibe coding tools are genuinely useful for early prototypes, interface mockups, proofs of concept, internal brainstorming, non-sensitive experiments, and workflow visualization. They can compress the time between an idea and a working demonstration significantly. That value is real.
However, they should not serve as the live system of record for regulated operations. The future of enterprise software will absolutely include AI-assisted development. Even so, regulated organizations cannot confuse app generation with operational governance. A tool that helps someone build quickly does not automatically provide the controls required to manage sensitive corporate data responsibly.
In compliance-driven environments, the relevant question is not simply whether something can be built. The better question is whether the organization can govern it, audit it, secure it, validate it, and prove what happened after the fact. Understanding why audit trails are an operational requirement rather than a compliance feature is the starting point for answering that question in any technology deployment, including AI-assisted ones.
The Order Matters
For regulated teams, the answer is not to ban AI-assisted development. Building the operational infrastructure that makes governed AI deployment possible comes first. New tools belong only within that governed foundation.
Before replacing a spreadsheet, a legacy system, or a manual process with a vibe-coded application, ask whether the replacement meets the same governance standards the original process was supposed to satisfy. In most cases, it does not, and in most cases, nobody asked.
That is the compliance risk. Not the tool. The absence of the question.
For organizations ready to build operational infrastructure that governs data, enforces accountability, and activates AI responsibly, talk to a Kohezion expert.
