The bane of every CISO is shadow IT. The devices connected to the network that came from home, bought with a corporate credit card, all because somebody just wanted to get their job done. The worst offenders have me sitting in the dark with a shotgun, a bottle of rum, and my dog curled up around my feet, considering a different career. You know those guys who bring unlicensed software into the company and install it because it works so well. That is why I live on a boat. The dog is long gone, and the same is almost true for the rum.
All those free AI accounts being used with company data represent a risk that has no real precedent in shadow IT history. I have looked at the data for some companies as a consultant, and the firewall logs show dozens of free AI services in use at a medium-sized business, hundreds of times a day. Most of it is completely opaque until the CISO starts looking. I am a fan of AI, but you have to know what you are doing when you click send on that prompt.
Threat Model
This chapter addresses two attack models that share a single channel but differ in intent. Both exploit the same blind spot. Both look identical on the wire.
The first is the unintentional insider threat. An employee pastes proprietary source code into ChatGPT to debug a build failure. Another drops a client list into Claude to draft a sales summary. A third uploads a quarterly earnings spreadsheet to a free AI tool to generate charts. None of these people are trying to steal anything. They are trying to get work done, and the AI tool does the job faster than anything else available to them. The Samsung incident in 2023 is the canonical example. Within twenty days of lifting its internal ban on ChatGPT, Samsung’s semiconductor division recorded three separate leaks of proprietary data: source code from a semiconductor measurement database program, code written to identify defective equipment, and the recording of a confidential meeting pasted in to generate minutes. Three different engineers, working independently, none aware of the others, each simply trying to be more productive. Under ChatGPT’s default settings at the time, submitted content could be used for model training. Samsung’s proprietary semiconductor code and internal meeting records were sitting on external servers that Samsung did not control.
The Samsung case got press. What does not get press is that this is happening at nearly every company, every day. According to Cyberhaven’s 2026 AI Adoption and Risk Report, 39.7% of employee AI interactions contain sensitive data. LayerX found that employees who paste into generative AI tools average 6.8 pastes per day, more than half containing corporate information, and a later 2025 LayerX report found that generative AI accounts for 32% of all corporate-to-personal data movement, making it the single largest channel for moving corporate data outside the enterprise perimeter. Netskope found that 47% of generative AI users access these tools through personal accounts, completely bypassing enterprise controls.
The second model is deliberate exfiltration using AI services as a covert channel. A compromised account or a malicious insider uses AI tools to move sensitive data out of the organization through a channel that looks like normal SaaS usage. The attacker does not need a USB drive, a personal email forward, or a file sharing service that DLP is watching. They paste the data into a prompt. The data leaves as an HTTPS POST to a domain your security tools already trust, like api.openai.com or claude.ai. The response comes back as rendered text in the browser. From the network’s perspective, this looks indistinguishable from an employee asking an AI tool a legitimate question. The attacker can extract data in fragments across dozens of sessions, pacing the volume to stay below any threshold that would trigger a review.
What makes both models dangerous is the same structural feature. The data leaves in natural language, embedded in a conversation, through an encrypted channel to a trusted destination. Traditional DLP was built to catch files moving through file transfer channels. It was not built to inspect what people type into web applications that your firewall considers safe.
The attacker in both models needs surprisingly little. For the unintentional insider: a browser, internet access, and a free AI account that takes thirty seconds to create. For the deliberate exfiltration channel: a compromised employee account or a motivated insider, the same browser access, and knowledge that the organization’s security stack treats AI service domains as trusted. Neither model requires malware, privilege escalation, or lateral movement. The attack surface is the browser itself, and the exfiltration channel is a service the company may have explicitly approved or at minimum has not blocked.
The observable artifacts are thin. An unintentional leak produces web traffic to a known AI domain, a pattern of paste operations into a browser tab, and possibly an entry in the AI service’s own logs that the organization cannot access without an enterprise agreement. A deliberate exfiltration produces the same traffic pattern, potentially with more structured pacing and a preference for free tier accounts that have no enterprise audit trail. The distinction between the two is intent, and intent does not appear in a packet capture.
Traditional Tools
The standard toolkit for preventing data loss through SaaS applications has three layers, and most small to mid-sized companies have deployed some version of all three.
Data Loss Prevention at the network and endpoint levels is foundational. Network DLP inspects traffic through the corporate proxy or secure web gateway, looking for patterns that match sensitive data classifications: credit card numbers, Social Security numbers, specific document markings, and regex patterns for proprietary identifiers. Endpoint DLP extends this to the device itself, monitoring clipboard operations, file system access, USB connections, print operations, and application-level data movement. Products in this category include Symantec DLP (now Broadcom), Microsoft Purview, Digital Guardian, and Forcepoint DLP. A CISO who deployed any of these products three to five years ago has a system that catches most file-based exfiltration attempts via email, cloud storage, and removable media.
Cloud Access Security Brokers sit between users and cloud services, providing visibility into which SaaS applications employees are using and applying policy to that usage. A CASB in inline mode decrypts TLS traffic, parses the API calls being made, and applies content inspection rules to uploads and downloads. Products like Netskope, Zscaler, Microsoft Defender for Cloud Apps, and Palo Alto Prisma Access give the security team a dashboard showing which cloud services the organization uses, who uses them, and how much data flows. For traditional SaaS applications like Box, Salesforce, and Google Workspace, a CASB can identify when a user uploads a file containing sensitive data and block or alert on that transaction.
Acceptable use policies and security awareness training form the human layer. The policy says employees must not paste sensitive data into unapproved tools, the training walks employees through the reasons why, and compliance tracking records who completed the course and signed the annual attestation.
These tools do what they were designed to do. Network DLP catches sensitive files moving through monitored channels, CASB provides visibility into SaaS usage and applies content rules to file operations, and policy sets behavioral expectations that training reinforces. Five years ago, this was a reasonable defensive posture against insider data loss.
The Gap
The traditional stack relied on a constraint that was valid until roughly 2023: data exfiltration required moving a recognizable data object through a recognizable data channel.
DLP was designed to catch files, attachments, and structured data patterns moving through email, file transfer, cloud sync, and removable media. The detection logic triggers on file types, data patterns within files, and the channel the file is traversing. A user uploading a spreadsheet full of customer records to a personal Dropbox account produces an event that DLP was built to detect: a file, containing data that matches a classification rule, moving through a channel that policy restricts.
CASB was designed to inspect API calls between users and SaaS applications, applying content rules to the data objects being exchanged. A CASB watching traffic to Salesforce or Box can identify what kind of file is being uploaded and apply classification rules to its contents. The detection logic depends on the data being packaged as a discrete object with identifiable structure.
AI tools broke both assumptions at once. When an employee pastes source code into ChatGPT, the data does not move as a file. It moves as form field content within an HTTPS POST request to a domain that the proxy considers trusted. There is no file attachment for DLP to inspect. There is no structured data object for CASB to classify. The traffic is TLS encrypted to a legitimate service endpoint that the security stack has been told to allow. From the network layer, it looks like a user interacting with a web application, and it is. The CASB sees a normal HTTPS connection to OpenAI or Anthropic and allows it, because the detection logic was built around file operations against cloud storage APIs, not around conversational text submissions to language model endpoints.
The constraint that traditional DLP relied on, that sensitive data would move as a file through a file channel, no longer holds. The constraint that CASB relied on, that data leaving the enterprise would be packaged as a discrete inspectable object sent to a cloud storage or collaboration API, no longer holds either. The data leaves as typed text. It travels through an encrypted session to a trusted host. It arrives at the AI service as unstructured natural language, gets processed, and the response returns as rendered text in the browser. No file was created, no attachment was sent, and no cloud storage API was called. The entire transaction happened inside a conversation that the security stack was not built to read.
This gap is not a theoretical concern. The IBM 2025 Cost of a Data Breach Report found that organizations with high levels of shadow AI paid $670,000 more per breach than those with little or none, and breaches involving shadow AI averaged $4.63 million. IBM’s 2026 edition, released July 29, 2026, found shadow AI involved in 43% of the incidents it studied, more than double the prior year. Those breaches also took longer to identify and contain than the 241-day average, and they disproportionately affected customer PII and intellectual property. The longer detection time is a direct consequence of the gap: the exfiltration is happening through a channel the security tools were not watching, so the time from first exposure to discovery is driven by secondary indicators rather than primary detection.
The policy layer fails for a different reason. Acceptable use policies that say “do not paste sensitive data into AI tools” have no enforcement mechanism. The policy is a statement of expectation. The enforcement requires a technical control that can distinguish between an employee asking an AI tool to summarize a public article and an employee pasting proprietary source code into the same tool, through the same browser, to the same domain, using the same HTTPS connection. No traditional DLP or CASB product ships with that distinction out of the box.
The exposure is also concentrated. Harmonic Security found that just six AI applications accounted for 92.6% of all sensitive data exposure, with source code representing 30% of that exposure, legal discourse 22.3%, and M&A data 12.6%. The data concentrates in a handful of popular tools that employees use because they work, and those tools are precisely the ones that CASB treats as trusted destinations.
AI Augmentation
The defense starts with knowing what you do not know, and what most organizations do not know is which AI services their employees are actually using, how often, and what kind of data is going into them. Building that visibility does not require a new platform purchase. It requires using the log data you already have in a way you have not been using it.
Building the AI service inventory from DNS and proxy logs. Every AI service interaction starts with a DNS lookup and an HTTPS connection. Your DNS resolver logs, proxy logs, and firewall session logs already contain the raw data for an AI usage inventory. The first step is building and maintaining a classification list of AI service domains. This is not a static list you download once. It requires weekly updates as new AI tools appear. Start with the obvious endpoints: api.openai.com, chat.openai.com, claude.ai, api.anthropic.com, gemini.google.com, bard.google.com, copilot.microsoft.com, huggingface.co, perplexity.ai, and the API endpoints for each. Expand it by reviewing DNS query logs for domains you have not classified. A Python script that queries your DNS logs against a maintained AI domain list and produces a weekly report of new, unclassified AI related domains is a weekend project. Feed that list into your proxy or CASB as a custom URL category. At this stage you are watching, and blocking comes later.
The output of this step is a dashboard that answers three questions: which AI services are in use, who is using them, and how much data is moving. Run this for two weeks before making any policy decisions, because those decisions depend on the baseline.
Behavioral baselining of AI usage per user. Once you have the inventory, the next layer is behavioral. Extract from your proxy logs the per user session metadata for AI service connections: timestamp, duration, bytes uploaded, bytes downloaded, frequency, time of day patterns. You are not reading the content of the sessions. You are building a usage profile from metadata alone. Most users fall into predictable patterns. A developer who uses GitHub Copilot sends a consistent volume of requests during working hours. A marketing analyst who uses ChatGPT for copy editing generates sessions of moderate length with small upload volumes.
The behavioral baseline lets you flag deviations. A user who normally sends 50KB per day to AI services suddenly sending 500KB in a single session is worth investigating. A user who normally accesses one AI tool beginning to hit five different free tier AI services in a single week is a signal. A pattern of AI service usage that shifts to off hours, or that correlates with access to sensitive file shares earlier in the same session, is a compound indicator worth alerting on. This analysis can run against your existing SIEM. The data sources are your proxy logs and your file access audit logs, both of which you already collect. The correlation is a set of detection rules that compare AI service usage patterns against the user’s established baseline and against concurrent access to sensitive resources. If you use Splunk, this is a set of saved searches. If you use Microsoft Sentinel, it is an analytics rule that joins proxy log data with file audit events. The engineering time is measured in days, not months.
Content aware analysis without reading the content. The gap in traditional DLP is that it cannot inspect conversational text being submitted to AI services. One approach that does not require you to deploy an inline content inspection proxy is metadata pattern analysis. You cannot read the encrypted payload, but you can read the metadata surrounding it. Look at the volume of data uploaded per session. Look at the ratio of uploaded to downloaded bytes. A normal AI conversation has a small request and a larger response. An exfiltration event, deliberate or not, often inverts that ratio: a large paste operation in the request, followed by a small response. Monitor for sessions where the upload volume exceeds the download volume by a significant margin, or where the upload volume in a single request exceeds a threshold you set based on your baseline data.
If your organization routes AI traffic through a forward proxy that performs TLS inspection (and many organizations already do this for other SaaS applications), you can go further. Deploy a content classification layer at the proxy that applies lightweight regex and NLP classification to the request body of HTTPS POSTs to AI service domains. You are not deploying a new product. You are adding classification rules to your existing proxy. Flag requests that contain patterns matching your data classification taxonomy: source code structures, API key formats, customer record layouts, specific document identifiers that your organization uses. The flag generates an alert for analyst review, not an automatic block. Automatic blocking of AI traffic will push users to personal devices and personal networks, which removes your visibility entirely.
Connecting AI usage to identity and data access. The most powerful detection you can build with existing tools correlates three data sources: your identity provider’s authentication logs, your file access audit logs, and your AI service usage logs. Build a detection that fires when a user accesses a sensitive file share or database, followed within a defined time window by a session with an AI service where the upload volume exceeds your baseline threshold. This compound indicator matters because neither event alone is suspicious. A user accessing customer records is normal for their role. A user interacting with ChatGPT is normal for the organization. A user accessing customer records and then sending an unusually large volume of data to ChatGPT within the next fifteen minutes is a pattern worth investigating.
This detection works for both threat models. The unintentional insider who downloads a customer spreadsheet and then pastes it into an AI tool to generate a summary produces the same compound indicator as the malicious insider who is deliberately extracting customer records through an AI channel. The response differs based on investigation findings, but the detection is the same.
What breaks when this fails. The AI augmentations described here create their own dependencies. The domain classification list must be maintained. If it falls behind, new AI services slip through undetected, and they will, because new AI tools appear weekly. The behavioral baseline must be recalibrated periodically, because legitimate usage patterns change as employees adopt new AI workflows. Assign a cadence: quarterly at minimum. The content classification rules at the proxy produce false positives. A developer pasting open source code into an AI tool will match source code patterns, and that is probably fine. The analyst reviewing the alert needs context about what the user was working on, which means the alert must include enough surrounding data to make a triage decision without a full investigation.
An adversary who understands this detection model can evade it. Pacing exfiltration across many small sessions keeps individual upload volumes below the threshold. Using the same AI tool that the user’s legitimate baseline already includes avoids the new service flag. Timing the exfiltration during normal working hours and at volumes consistent with the user’s usual pattern defeats the behavioral anomaly detection. The manual fallback for all of these is periodic human review of AI usage reports, sampling sessions from high risk users and users with access to the organization’s most sensitive data. Automated detection catches the obvious cases, and targeted review catches the rest, but neither works without the other.
Where to start. If you have nothing in place today, build the AI service inventory from your DNS and proxy logs first. That step alone changes the conversation from “we do not know what AI tools our employees are using” to a specific list of services, users, and data volumes. Everything else builds on that foundation. The inventory takes a week, the behavioral baseline takes two more, and the compound detection rules take another week after that. A month from standing start to working detection, using the log infrastructure you already have.
Works Cited
Cyberhaven Labs. (2026). 2026 AI adoption and risk report. https://www.cyberhaven.com/resources/report/ai-adoption-risk-report-2026
Harmonic Security. (2026, January). Analysis of 22.4 million generative AI prompts [Reported in SecurityBrief, “ChatGPT drives bulk of enterprise generative AI data risk”]. https://securitybrief.news/story/chatgpt-drives-bulk-of-enterprise-generative-ai-data-risk
IBM. (2025). Cost of a data breach report 2025. https://www.ibm.com/reports/data-breach
LayerX Security. (2025). Enterprise GenAI data security report 2025. https://layerxsecurity.com/?p=2387
LayerX Security. (2025). Enterprise AI and SaaS data security report 2025. https://go.layerxsecurity.com/hubfs/LayerX_Enterprise_AI_and_SaaS_Data_Security_Report.pdf
Netskope Threat Labs. (2026). Cloud and threat report: 2026. https://netskope.com/resources/cloud-and-threat-reports/cloud-and-threat-report-2026
The Register. (2023, April 6). Samsung reportedly leaked its own secrets through ChatGPT. https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own
Underhill, K. (2026, July 30). IBM 2026 cost of a data breach report: Key findings. eSecurity Planet. https://www.esecurityplanet.com/cybersecurity/ibm-2026-cost-of-a-data-breach-report-key-findings/
About the Author
