Shadow AI used to be about employees pasting sensitive data into **ChatGPT**. Now, it's evolved into something far more dangerous: employees building full-fledged applications with AI, integrating them into production systems, and publishing them on the open internet, all without the knowledge or involvement of security or IT teams. ## The New Shadow AI Isn't About Prompts, It's About Products Vibe coding, the broader landscape of AI-driven development platforms, empowers anyone to create working applications by simply describing their desired functionality. This has drastically reduced development time, enabling non-developers to deploy applications rapidly. These applications are frequently connected to sanctioned production systems – CRMs, ERPs, ticketing tools, BI platforms – and often published to the open internet with minimal or no access controls. While the individuals building these applications are not malicious, their actions expose sensitive data and create significant security risks. ## Why Traditional Security Stacks Fail to Detect Shadow AI Traditional security tools like Endpoint Detection and Response (EDR), Data Loss Prevention (DLP), and Cloud Access Security Brokers (CASB) often fail to detect Shadow AI activity. This is because: * **EDR:** Focuses on browser processes and may not recognize the build process within a vibe-coding platform as malicious activity. It also struggles with BYOD devices. * **DLP:** Monitors enumerated channels and may not detect data moving cloud-to-cloud via APIs. * **CASB:** Designed for sanctioned SaaS vendors and struggles to differentiate custom applications hosted on a vibe-coding platform's subdomains. * **Firewall/SSE:** Lack the application-as-business-object context and often leave unmanaged devices exposed. These tools are not necessarily failing, but the nature of Shadow AI allows it to exist in the gaps between these layers, preventing a comprehensive security picture. ## Gaining Visibility Through Session Layer Monitoring Vibe coding is essentially a web-session event. Every step, from the build process to the OAuth grant and data transfer, occurs within the session layer. Therefore, a control positioned at the session layer can provide a complete view of the build path, including the platforms used, connected systems, data movement, and deployment events. This approach offers visibility regardless of the browser used, the network path taken, or whether the device is corporate-issued or personal. ## Immediate Steps to Mitigate Shadow AI Risks **Red Access** recommends the following actions: 1. **Discovery:** Directly engage employees to identify AI-driven tools they have built, framing the discussion as an inventory exercise rather than an audit. 2. **Mapping:** Document the corporate systems connected to each application, the connection method (OAuth, API key, etc.), and whether the application is publicly accessible. 3. **Sanctioned Path:** Establish approved platforms, define acceptable data categories, and set minimum authentication standards. 4. **Continuous Discovery:** Recognize that Shadow AI is an ongoing issue, and continuous monitoring is essential. By focusing on session-layer visibility and implementing proactive discovery and governance measures, organizations can effectively mitigate the risks associated with Shadow AI. **Red Access** offers an agentless, session-layer security platform designed to provide visibility and governance across any browser and device. [**Request your free audit.**](https://info.redaccess.io/request-a-demo) Found this article interesting? <span>This article is a contributed piece from one of our valued partners.</span> Follow us on <a rel="noopener" href="https://news.google.com/publications/CAAqLQgKIidDQklTRndnTWFoTUtFWFJvWldoaFkydGxjbTVsZDNNdVkyOXRLQUFQAQ">Google News</a>, and <a rel="noopener" href="https://www.linkedin.com/company/thehackernews/">LinkedIn</a> to read more exclusive content we post.