Once upon a time, Shadow AI meant staff members copying and pasting confidential information into ChatGPT. Today, it signifies something far more significant: workers creating complete applications with AI, linking them to live production environments, and launching them on the public internet — all without involving Security or IT teams.
The output has evolved from a simple prompt to a full-fledged product. And the threat landscape has expanded right alongside it.
In The Shadow Builders report (download it here), a groundbreaking category-wide study featured in May by Axios, WIRED, and VentureBeat, Red Access uncovered over 380,000 publicly reachable web assets spread across the top vibe-coding platforms.
Approximately 5,000 appeared to belong to businesses. Over 2,000 of those contained confidential corporate, operational, or personally identifiable data — sitting exposed on the open web, deployed with no fundamental access protections, frequently handing out admin-level access to anyone who stumbled upon the URL. Six continents. Every sector reviewed. No hacking needed.
All while these organizations were passing their audits with flying colors.
The latest Shadow AI isn’t about prompts — it’s about products.
Vibe coding — the broader ecosystem of AI-powered development tools that lets anyone construct a functional application simply by explaining what they want — has turned what once took engineering teams months into something a non-technical employee can deploy before lunch break.
A marketing manager creates a campaign tracking tool and hooks it up to the BI platform where the actual data lives. An operations lead builds a vendor registration form and links it to the ticketing system. A finance group assembles a board-ready dashboard and feeds invoice data into it by end of week. Those applications get wired into approved production systems — CRMs, ERPs, ticketing platforms, BI tools — and are regularly pushed out onto the open internet, with whatever security settings the creator happened to pick. Often, that means none at all.
The individuals doing this aren’t acting with bad intent. They’re capable employees addressing real challenges faster than their organization can respond, doing precisely what the platforms encouraged them to do. The platforms aren’t the enemy either — they’re fulfilling what their core users requested. What hasn’t caught up are the safeguards, both technical and cultural, that govern what happens after the application goes live.
This isn’t Shadow IT in the traditional sense. Shadow IT had limits: when a team signed up for a Trello account on a corporate card without notifying anyone, the data lived inside an unapproved SaaS tool, but at minimum there were identity controls, audit trails, and a governance surface. Shadow Builders flip that model on its head. The application is purpose-built, the data is custom-imported, the integrations tie straight into live production systems of record, and the end product is frequently published on the open internet. The underlying platform might be audited; the app constructed on top of it isn’t. There’s the builder, the platform, and the URL. IT? Usually nowhere to be found.
Why even a well-established security stack still fails to catch this
The first instinct of a CISO reviewing these figures is to audit their tools. EDR is active. DLP is set up. CASB is in place. Firewall and SSE are running. Some organizations have even rolled out an enterprise browser. Each of those defenses is performing its intended function. The problem lives in the spaces between them.
EDR sees the browser process, not the application being built inside it. To an endpoint agent, someone working on a vibe-coding platform looks identical to a user casually browsing news sites — the same signature of telemetry, nothing suspicious. Where modern EDR or an enterprise browser does peer deeper, it only does so on organization-owned devices and within managed browsers. Personal laptops, contractor devices, BYOD machines, and personal-browser windows are, by nature, completely invisible.
DLP monitors known transfer channels. It can flag someone pasting sensitive data into a recognized AI chat window. But it can’t detect a vibe-coded application making a programmatic connection to an approved BI tool via API, shuttling data from cloud to cloud without ever touching the endpoint.
CASB was designed for Shadow IT — for SaaS vendors with identifiable footprints. It can’t easily tell an unlimited collection of custom apps hosted on a vibe-coding platform’s subdomains apart from the platform itself. The entire population typically shows up as a single approved SaaS vendor.
Firewall and SSE see traffic heading toward the platform’s domain but lack the application-level business context. And most SASE/SSE rollouts are incomplete — even the most advanced ones leave the unmanaged-device gap wide open.
None of these tools are failing. The problem simply exists across the cracks that the current architecture creates between layers, producing scattered pieces of data that never come together into a single, manageable picture.
Where real visibility actually needs to be
From start to finish, vibe coding is a web-session event. The building happens in the browser. The OAuth authorization that connects the new application to a sanctioned enterprise system happens in the browser. The data the app revolves around flows through that session. The deployment happens in the browser — the publish button that transforms the build into a live application on a public URL is just another click inside the same tab where everything else occurred.
Every stage takes place at the session layer. Not next to it. Right within it.
A security control positioned at the session layer can therefore observe the entire build journey — not just a sliver of it. The platform being used. The business systems it connects to, and through what method. The data flowing in and out. The publish action that pushes the app onto the open internet. Traceable to a specific individual and a specific application instance, no matter which browser was used or which route the traffic followed. And critically, regardless of whether the device is a company-issued laptop or a contractor’s personal computer.
Steps to take this week
Four actions. None of them require purchasing a new tool.
Begin with discovery. Ask your employees directly what they’ve built. Most Shadow Builders are creating useful tools and have nothing to hide — how you frame the ask matters enormously. A workforce-wide message — if you’ve built something using an AI development platform, we’d love to hear about it. This isn’t an audit. We’re simply building an inventory — will get much further than a policy announcement or a new tool rollout.
Then categorize. For each application discovered, document which corporate systems it connects to, how (OAuth, API key, manual upload — each leaves a different audit trail), and whether it’s publicly accessible. Public accessibility is the most urgent signal to address in the near term.
Create an approved channel. Give Shadow Builders a way to report in. List the accepted platforms, define what data types are permissible, and establish a baseline authentication requirement. It’s far less obstructive than the alternative, which is them keeping it to themselves entirely.
And then recognize that this isn’t a one-off inventory exercise. Vibe-coded applications will keep being created; whatever picture you assemble this month will be outdated by next month. The right long-term approach is ongoing discovery at the layer where the actual work is happening.
This category will keep evolving. Platforms will keep adjusting their defaults. None of these changes have reached a steady state. The risk is present in most organizations right now.
Red Access is the agentless, session-layer security platform purpose-built for exactly this challenge — SSE-grade visibility and governance at the session itself, across any browser, any device, including unmanaged ones. Up and running in hours. Request your free audit.
