What 2,000 Exposed Vibe-Coded Apps Reveal About the Limits of Most Security Stacks

Historically, the term Shadow AI referred to employees inadvertently inputting sensitive data into AI platforms like ChatGPT. However, it has since evolved to encompass a more significant concern: employees developing complete applications utilizing AI, integrating them with production systems, and making them accessible on the open internet—all without involving Security or IT departments.

The transition from a simple prompt to a fully functioning product has expanded the risk landscape associated with these applications.

According to The Shadow Builders report, which was recently covered by Axios, WIRED, and VentureBeat, Red Access identified over 380,000 publicly accessible web assets across major vibe-coding platforms. Among these, approximately 5,000 appeared to be corporate in nature. More than 2,000 of these assets contained sensitive corporate, operational, or personal information—exposed on the public web without fundamental access controls, often providing default administrative access to anyone who stumbled upon the URL. This issue spans six continents and various industries, with no exploitation necessary to access the data.

These vulnerabilities existed within organizations, even as they passed their audits while these exposures remained active.

The new Shadow AI isn't about prompts. It's about products.

Vibe coding—part of the broader category of AI-facilitated development platforms that enable users to create applications simply by describing their desired functionality—has significantly reduced the time typically required for engineering teams to develop applications. This allows individuals without a programming background to deploy an operational tool in a matter of hours.

For instance, a marketing manager could quickly assemble a campaign tracking tool connected to a business intelligence (BI) system housing relevant metrics. An operations manager might design a vendor intake form linked to the organization’s ticketing system. Similarly, a finance team could develop a dashboard for board preparations, integrating invoice data ahead of a deadline. Such applications are often connected to approved production systems—including CRMs, ERPs, ticketing tools, and BI platforms—and are frequently exposed on the internet with whatever access settings the builder has established—often none at all.

Importantly, those creating these applications are typically well-meaning employees striving to address genuine needs more efficiently than their organization can. They are doing precisely what the AI development platforms encourage. The platforms themselves are not nefarious; they fulfill the demands of their users. However, the associated governance frameworks, both technical and behavioral, have not adapted to manage the outcomes of this rapid development.

This scenario represents a shift from traditional Shadow IT. Instead of merely purchasing an unauthorized SaaS tool, which would keep the associated data within that platform, Shadow Builders craft tailored applications. These applications incorporate unique data and directly link to primary production systems, often exposing them to the open internet without appropriate oversight. The underlying platforms may be subject to audits, yet the applications built atop them are frequently not. This dynamic renders IT departments largely uninvolved in the process.

Why a mature security stack still misses this

A Chief Information Security Officer (CISO) encountering these statistics may instinctively review the current security stack. Endpoint Detection and Response (EDR) systems are in operation, Data Loss Prevention (DLP) mechanisms are configured, Cloud Access Security Brokers (CASB) are licensed, and both firewall and Secure Service Edge (SSE) protections are in place. While each of these tools performs its designated function properly, they may not adequately address the new risks posed by vibe-coded applications.

EDR solutions monitor browser activity and may misinterpret a Shadow Builder engaging with a vibe-coding platform as benign, non-malicious browsing—hardly distinguishable from typical internet usage. Furthermore, most modern EDR systems or enterprise browsers only assess activity on devices managed by the organization. Personal laptops, contractor devices, or BYOD (Bring Your Own Device) systems remain invisible to these tools.

DLP monitors specific, known channels for regulated data but cannot detect instances where a vibe-coded application connects to an authorized BI tool via an API, transferring data directly from cloud to cloud, thereby bypassing endpoints entirely.

CASB solutions were initially designed to manage Shadow IT related to identifiable SaaS platforms, yet they struggle to differentiate between a vast array of custom applications hosted on the subdomains of vibe-coding platforms and the platforms themselves. Consequently, the entire spectrum of applications may register as a single approved SaaS vendor.

Firewall and SSE tools can monitor traffic aimed at a platform's domain but lack the necessary application-level context. Moreover, many SASE/SSE implementations are only partially complete, leaving the unmanaged device issue unresolved.

None of these security measures are failing; rather, the challenge arises from their collective inability to cover the gaps left unaddressed by the existing architecture, resulting in fragmented signals that never coalesce into a comprehensive, governable overview.

Where visibility actually has to live

The process of vibe coding unfolds as a series of web-session events. The initial build occurs within a browser session, as does the OAuth grant linking the new application to an approved enterprise system. The data crucial to the application is exchanged during this session, culminating in the publish action that transforms the build into a publicly accessible application—only a click away within the same tab.

Given this, a control mechanism situated at the session layer can capture the entirety of the build process—not just isolated fragments. Such a control can monitor the platform utilized, the corporate systems it connects to, the methods of integration (OAuth, API key, manual uploads), the data flow, and the publication event that places the application on the open internet. This level of monitoring is attributable to individual users and specific application instances, independent of the browser or network route employed. It can also account for devices, whether corporate-issued or personal.

What to do this week

Organizations can undertake four crucial steps, none of which necessitate new technology purchases.

First, initiate a discovery phase. Encourage employees to disclose any applications they have developed. Most Shadow Builders are engaged in constructive work and are not concealing their projects; the approach is critical. A workforce-wide request, such as “If you have constructed a tool using an AI development platform, we would like to know about it. This is not an audit; we are conducting an inventory,” can yield much better responses than traditional policy announcements or tooling rollouts.

Next, map the findings. For each identified application, document which corporate systems it connects to, the method of connection (OAuth, API key, manual upload—each with distinct audit trails), and whether the application is publicly accessible. Notably, public reachability serves as the most actionable insight in the short term.

Establish a sanctioned communication pathway. Provide Shadow Builders with a means to share their developments. Designate approved platforms, outline acceptable data types, and establish baseline authentication standards. This strategy allows for a more efficient communication flow than the alternative, where employees may opt not to disclose their developments.

Finally, recognize that this effort represents an ongoing inventory. The creation of vibe-coded applications is a continual process; the understanding developed now will likely evolve and be incomplete in the coming months. The optimal approach is to maintain continuous discovery at the activity layer where these developments occur.