Shadow AI: From Helpful Apps to Enterprise Data Exposure
Shadow AI is the spread of AI-built applications created outside formal IT oversight, where non-developers use AI platforms to build and publish tools that quietly connect to live corporate systems and expose sensitive data through missing access controls. In Red Access’s Shadow Builders report, researchers scanned leading “vibe-coding” platforms and found more than 380,000 publicly accessible web assets, with roughly 5,000 appearing to be corporate. Over 2,000 of those apps held sensitive corporate, operational, or personal data yet lacked basic access controls, often granting admin rights to anyone who knew the URL, with no exploitation required. This is a new kind of enterprise data exposure: not a rogue SaaS signup, but custom mini‑apps wired into CRMs, ERPs, ticketing tools, and BI platforms by well‑meaning employees under pressure to move fast.
How AI App Speed Creates Access Control Misconfiguration
Vibe coding compresses months of development into hours, inviting non-technical staff to describe what they want and get a live application in return. Marketing teams build campaign trackers, operations teams build vendor intake forms, and finance teams assemble board dashboards—then connect them directly to production systems and, often, publish them to the open internet. Under tight deadlines, access control misconfiguration is almost guaranteed: default-public deployments, weak or missing authentication, and admin-level privileges tied to a shared URL. The result is a quiet wave of AI app security vulnerabilities embedded inside ordinary business workflows. Builders are not bypassing rules out of malice; they are following the cues the platforms give them, while governance, security training, and guardrails lag behind. The artifact has changed from a single AI prompt to a live product, and the risk surface has expanded with it.
Why Traditional Security Stacks Failed to See 380,000 Public Assets
The exposure of more than 380,000 public assets shows how AI-built applications slip through gaps in today’s security stack. Endpoint detection and response tools see a browser process, not a user building and publishing an app inside a tab. Data loss prevention focuses on known channels, so it can flag someone pasting records into a chat, but not a vibe-coded app moving data cloud-to-cloud via API. CASB tools are tuned for SaaS vendors with clear identities, not thousands of custom apps sitting on a single platform’s subdomains. Firewall and SSE products see traffic to a legitimate domain but lack context about the specific application or its access model. None of these tools are broken; the activity lives at the session layer, where identity, OAuth grants, data flows, and publish events all occur in one seamless browser session that current controls rarely monitor end-to-end.
Managing Supply Chain Security Risks in AI-Built Apps
These AI-generated apps are now part of the digital supply chain, pulling data from sanctioned systems and shaping decisions, yet they bypass normal procurement, architecture, and security review. That creates supply chain security risks inside the enterprise itself: untracked integrations, opaque dependencies on AI platforms, and fragmented audit trails around who granted which access and when. According to Red Access, the platform underneath may be audited, but the applications built on top of it are not. To reduce enterprise data exposure, organizations need new vetting paths for AI-generated code and configurations: inventories of apps and their connections, policies defining acceptable data types, and minimum authentication standards for anything exposed to the public web. Without these steps, every enthusiastic “citizen developer” can unintentionally add another blind spot to the enterprise attack surface.
A Practical Playbook: Discover, Map, Sanction, and Monitor
Fixing this problem starts with visibility rather than new tools. Security leaders should begin with discovery by asking staff what they have built on AI development platforms, framing it as inventory, not a hunt for violations. Next comes mapping: for each surfaced application, record which corporate systems it connects to, how it authenticates, and whether the URL is publicly reachable—the strongest short-term signal of risk. Then define a sanctioned path that names approved platforms, clarifies safe data categories, and sets baseline access control requirements, so builders know where to go instead of hiding their work. Finally, accept that this is not a one-time project. New AI-built apps appear every week, so monitoring must move closer to the session layer, where build actions, OAuth grants, data flows, and publish events can be tied back to real users and governed continuously.
