In April 2023, engineers at Samsung’s semiconductor division used ChatGPT to help debug proprietary source code — three separate times in less than a month. The leaked material included internal meeting notes, source code for measuring semiconductor equipment, and data related to a faulty batch. Samsung subsequently banned ChatGPT internally, but the data had already left the building. No malicious actor was involved. No security control caught it in real time. Employees were just trying to do their jobs more efficiently.

This is shadow AI: the unsanctioned use of external AI tools with corporate data. It’s not primarily a story about bad actors — it’s a story about good employees making decisions at the intersection of “this tool is incredibly useful” and “I don’t know what happens to data I submit.” The enterprise’s job isn’t to stop that impulse. It’s to channel it safely.

The Scale of the Problem

Shadow IT — employees using unauthorized software tools — has existed for decades. Cloud storage, consumer messaging apps, and personal email accounts have all gone through cycles of prohibition, tolerance, and eventual formalization. Shadow AI follows the same pattern but is moving faster and carrying higher data sensitivity per interaction.

Cyberhaven, which operates a data loss prevention platform with visibility into enterprise data flows, published research in early 2024 documenting AI adoption patterns across its customer base. Their data showed that a significant portion of data employees paste into AI tools is classified — including source code, customer data, and regulated health information. In one analysis, they found that sensitive data flows to AI tools were doubling roughly every few months, even within organizations that believed they had AI governance policies in place.

The tools employees are actually using span a wide range: ChatGPT (including personal and team accounts), Claude, Microsoft Copilot on personal accounts (distinct from the enterprise-licensed version with data protection addenda), AI-powered coding assistants like GitHub Copilot on personal accounts, AI browser extensions that process page content, and Zapier or Make automations that route corporate data through personal AI accounts. The footprint extends well beyond “someone opened the ChatGPT website.”

What’s being submitted is correspondingly broad. Source code is the most documented category — it’s sensitive, it’s large, and it’s exactly the kind of thing developers paste for “explain this” or “fix this bug.” But the full range includes M&A documents and financial projections, customer lists and PII, internal presentations and strategy documents, legal documents, and HR records.

Gartner has flagged shadow AI as a top emerging risk for enterprise security programs (2024), noting that traditional governance frameworks — built around shadow IT — don’t map cleanly to the AI context because AI tools consume data at the prompt level, making traditional file-transfer detection insufficient.

Why Traditional DLP Doesn’t Catch It

Data loss prevention technology classifies data and blocks or alerts on transfers that violate policy. It was designed for a world where sensitive data leaves the enterprise through recognizable channels: email attachments, USB drives, file uploads to cloud storage, web form submissions of specific file types.

AI prompt submission doesn’t fit this model well. Consider what happens when an employee opens ChatGPT, copies three paragraphs from an internal document, pastes them into the chat, and types “summarize this for a client.” From a network perspective: an HTTPS POST request to chat.openai.com. No file type. No file transfer event. No DLP trigger by default.

Some DLP products have added AI-specific detection in the last 18–24 months, including URL-category policies that apply to known AI endpoints and content inspection rules that fire on large text submissions. But these capabilities are uneven across vendors, and they require explicit configuration — they’re not in the default policy sets that enterprises already have deployed. Most organizations have not yet adapted their DLP policies to specifically cover AI prompt submission.

This creates a gap that is currently very wide.

Threat Taxonomy

Framing shadow AI as a single risk obscures the distinct threats it creates. Each has a different detection surface and different governance response.

Data Exfiltration via AI Prompts

The most straightforward risk: sensitive data submitted to third-party AI services is no longer under enterprise control. The provider’s data handling commitments vary enormously. Free-tier ChatGPT, as of its Terms of Service in 2023–2024, permitted OpenAI to use submitted content for model improvement unless users opt out — an opt-out most casual users don’t make. Enterprise contracts typically include data processing addenda with no-training commitments, but employees using personal accounts get no such protection.

Even with a no-training commitment, the data is processed on the provider’s infrastructure and is subject to any breach or unauthorized access at the provider. The enterprise has no visibility into what was submitted, no audit trail, and no way to demonstrate compliance with data handling obligations to regulators or auditors.

Credential and Secret Exposure

Developers routinely share code with AI assistants for review, debugging, and explanation. Code frequently contains credentials: API keys hardcoded in configuration files, database connection strings, internal service URLs, authentication tokens. A developer who pastes a function into ChatGPT to ask “why is this throwing an exception” may not notice — or not think to remove — the database credentials in the connection string three lines above the function.

This category of risk is particularly acute because the exposure is immediate and the scope can be large: a single pasted code snippet can expose credentials that provide access to production systems.

AI-Assisted Insider Threat Enablement

AI tools are powerful force multipliers for data aggregation and exfiltration. A malicious or disgruntled employee who would previously have spent hours manually copying and summarizing internal documents can now extract, summarize, and reformat large volumes of corporate information in minutes. Shadow AI tools — used outside the enterprise’s visibility — make this capability available without any audit trail.

This risk isn’t the most common scenario, but it’s the one with the highest potential impact. A motivated insider using external AI tools for data extraction creates an attack surface that traditional user behavior analytics (UBA) tools — which look at file access, print events, and USB activity — may not cover.

Shadow AI Pipelines

Beyond direct use, employees are building automation workflows that route corporate data through personal AI accounts. Platforms like Zapier, Make (formerly Integromat), and n8n make it straightforward to create automations that trigger on enterprise events — new emails, calendar invites, CRM updates, Slack messages — and route their content to an AI API for processing.

These pipelines are often well-intentioned: an employee builds a workflow to auto-summarize incoming customer emails and draft responses. The workflow uses the employee’s personal OpenAI API key. The enterprise has no visibility into the data flow, no contract governing the AI provider’s data handling, and often no awareness the pipeline exists.

The footprint of these automations can grow significantly before discovery. Unlike a single chat session, an automated pipeline can continuously route corporate data to an external AI service — potentially including data from systems the employee has access to but the automation was not deliberately designed to pull.

Compliance Violations

Enterprises operating under GDPR, HIPAA, or sector-specific privacy regulations have specific obligations around data processing: they must know who is processing covered data, under what agreements, with what protections. Compliance frameworks like SOC 2 and CCPA impose different obligations (attestation and service-provider contracting models, respectively) but share the same underlying requirement: documented, controlled data handling. Employees submitting personal data or protected health information to AI tools operating outside enterprise contracts create exposure under each framework, in different ways.

Under GDPR, submitting EU data subject PII to an external AI service creates data handling risks that depend on the provider’s role: if the provider acts as a data processor, processing without an approved DPA is unauthorized; if the provider acts as a data controller in its own right (using inputs for its own purposes), the enterprise may be enabling unauthorized transfer of personal data to a third controller without adequate legal basis. Under HIPAA, submitting PHI to a service without a Business Associate Agreement is a compliance violation; breach notification duties depend on a risk assessment of the specific incident, but the unauthorized processing itself violates the HIPAA Privacy and Security Rules. The compliance implications don’t require a breach to materialize — the unauthorized processing is itself the problem.

Detection Approaches

Shadow AI is detectable. Not with certainty, and not with a single control — but organizations that apply multiple detection layers get meaningful visibility. The key is adapting existing controls to the AI context and adding AI-specific visibility where gaps remain.

DLP with AI Endpoint URL Policies

The immediate, deployable step: add AI service URLs to your DLP URL category lists and apply content inspection policies to HTTPS traffic to those endpoints.

The canonical domains to cover include chatgpt.com, chat.openai.com, api.openai.com, claude.ai, api.anthropic.com, gemini.google.com, and the API endpoints for Mistral, Cohere, and other providers your sector uses. Most enterprise DLP platforms (Symantec DLP, Forcepoint, Microsoft Purview) support URL-category policies; you’re creating a new category for AI services and attaching inspection rules to it. Note: hostname-based controls alone cannot distinguish personal accounts from sanctioned enterprise accounts on the same provider domain — an employee’s personal ChatGPT account and a corporate enterprise account share chatgpt.com. Identity-aware controls (SSO enforcement, conditional access, CASB with account-type detection) are needed to enforce the personal-vs-enterprise distinction.

Limitations: this doesn’t catch traffic that bypasses the DLP inspection path — including scripts or automation tools running on unmanaged devices or on cloud infrastructure that routes traffic directly to AI APIs without traversing the enterprise proxy. It also requires SSL inspection to see POST body content over HTTPS — a deployment complexity many organizations have managed for other use cases but that requires careful certificate and bypass configuration.

Browser Extension Monitoring

AI browser extensions — tools that summarize pages, rewrite emails, assist with writing — are a significant and often overlooked shadow AI surface. They execute in-browser, can read page content across all tabs, and submit that content to external AI APIs. A single extension installed by many employees can create a continuous data flow to external AI providers.

Endpoint management platforms (Microsoft Intune, Jamf, CrowdStrike Falcon) provide visibility into installed browser extensions across the fleet. The detection approach: inventory what’s installed, classify extensions by their network behavior (specifically, whether they make API calls to AI providers), and apply allowlisting policies that block unapproved extensions in managed browsers.

This requires endpoint management coverage — unmanaged devices (personal laptops used for work) are a gap. But for corporate-managed endpoints, extension monitoring is a tractable, high-value detection layer.

Network Proxy Classification for AI API Traffic

Enterprise network proxies sit in the request path for browser traffic; next-generation firewalls can identify AI traffic at the application layer even without URL-specific policies. The AI traffic signature — for deployments with SSL/TLS inspection enabled — includes API call patterns (POST requests to /v1/chat/completions, /api/messages, and similar endpoints), response payload sizes consistent with language model output, and distinctive HTTP headers used by AI provider SDKs. Without SSL inspection, NGFWs rely on hostname and IP-based classification, which still identifies the AI service but cannot inspect request content.

Some NGFW vendors (Palo Alto, Zscaler, Netskope) have added AI application categories to their application identification libraries, enabling policy creation and visibility without manual URL list maintenance. This is particularly useful for catching API calls from scripts and automation tools that bypass browser-level DLP.

Network proxy coverage has the same unmanaged-device gap as endpoint monitoring. For organizations with mobile device management and proxy enrollment, coverage can extend to mobile and remote work scenarios; otherwise, it’s limited to on-network or VPN-tunneled traffic.

Behavioral Analytics for Data Volume Anomalies

A different detection angle: rather than classifying the destination, monitor for unusual outbound data patterns to any web service. An employee who begins submitting several hundred kilobytes of text to a web endpoint daily — where that endpoint is a service the enterprise has no relationship with — is exhibiting behavior consistent with shadow AI use, even if the specific destination isn’t yet on a monitoring list.

User and Entity Behavior Analytics (UEBA) tools — including components in Microsoft Sentinel, Splunk UEBA, and Exabeam — can implement this kind of anomaly detection. It requires baselining normal data submission behavior and setting thresholds that flag significant deviations. The false positive rate requires tuning: legitimate web application use involves substantial data submission. But the behavioral pattern for heavy AI use (repeated large submissions to a consistent endpoint) is distinctive enough to be separable from normal web browsing.

CASB Solutions with AI Awareness

Cloud Access Security Brokers sit between users and cloud services, providing visibility and control over cloud application use. CASBs were built for shadow IT governance — the exact problem model that shadow AI extends. Modern CASB solutions from Netskope, McAfee (now Skyhigh Security), and Microsoft Defender for Cloud Apps have added AI application catalogues, enabling policy enforcement (block, alert, or allow-with-logging) for specific AI services by name.

CASB deployment modes vary: API-mode CASBs integrate with SaaS providers directly (limited for AI services that don’t offer CASB integrations), while proxy-mode CASBs intercept traffic inline. The proxy-mode approach provides the most comprehensive coverage and supports real-time blocking, not just after-the-fact logging.

For organizations already running a CASB for SaaS governance, extending it to cover AI services is the path of least resistance. For organizations without a CASB, the AI use case may now provide the justification for deployment — the governance value extends well beyond AI.

Governance Frameworks

Detection tells you what’s happening. Governance determines what you want to happen and makes that achievable for employees.

The AI Acceptable Use Policy

Most enterprises have an acceptable use policy covering computer and network use. Extending it to explicitly address AI tools is now table stakes — but the extension needs to do more than prohibit unauthorized use. Policies that only say “don’t use unauthorized AI tools” will fail the same way shadow IT policies did: employees will use the tools anyway, except now covertly, which is worse from a security standpoint than acknowledged use.

An effective AI acceptable use policy covers:

• Which AI tools are approved for which data classification levels (e.g., approved tools may be used with public or internal-use data; classified, regulated, or customer data requires additional controls)
• Clear guidance on what data types are prohibited in AI inputs (PII, PHI, credentials, trade secrets, M&A-related information) — not just “sensitive data” as an undefined category
• The process to request approval for new AI tools (a path that’s faster than the alternative: employees routing around)
• Consequences for violation — not punitive by default, but specified

The tone matters. Policies framed as “AI is dangerous, here’s what you can’t do” will be read as obstacles. Policies framed as “we want you to use AI effectively, here’s how to do it safely” are more likely to change behavior.

The Sanctioned AI Tool Program

The most effective shadow IT governance strategy has always been to say “yes” to the legitimate need while channeling it through a controlled path. Shadow IT programs that replace an employee’s preferred tool with an approved equivalent consistently outperform pure prohibition. Shadow AI governance works the same way.

A sanctioned AI tool program means:

• Identifying the AI use cases employees actually need (coding assistance, writing assistance, research summaries, data analysis) and matching them to enterprise-licensed tools with appropriate data processing agreements
• Enterprise licensing that includes data processing addenda, no-training commitments, and audit rights — the protections that personal accounts don’t have
• A clear procurement pathway so teams can request AI tools through IT/security rather than defaulting to personal accounts when the approved list doesn’t cover their use case

The common failure mode is a sanctioned list that’s too narrow or too slow. If the approved tool doesn’t do what employees need, or if the approval process takes weeks, employees will route around it. The program needs to be genuinely responsive to demand.

AI Usage Logging and Auditability

For compliance purposes — and for incident response — enterprises need an audit trail of AI tool use. What tools were used? By whom? What data was submitted? Answers to these questions are currently unavailable at most enterprises that haven’t implemented specific controls.

Enterprise AI tool agreements should include logging provisions: the ability to retrieve user-level usage data, including content where legally permitted and technically feasible. Some enterprise AI offerings provide usage dashboards and log exports; others don’t. This should be an evaluation criterion during procurement.

For shadow AI detection and response, the log should capture: user identity, timestamp, tool used, data volume submitted, and — where technically achievable through DLP or CASB — content of what was submitted. Content capture creates its own legal and employee privacy considerations (addressed by consulting employment counsel before implementation), but the metadata layer alone provides significant forensic value.

Data Classification Adapted for AI Context

Traditional data classification schemes were designed for file-level decisions: is this document confidential? The AI context requires a more granular distinction: is a specific piece of content safe to submit to this AI tool?

An employee might have a document classified as “internal use” that contains a section with client PII or a reference to M&A discussions. The document-level classification doesn’t resolve whether the PII section can be pasted into an AI tool. Employees making that judgment call in the moment will often make it incorrectly — not from malice, but because the classification guidance doesn’t reach that level of granularity.

Updating classification guidance to include AI-submission context means adding explicit statements like “internal use data may be submitted to approved AI tools except where it contains any of the following: [list].” This is more operationally specific than most current classification frameworks, but it’s the specificity that employees need to make correct decisions at the prompt level.

Enterprise AI Security Architecture

Governance policy without technical architecture produces policies that are advisory at best. The detection controls above are part of the architecture; the enterprise agreement and procurement side is the other half.

Enterprise Agreements with LLM Providers

For the AI tools the enterprise chooses to sanction, the agreement structure matters as much as the technology. The critical contractual elements are:

Data processing addenda: Formal documentation of the provider’s obligations as a data processor under GDPR, CCPA, and applicable law. This establishes the legal basis for using the tool with covered data.

No-training commitments: Explicit provisions that the enterprise’s data will not be used to train the provider’s models. Most enterprise tiers of major AI providers now include this; it should be confirmed, not assumed.

Audit rights: The ability to audit the provider’s data handling practices and to receive notification of security incidents affecting enterprise data. This is standard in enterprise SaaS agreements; AI providers are not consistently including it in their standard enterprise terms.

Data residency and deletion: Where the enterprise’s data is processed and stored, and the provider’s obligations to delete data at the end of the agreement or upon request.

These provisions require legal review — security teams should be coordinating with counsel on AI procurement in the same way they coordinate on any SaaS procurement involving sensitive data.

On-Premises and Private Cloud Options

For enterprises with the highest sensitivity requirements — defense industrial base, financial services with significant regulatory exposure, healthcare with strict PHI requirements — the goal is to minimize or eliminate data exposure to third-party infrastructure. The options range from keeping data fully on-premises to using dedicated private-cloud deployments with strong isolation guarantees.

Options here are maturing:

Self-hosted open models: Llama 3, Mistral, and similar open-weight models can be deployed on enterprise infrastructure. The operational cost is significant (GPU infrastructure, model maintenance, performance tuning), but for specific high-sensitivity use cases, the capability is now real and the costs are declining.

Private cloud deployments: Azure OpenAI Service and similar offerings allow enterprise deployment of GPT-class models in the provider’s cloud but isolated to the enterprise’s subscription, with no cross-customer data sharing and explicit data processing agreements. This is a middle path between public API access and fully on-premises deployment.

Air-gapped AI: For the most sensitive environments (classified work, air-gapped operational technology networks), dedicated hardware inference appliances running certified models represent the current state of the art. This is specialized and expensive — appropriate for specific use cases, not general enterprise AI adoption.

The architecture choice should match the risk profile of the data being processed. A company-wide writing assistant probably doesn’t need air-gapped deployment; the M&A advisory workflow that processes acquisition target financials probably does.

Integration with Existing Security Infrastructure

Shadow AI governance should integrate with — not replace — existing security infrastructure. The detection controls described above are extensions of existing tools (DLP, CASB, UEBA, endpoint management) rather than greenfield deployments. Organizations that already have these tools deployed are adapting them; organizations that don’t are choosing which investments to prioritize.

The identity layer is particularly important: AI usage monitoring should be tied to identity management (SSO/IdP) so that usage events are attributed to specific users and carry the access context that identity provides. An employee in finance submitting data to an unsanctioned AI tool is a different risk profile than the same behavior from an employee with access to regulated customer data. Identity-aware monitoring makes this distinction.

What Good Looks Like

The organizations that are ahead of this problem share a few common characteristics:

They’ve updated their DLP policies to explicitly cover known AI endpoints — a configuration change, not a new tool purchase.

They’ve established an AI procurement process that’s fast enough to be preferable to shadow use. The approval process for a new AI tool takes days, not months, and has clear criteria.

They’ve deployed at minimum one network-level visibility control (CASB or NGFW AI categorization) that gives them a continuous view of which AI services are being accessed.

They’ve communicated clearly to employees: not “AI is prohibited” but “here are the tools we’ve approved, here’s why we’ve approved them, here’s the process if you need something else.”

And they’ve accepted that perfect coverage isn’t achievable — personal devices, unmanaged endpoints, and travel scenarios will always have gaps. The goal is meaningful visibility over the enterprise’s managed surface and a governance posture that makes the controlled path the path of least resistance.

Shadow AI isn’t going away. The productivity benefits are real, and employees have noticed. The enterprises that handle this well are the ones that treat it as a governance problem to be solved rather than a behavior problem to be prohibited.

---

Sources and further reading:

• Samsung ChatGPT data leak (2023): Widely documented in technology press including The Verge, Ars Technica, and Bloomberg (April 2023). Samsung subsequently implemented an internal AI tool and restricts external AI use.
• Cyberhaven AI Data Movement Report (2024): Cyberhaven’s research documenting enterprise data flows to AI tools, including sensitive data categories. Available at cyberhaven.com.
• Gartner: “Managing the Risks of Shadow AI” (2024). Available to Gartner subscribers. Key findings cited in technology press.
• NIST AI Risk Management Framework (AI RMF 1.0, January 2023): Available at nist.gov/system/files/documents/2023/01/26/AI RMF 1.0.pdf
• CISA/NSA Joint Guidance on Deploying AI Systems Securely (November 2023): Available at cisa.gov
• ICO (UK Information Commissioner’s Office) guidance on using generative AI: ico.org.uk (2024)