2,000 Public Vibe-Coded Apps Expose Security Gaps

Red Access’s May report found more than 380,000 public web assets hosted on leading AI-driven development platforms. Roughly 5,000 of those assets appeared to belong to companies on six continents, and more than 2,000 apps held corporate, operational or personal data that was publicly reachable without basic access controls.

Many exposed applications were built and deployed by non-developer employees who connected them directly to production systems such as customer relationship management platforms, enterprise resource planning systems, ticketing tools and business-intelligence platforms. In several cases the apps were reachable on the open internet with default or no authentication, and some granted administrative access to anyone with the URL. The report notes affected organizations continued to pass security audits while these exposures were live.

Vibe-coding platforms let users describe an application in a browser and quickly generate working software that can be linked to live data sources. OAuth grants or API keys created during the same browser session can tie the new application to corporate systems. The report describes the build, the connection to enterprise systems and the publish action as occurring inside a single browser tab.

The report found common security controls often do not detect or block these workflows. Endpoint detection and response tools register the browser process but not the application being assembled inside it, and they typically cover only managed devices. Data-loss-prevention tools monitor enumerated channels and can flag text pasted into monitored AI chat tools but do not track cloud-to-cloud connections made by a newly created app. Cloud-access security brokers are tuned to recognize known SaaS vendors and can treat many custom subdomain-hosted apps as a single approved platform. Firewalls and secure web gateways observe traffic to platform domains but generally lack context about individual applications or the specific business data those apps expose.

Red Access frames the build-and-publish lifecycle as a session-layer event: the code generation, the OAuth or API connection, the data movement and the publish click all occur inside the same browser tab. A control positioned at the session layer would be able to see which platform was used, which enterprise systems were connected and which application instance was published, with attribution to the individual who performed the action regardless of whether the device was corporate-issued or a contractor’s personal laptop.

The report recommends immediate steps for security teams. Begin with discovery by asking employees whether they have built tools on AI development platforms and record each disclosed application as an inventory item rather than an audit finding. For each application, capture which corporate systems it touches, how those connections are authorized (OAuth, API key, manual upload) and whether the app is publicly reachable. Define approved platforms, specify which categories of data may be used and set a minimum authentication standard that encourages compliance. Adopt continuous discovery at the session layer to monitor new vibe-coded applications as they appear.

The report notes most creators did not act with malicious intent and were solving business problems quickly. It distinguishes these custom-built, directly connected and often publicly published applications from older forms of unsanctioned SaaS, which retained vendor-level identity and audit trails; the report says existing governance models were not designed to manage the exposures created by these new application types.