Shadow AI Apps: From Prompt Experiments to Public Data Exposure
AI app security vulnerabilities in “vibe-coded” or AI-built applications arise when non-developers rapidly create and publish custom business tools that connect to production systems but lack basic authentication, authorization, and oversight, leading to silent cloud data exposure that traditional enterprise security stacks often fail to detect. In the Shadow Builders report from Red Access, researchers found more than 380,000 publicly accessible web assets on leading AI development platforms. Roughly 5,000 appeared corporate, and over 2,000 of those exposed sensitive corporate, operational, or personal data without meaningful access controls, often granting admin access by default to anyone who knew the URL. These are not proof-of-concept toys but working apps wired into CRMs, ERPs, ticketing tools, and BI platforms. The result is a growing class of access control failures that sit in production while organizations pass internal audits, unaware that sensitive dashboards, forms, and trackers are sitting open on the internet.
How AI Development Tools Bypass Standard Security Practices
Vibe-coding platforms promise working applications in hours by letting employees describe what they want and auto-generating the code and integrations. That speed comes with a trade-off: the platforms optimize for rapid delivery, not security design. Builders often deploy apps with default public URLs, weak or no authentication, and overly broad permissions to connected systems. Marketing teams build campaign trackers tied into business intelligence tools, operations teams publish vendor intake portals connected to ticketing systems, and finance teams expose invoice dashboards—frequently without realizing they are publishing live production data to the open web. According to Red Access, “more than 2,000” corporate AI-built apps held sensitive data while lacking basic access controls. Because the underlying platforms may be sanctioned, enterprises sometimes assume these apps inherit corporate controls. In reality, each custom app is its own security object, and most receive no code review, threat modeling, or identity integration before going live.
Why Enterprise Security Stacks Miss These Access Control Failures
Cloud data exposure from AI-built apps lives in the gaps between existing security tools. Endpoint detection and response (EDR) often only sees a benign browser session, not that the user is building a new public-facing app. Data loss prevention (DLP) focuses on known channels and obvious copy-paste flows, while vibe-coded apps move data cloud-to-cloud through APIs, bypassing the endpoint altogether. CASB tools were designed to spot and govern SaaS vendors, not thousands of custom apps hosted under a single approved platform’s domain, so the entire population can appear as one sanctioned service. Firewalls and SSE tools see traffic to a familiar domain but lack context about which specific app instance is exposing what data. The key issue is that every step—from building to OAuth grants to publishing—is a session-layer browser event, and most enterprise controls are not instrumented to track and govern that layer end-to-end across managed and unmanaged devices.
Closing Enterprise Security Gaps Before AI Apps Hit Production
Organizations need a structured response that treats AI-generated code and vibe-coded apps as first-class production software, not side projects. Mandatory security reviews for AI-generated applications should be built into deployment workflows, covering authentication, authorization, data classification, and exposure of public URLs. Security teams should start with discovery: ask employees to self-report tools they have built on AI development platforms and build an inventory of applications, the systems they connect to, and whether they are publicly reachable. From there, define a sanctioned path with approved platforms, minimum authentication standards, and clear boundaries for what data may flow into AI-built apps. Finally, recognize that this is a continuous problem, not a one-time cleanup. New apps will appear weekly. Controls and monitoring must operate at the browser session layer, where AI app creation, integration, and publication actually occur, so access control failures are caught before sensitive data reaches the open internet.
