Shadow AI: From harmless prompts to exposed products
Shadow AI app security refers to the risks that arise when employees use AI-driven development platforms to build and deploy applications that connect to enterprise systems without formal security review, leaving sensitive corporate data exposed through weak or missing access controls and governance. In Red Access’s Shadow Builders research, more than 380,000 publicly accessible web assets were discovered on leading “vibe-coding” platforms, where anyone can describe an idea and get a working app in minutes. Around 5,000 of those assets appeared corporate. Over 2,000 contained sensitive corporate, operational, or personal data and were deployed on the open internet with no basic authentication, in many cases granting admin access by default to anyone who knew the URL. These apps were live while organizations were passing internal audits, highlighting how far traditional controls lag behind AI-led development.
How vibe-coded apps bypass access controls
Vibe coding compresses months of engineering into a morning’s work for a non-developer. A marketing manager can spin up a campaign tracker tied into the business intelligence tool, an operations lead can wire a vendor-intake form into the ticketing system, and finance staff can pull invoice data into a board dashboard before week’s end. The problem is not their intent but the absence of access control best practices. Many of these AI-generated applications are published directly to the public web, inheriting whatever configuration the builder guessed through—often none at all. According to Red Access, “more than 2,000 [corporate-looking apps] held sensitive corporate, operational, or personal data – sitting on the open web, deployed without basic access controls.” The result is large-scale enterprise data exposure from apps that were never logged, reviewed, or integrated into standard supply chain security processes.
Why mature security stacks never saw the risk
The exposures did not occur because security tools failed, but because AI app development lives in the gaps between them. Endpoint detection and response sees a browser process, not an employee building an app inside a tab, so AI app security issues look like normal web use. Data loss prevention watches known channels and can flag a user pasting regulated data into a chatbot, but it cannot see a vibe-coded app pulling data via APIs directly from sanctioned BI or CRM tools. CASB is tuned for recognizable SaaS vendors, not thousands of custom subdomain apps that all appear as one approved platform. Firewalls and SSE see traffic to the platform’s domain but have no context that a specific URL is a production-grade business application. Unmanaged or personal devices further blind these tools, leaving a full build pipeline invisible from start to publish.
Session-layer blind spots and the new supply chain
Every critical step in this new supply chain happens in a single browser session: describing the app, granting OAuth access to production systems, moving data into the app, and clicking “publish” to expose it at a public URL. Traditional tools sit around this activity, not inside it, so they only see fragments. That makes access control vulnerabilities and enterprise data exposure hard to correlate into a clear risk. The platforms themselves may be audited, but the individual applications built on top of them rarely are, which creates a shadow layer of custom micro‑apps directly wired into systems of record. In effect, AI-generated apps form a new kind of software supply chain that bypasses standard onboarding, vendor review, and continuous monitoring. Without visibility at the session layer, security teams cannot reliably know which AI-built assets exist, what they connect to, or whether they are open to the internet.
What organizations should do now
Fixing these gaps starts with discovery, not another tool purchase. Security teams should ask staff directly what they have built with AI development platforms, framing it as inventory gathering rather than an audit to encourage honest responses. Each discovered application should be mapped: which corporate systems it connects to, what method it uses (OAuth, API keys, manual uploads), and whether it is publicly reachable. Public exposure is the first clear remediation target. Organizations also need a sanctioned path for AI-built apps—approved platforms, defined data categories, and minimum authentication standards that lower friction compared with “quiet” unsanctioned builds. Finally, continuous asset discovery for AI-built applications is essential, ideally at the browser session layer where the build, integration, and publish events all occur. Without ongoing visibility, new wave Shadow AI apps will keep slipping past governance and putting sensitive data at risk.