Key Takeaways
- Shadow AI has evolved from risky prompt‑pasting to employees building full applications with AI‑driven “vibe‑coding” platforms and exposing them on the open internet.
- Red Access’s audit found >380,000 public web assets built on these platforms, with ~2,000 containing sensitive corporate or personal data and often lacking any access controls.
- Traditional security controls (EDR, DLP, CASB, firewall/SSE) operate at the endpoint, network, or SaaS‑vendor level and cannot see the full build‑to‑publish flow that occurs inside a browser session.
- Effective governance requires visibility at the session layer – capturing the build, OAuth/API connections, data movement, and publish actions regardless of device or network.
- Immediate actions: workforce‑wide discovery, mapping of integrations and exposure, establishing a sanctioned path for approved platforms, and treating the effort as a continuous process rather than a one‑off inventory.
Introduction: From Prompt to Product
The original notion of “shadow AI” pictured employees inadvertently leaking data by pasting sensitive text into public chatbots. Today the phenomenon is far broader: workers are using AI‑powered development environments to create complete applications, hooking them directly into corporate systems of record, and publishing the results to the open internet—often without any involvement from security or IT teams. The artifact has moved from a fleeting prompt to a tangible product, and the associated risk surface has expanded accordingly.
Scale of Exposure
According to the Shadow Builders report covered by Axios, WIRED, and VentureBeat, Red Access identified more than 380,000 publicly accessible web assets generated on leading vibe‑coding platforms. Roughly 5,000 of those assets appeared to be corporate in nature, and over 2,000 contained sensitive corporate, operational, or personal data. Many of these applications granted admin‑level access by default to anyone who could reach the URL, exposing data across six continents and every industry while still passing internal audits.
What Vibe Coding Enables
Vibe‑coding platforms compress what used to require months of engineering effort into a task a non‑developer can finish before lunch. A marketing manager might assemble a campaign tracker that pulls live numbers from a business‑intelligence tool; an operations manager could spin up a vendor‑intake form that writes directly into a ticketing system; a finance team may build a board‑prep dashboard that ingests invoice data on demand. Because these applications are built by connecting to sanctioned production systems—CRMs, ERPs, BI platforms, etc.—and then published with whatever access controls the builder chose (often none), they create a direct conduit for data to leave the protected environment.
Why Traditional Security Tools Miss It
Existing security stacks are designed for different threat models. Endpoint Detection and Response (EDR) sees only the browser process, treating a vibe‑coding session as ordinary web activity. Data Loss Prevention (DLP) monitors known channels for pasted data but cannot detect cloud‑to‑cloud API calls that move information without touching the endpoint. Cloud Access Security Brokers (CASB) were built for discoverable SaaS vendors; they treat the multitude of custom apps on a vibe‑coding platform as a single approved service. Firewalls and Secure Service Edge (SSE) solutions observe traffic to the platform’s domain but lack context about the specific application, its integrations, or its publish state. Consequently, the activity lives in the gaps between these layers, producing fragmented signals that never coalesce into a governable picture.
Where Visibility Actually Has to Live
Every step of a vibe‑coding project—design, OAuth grant to a corporate system, data manipulation, and the final “publish” click that makes the app reachable at a public URL—occurs inside a browser session. Therefore, a control positioned at the session layer can observe the complete workflow: which platform was used, which enterprise systems were linked, how data flowed in and out, and the exact moment the application became publicly accessible. This visibility is independent of the device (corporate laptop, contractor machine, personal PC) or network path, providing a single, attributable record for each builder and each application instance.
Practical Steps for Organizations
- Discovery: Launch a workforce‑wide, non‑punitive prompt asking employees to disclose any tools they have built using AI development platforms. Framing the request as an inventory effort, not an audit, yields higher participation.
- Mapping: For each disclosed application, document the corporate systems it connects to, the connection method (OAuth, API key, manual upload, etc.), and whether the app is publicly reachable. Public exposure is the most immediate risk indicator.
- Establish a Sanctioned Path: Approve specific vibe‑coding platforms, define permissible data categories, and set baseline authentication requirements (e.g., mandatory MFA, least‑privilege OAuth scopes). Providing a clear, low‑friction alternative reduces the incentive to bypass governance.
- Continuous Process: Treat the inventory as an ongoing activity. New applications will appear regularly; mature organizations embed periodic discovery and mapping into their security operating model, revisiting the session‑layer view on a recurring schedule.
Conclusion and Outlook
The shadow‑AI landscape is maturing alongside the platforms that enable it. Vendors will adjust defaults, and enterprises will refine policies, but the fundamental shift—employees turning natural‑language prompts into live, integrated applications—will persist. Organizations that adopt session‑layer visibility and proactive, continuous governance will be able to harness the productivity gains of vibe‑coding while keeping sensitive data under control. Solutions such as Red Access’s agentless, session‑layer platform aim to deliver exactly that: SSE‑grade insight across any browser or device, deployable in hours, with a free audit available to start the process.
By recognizing that the risk now resides in the build‑to‑publish flow inside the browser, security teams can close the gaps left by traditional tools and turn a potential liability into a managed, innovative capability.