Shadow AI: The New Shadow IT
Shadow AI: The New Shadow IT#
Shadow AI is what happens when the productivity pull of generative AI outruns the governance infrastructure of organizations trying to contain it. It is Shadow IT with a faster clock speed, a bigger blast radius, and a compliance liability your legal team hasn’t fully priced in yet.
The Pattern We’ve Seen Before#
Security teams have spent the better part of two decades chasing Shadow IT — the proliferation of unsanctioned applications, services, and devices that employees adopt because approved tools are too slow, too clunky, or simply don’t exist yet. Dropbox replaced the shared drive. Personal Gmail replaced the corporate mail server that filtered everything. Slack wormed its way in before IT had a sanctioned alternative.
The pattern was always the same: productivity pressure → employee workaround → IT discovers it after the fact → governance scramble. The risk was real but bounded. A file in the wrong place. A credential in the wrong system. Painful, but recoverable.
Shadow AI inherits that entire playbook and adds something genuinely new. When an employee pastes sensitive data into an unsanctioned AI tool, that data isn’t just in the wrong place — it has been consumed by infrastructure you don’t control, potentially retained, potentially used for model training, with no audit trail and no retrieval path. The exposure is asymmetric in a way Shadow IT rarely was.
Defining the Threat Surface#
Shadow AI encompasses any use of AI tools — generative AI assistants, code completion tools, document summarizers, chatbots — outside of organizational IT governance. It includes:
- Consumer AI tools on personal accounts (ChatGPT Free, Claude.ai, Gemini) used for work tasks
- Browser extensions and plugins with AI capabilities that intercept data flows
- Third-party AI integrations added to SaaS products without IT review
- AI-assisted development tools used without security vetting (Cursor, GitHub Copilot on personal accounts)
- Vibe coding — using AI to generate production code without security review or developer oversight
The scale is no longer theoretical. Current data from 2024–2025 paints a clear picture:
| Metric | Figure | Source |
|---|---|---|
| Employees using unsanctioned AI tools | ~49–56% | BlackFog / IDC 2025 |
| Organizations lacking AI data-flow visibility | 86% | Reco State of Shadow AI 2025 |
| Organizations lacking basic controls to prevent AI data exposure | 83% | Reco 2025 |
| Organizations with policies to detect Shadow AI | 37% | IBM 2025 |
| GenAI enterprise traffic surge in 2024 | 890%+ | Menlo Security |
| Gartner prediction: enterprises with AI-related security incidents by 2030 | 40%+ | Gartner |
The math is straightforward: the majority of organizations have no meaningful visibility into how their data flows in and out of AI tools, while the majority of employees are using those tools anyway.
Why Employees Do It — and Why That Matters#
Understanding motivation is prerequisite to solving the problem. Employees aren’t adopting Shadow AI out of malice. They’re doing it because:
Productivity pressure is real. A BlackFog study found that 60% of employees would take security risks to meet deadlines. When a deadline is today and the AI procurement process takes six weeks, the math is obvious.
Approved alternatives are often worse. Consumer-tier ChatGPT is faster, more capable, and easier to use than many enterprise AI deployments. The gap creates pull.
The risk isn’t visible. Pasting meeting notes into a chatbot doesn’t feel like a data breach. There’s no immediate consequence, no error message, no audit ping.
Leadership sets the tone — badly. IBM data shows that roughly half of employees using unsanctioned AI include enterprise leaders among the offenders. When executives bypass governance, the implicit message is that governance is optional.
This matters for the security response. A governance strategy built entirely on prohibition will fail for the same reason blocking Dropbox failed — employees will route around it. The most effective countermeasure is making sanctioned alternatives faster to access and clearly better to use than the consumer workaround.
Vibe Coding: When the Risk Writes the Code#
Shadow AI in productivity workflows is dangerous. Shadow AI in the development pipeline is a different category of problem.
Vibe coding — a term coined to describe the practice of prompting AI to generate entire code blocks, functions, or applications without the developer fully reading, understanding, or security-reviewing the output — has moved from a novelty to a normalized workflow in engineering teams across the industry.
The security data is alarming:
- 53% of AI-generated code contains security issues that passed initial review before shipping (Autonama 2025)
- Across 5,600 vibe-coded applications, researchers found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 instances of exposed PII
- Stanford and academic studies report that over 60% of AI-written programs contain security flaws
- Georgia Tech’s Vibe Security Radar project tracked 74 confirmed CVEs directly attributable to AI coding tools as of mid-2025
The root cause isn’t the AI generating bad code on purpose — it’s that LLMs are trained on the vast corpus of publicly available code, including the poorly written, outdated, and vulnerable portions of it. The model doesn’t know that strcpy is unsafe or that the SQL query it just generated is injectable. It produces code that looks right and often runs right, but carries subtle flaws that a security-aware developer would catch during review.
The compounding factor is uncritical acceptance. Vibe coding’s failure mode isn’t that developers don’t know the code might have issues — it’s that the cognitive ease of the workflow creates pressure to skip the review. “It looks fine” becomes a substitute for “I verified it.”
Common vulnerability classes in AI-generated code#
- Injection vulnerabilities (SQL, command, prompt) — AI models often generate queries without parameterization
- Hardcoded secrets — API keys, tokens, and credentials embedded directly in generated code
- Insecure deserialization — common in generated serialization/parsing routines
- Missing authentication/authorization checks — AI fills in functionality but often omits access control
- Dependency confusion — AI may suggest package names that don’t exist, which threat actors register (package hallucination attacks)
- Memory corruption — in systems languages, AI-generated pointer arithmetic and buffer handling may be unsound
Real-World Incidents: The Scorecard So Far#
Shadow AI is no longer a theoretical risk category. The incident record is accumulating.
Samsung (April 2023)#
The defining case study. Within 20 days of allowing employees to access ChatGPT, Samsung experienced three separate data exposure incidents:
- An engineer pasted proprietary semiconductor source code into ChatGPT to debug a database issue
- Another employee submitted an entire internal meeting recording to generate meeting minutes
- A third pasted internal documentation for debugging assistance
All three interactions sent confidential intellectual property to OpenAI’s servers. Samsung banned generative AI tools company-wide immediately after — then quietly re-enabled access with new security protocols once approved tooling was in place. The lesson: prohibition without alternatives is temporary.
Financial Sector Response (2023)#
Within weeks of Samsung’s incident, the following institutions restricted or banned employee ChatGPT access:
- JPMorgan Chase
- Goldman Sachs
- Bank of America
- Citigroup
- Deutsche Bank
- Wells Fargo
The pattern reveals the sector’s read of the risk: the data flowing into these tools is a liability regardless of whether a breach occurs on the AI vendor’s side — the act of transmission is itself the exposure event.
The Broader Trend#
IBM’s 2025 Cost of a Data Breach report found that breaches involving Shadow AI cost organizations $650,000 more on average than standard data breaches, and that 1 in 5 organizations has already experienced a breach linked to Shadow AI use. High-shadow-AI organizations reported more PII compromise (65%) and intellectual property theft (40%) in breach events.
Compliance: The Hidden Multiplier#
The security risk is the part security teams worry about. The compliance liability is the part that gets organizations fined.
Every time an employee pastes regulated data into an unsanctioned AI tool, they may be triggering obligations under:
| Regulation | Trigger | Potential Exposure |
|---|---|---|
| GDPR | EU personal data processed by unauthorized third party | Up to 4% of global annual revenue |
| HIPAA | Protected health information sent to external AI system | $100–$50,000 per violation, criminal referral |
| PCI DSS | Cardholder data in scope of unsanctioned processing | Loss of PCI compliance certification |
| EU AI Act | Deployment of high-risk AI systems without risk assessment | Tiered fines up to €35M or 7% global revenue |
| SEC | Material non-public information exposure via AI | Insider trading and disclosure violations |
A single employee action — pasting patient records into a free chatbot — can trigger HIPAA notification obligations, GDPR breach reporting windows (72 hours), and potentially SEC disclosure requirements if the data is material. Most organizations have no detection mechanism that would surface this event.
Detection: Finding What You Can’t See#
Shadow AI is hard to detect by definition — that’s what makes it shadow. However, there are meaningful signal sources:
Network-level visibility
- Monitor DNS and HTTP traffic for connections to AI API endpoints (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com)
- Flag large outbound POST requests to known AI service domains — these often correlate with prompt submission
- DLP rules on outbound data to AI endpoints, particularly for data classified as PII, IP, or confidential
Identity and access layer
- OAuth token grants from corporate SSO to AI SaaS tools
- Browser extension inventories — many AI tools live here
- SaaS Management Platform (SMP) visibility into AI-category app registrations
Development pipeline
- Static analysis scans for AI-generated code patterns (hallucinated packages, missing input validation common in generated output)
- SAST/DAST integration into CI/CD to catch vulnerability classes common in AI-generated code
- Pre-commit hooks scanning for hardcoded secrets
Behavioral signals
- Anomalous clipboard or data export activity prior to known AI tool connections
- Bulk document access followed by network connections to AI endpoints
Building a Shadow AI Governance Program#
Governance that works focuses on data boundaries and fast approved alternatives, not blanket prohibitions that employees will circumvent. The structure that’s emerging in mature organizations uses a tiered model:
Tier 1: Approved — No Restrictions Beyond Standard Data Handling#
Enterprise-provisioned AI tools with signed DPAs, SOC 2 Type II certification, no training on customer data by default, and GDPR Article 28 compliance for EU data. Examples: Microsoft Copilot (M365), Google Workspace AI features, internally hosted models.
Tier 2: Limited Use — Approved With Data Classification Rules#
Consumer or mid-tier AI tools that may be used for non-sensitive work. Employees may use these tools for tasks involving public information or internally-generated content that isn’t regulated. Personal health data, source code, customer data, and financial records are explicitly prohibited.
Tier 3: Prohibited — High Risk or Non-Compliant#
Any AI tool that doesn’t meet minimum data processing requirements, lacks a DPA, or operates in jurisdictions with data sovereignty conflicts. Use triggers incident response.
Core Program Components#
1. Policy with teeth and speed A policy nobody has read isn’t a policy. Annual training isn’t sufficient given the pace of AI adoption. AI-specific security awareness needs to be embedded in onboarding and reinforced quarterly, with concrete examples employees recognize from their own workflows.
2. Accelerated procurement The fastest path to reducing Shadow AI adoption is making the approved alternative available faster than employees can set up the workaround. If the procurement process takes six weeks, employees will not wait six weeks.
3. Non-punitive incident reporting Good-faith disclosure of accidental Shadow AI use should be rewarded, not penalized. Organizations that make incident reporting punitive get fewer reports — which means they find out about breaches during regulatory investigations instead of from their own employees.
4. Developer-specific controls The vibe coding threat requires developer-specific governance: approved AI coding tools (enterprise Copilot, Claude for Enterprise), mandatory security review gates before AI-generated code ships, and SAST integration that’s aware of AI-generation patterns.
5. Continuous monitoring Point-in-time audits catch what was true on the day of the audit. Shadow AI moves faster than quarterly reviews. Continuous SaaS visibility and network monitoring is the baseline.
The Right Framing for 2025 and Beyond#
Shadow AI is not a problem that gets solved once. The attack surface will expand as AI capabilities grow, as new tool categories emerge (AI agents, autonomous coding systems, AI-embedded SaaS features), and as the productivity pull intensifies. The organizations that manage it well will be the ones that treat governance as continuous, not episodic.
The comparison to Shadow IT is instructive not just as a threat analogy, but as a maturity map. It took the industry roughly a decade to develop SaaS management platforms, CASB tools, and mature policies for unsanctioned software. Shadow AI is compressing that timeline by force — the compliance and breach risk is too acute to allow a decade of drift.
The core security principles that apply are familiar: visibility before control, understand the workflow before blocking it, make the secure path the easy path. What’s different is the urgency, the velocity of adoption, and the fact that the data that left the building may be genuinely unrecoverable.
Key Takeaways#
- ~50% of employees are using unsanctioned AI tools at work; most organizations lack visibility or controls to detect this
- Shadow AI differs from Shadow IT in kind, not just degree — data doesn’t just move to the wrong place, it’s consumed by third-party infrastructure
- Vibe coding introduces a distinct code-security risk: AI-generated code is often functional but vulnerable, and workflow pressure discourages security review
- Samsung’s 2023 incident remains the canonical case study: three exposures in 20 days, all from routine productivity use
- Compliance liability is automatic — GDPR, HIPAA, and PCI obligations may trigger from a single employee action involving regulated data
- Governance works through alternatives and visibility, not prohibition — employees will route around blanket bans
- Detection requires layered signals: network monitoring, DLP, SaaS management, and developer pipeline controls combined
Sources#
- 2025 State of Shadow AI Report — Reco
- Shadow AI Threat Grows — BlackFog Research
- Shadow AI: How Unsanctioned Tools Create Invisible Risk — OffSec
- ~Half of Employees Using Unsanctioned AI Tools — CIO
- What Is Shadow AI? — Palo Alto Networks
- The Rise of Shadow AI: Auditing Unauthorized AI Tools — ISACA 2025
- From Shadow IT to Shadow AI — ISACA Newsletter Vol. 19
- Vibe Coding Security Risks: Why 53% of AI Code Has Security Holes — Autonama
- Security Risks of Vibe Coding and LLM Assistants — Kaspersky
- Passing the Security Vibe Check — Databricks Blog
- AI-Generated Code Security Risks — Veracode
- Samsung ChatGPT Data Leak: 3 Incidents in 20 Days — AuthentEch
- Samsung Engineers Feed Sensitive Data to ChatGPT — Dark Reading
- Shadow AI Forcing a Rethink of Enterprise Governance — Dark Reading
- Is Shadow AI Undermining Your Compliance? — SHI
- Shadow AI: The Silent Cyber Risk Every CISO Must Confront — MetricStream
- Shadow AI in 76% of Organizations — Digital Applied