Red Access identified more than 380,000 publicly accessible web assets on leading vibe-coding platforms — roughly 5,000 of those looked corporate, and more than 2,000 held sensitive corporate, operational, or personal data exposed on the open web.
Red Access's discovery: scale, scope, and defaults
The investigation described as The Shadow Builders found a vast population of web-accessible artifacts on "vibe-coding" platforms. Many of the corporate-looking applications were deployed without basic access controls; in some cases an application granted administrative access by default to anyone who reached its URL. These exposures spanned six continents and every industry, and the report notes that some organizations continued to pass audits while these exposures were live. The platforms themselves may be audited — but, the report emphasizes, the custom application built on top of them frequently is not.
Vibe coding and Shadow AI: the artifact moved from a prompt to a product
The term "Shadow AI" in the report has shifted from employees pasting prompts into chat to employees building full applications with AI, wiring those applications into production systems, and publishing them on the open internet — often without Security or IT in the room. Vibe coding compresses work that used to take engineering teams months into something a non-developer can ship before lunch: marketing, operations, and finance teams can create tools, connect them to CRMs, ERPs, ticketing systems, or BI platforms, and publish them. Every step of the build — the authoring, the OAuth grants, the data movement, the publish click — is a browser session event, the report says: the build and deployment all happen inside the same tab and same session.
Why mature security stacks still miss these apps
The report lays out why existing controls generate fragments of signal rather than a governable picture. Endpoint detection and response (EDR) sees the browser process, not the build inside it; what a Shadow Builder does looks telemetry‑wise like ordinary, non‑malicious browser activity. Where EDR or an enterprise browser sees deeper, it usually does so only on devices owned and managed by the organization, leaving personal laptops, contractor machines, BYOD devices, and unmanaged browser tabs invisible.
Data loss prevention (DLP) watches enumerated channels and can flag a user pasting regulated data into a known AI chat, but it cannot see a vibe-coded application programmatically connecting via API to a sanctioned BI tool and moving data cloud-to-cloud, effectively bypassing the endpoint. Cloud access security brokers (CASB) were designed for Shadow IT — identifiable SaaS vendors with discoverable identities — and the report says CASBs can’t readily distinguish an unbounded population of custom applications hosted on a platform’s subdomains from the platform itself. Firewalls and SSE see traffic to the platform domain but lack application-as-business-object context, and many SASE/SSE deployments are partial, leaving the unmanaged-device problem unsolved. In short: none of these tools is failing at its job; the new category simply sits in the gaps between them.
Four immediate moves security leaders can take this week
- Start with discovery: Ask employees directly what they've built. The report recommends a workforce-wide prompt framed as inventorying rather than auditing — "If you've built a tool using an AI development platform, please tell us about it" — noting most Shadow Builders are solving real problems and are not hiding malicious intent.
- Map each application: For every surfaced app, capture which corporate systems it touches, how it connects (OAuth, API key, manual upload), and whether it's publicly reachable. The report highlights public reachability as the most actionable short-term signal.
- Establish a sanctioned path: Give builders somewhere to report and a lower-friction approval lane: name approved platforms, define acceptable data categories, and set minimum authentication standards.
- Move to continuous discovery: Accept that this is not a one-time inventory. Vibe-coded applications will keep being created; the recommended mature posture is continuous discovery at the session layer where the activity actually happens.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: The report implies they must shift some visibility to the session layer to see the full build path — the platform used, the corporate systems connected, the data flows, and the publish event attributable to a specific person and application instance, regardless of device or network.
- Procurement and governance leaders: The suggested response is to provide an approved, lower‑friction path for builders, name accepted platforms, and set minimum authentication and data‑handling standards so useful internal work does not become a public exposure.
- End users and business teams: The report frames these builders as competent employees solving real problems; the recommended approach is collaborative discovery and defined, sanctioned alternatives rather than punitive audits that discourage disclosure.
The central point in the report is spare and stark: the session is where the build lives, and existing architectures leave that layer fragmented. Platforms will keep recalibrating defaults, and none of those adaptations is finished; the exposure exists in most enterprises right now. The only immediate remedy the report prescribes is organizational — discover, map, sanction, and keep looking at the layer where the activity happens — and, where desired, consider session-layer tools that claim to provide visibility and governance across any browser and any device.
