What your employees paste into AI
The 2026 Verizon Data Breach Investigations Report did something useful this year: it counted. Across its corpus it analyzed 858,440 data-loss-prevention events that involved an upload to a generative AI tool, then ranked what was being sent by frequency. Source code came first, and by a wide margin. Images were second. Structured data, the kind that lives in a spreadsheet or a database export, was third.
That ordering is the whole story. The single most common thing a person hands to a public model is the thing your company is built on. Not a stray password, not a customer record by accident, but the proprietary logic an engineer pasted in to get a stack trace explained or a function refactored.
Why this is an insider-threat problem, not a tooling problem
It is tempting to read those numbers and reach for a ban. Block the domains, add a line to the handbook, move on. That misreads where the risk lives. A January 2026 BlackFog survey of 2,000 workers found 49% admitting they use AI tools their employer never sanctioned. Microsoft's own threat intelligence puts the share of organizations that have detected unauthorized AI use in their networks at 73%, while only 28% have any real monitoring or blocking in place.
So the typical company is in a specific and uncomfortable position. Half the staff is already pasting work into something. Three out of four security teams know it is happening. Fewer than one in three can say what went where. The gap between "we know people do this" and "we can see what they sent" is the actual exposure.
Shadow AI earns the "shadow" label because it leaves almost no trace by the old rules. Shadow IT at least meant someone installed software or stood up a server. Shadow AI needs a browser tab and a login the company never provisioned. There is no asset to inventory, no agent to push, no port to scan. An HR coordinator polishing a termination letter, a finance analyst summarizing a forecast, a developer debugging a service: each one can move sensitive data outside the building in the time it takes to paste and hit enter, and your logs show a normal HTTPS request to a popular site.
The part that makes it dangerous
Two properties stack on top of each other here.
The data may not come back. Depending on the product and the account tier, prompts can be retained and used to improve the model. When that happens, a Q3 forecast or a block of unreleased source has effectively left your control and joined a training corpus you do not own and cannot recall. A deletion request after the fact does not unwind that.
You learn about it late, or never. This is the same failure shape that makes a silently stalled cron job so hard to catch. Nothing errors. No alert fires. The leak is an absence of a signal, not the presence of one, and traditional security tooling is built to flag presence: a malware hash, a known-bad IP, a credential used from a strange country. A trusted employee on a managed laptop opening a reputable AI site trips none of that.
What moves the needle
The honest first move is discovery, not policy. A policy written before you can measure compliance is a document, not a control. You want to answer one question with evidence: which AI services are people on our network using, and at what volume? That signal already exists in places most teams do not look.
- Egress and DNS logs. Your resolver and your proxy already see every request to every AI endpoint. Aggregating those by destination and by user turns "we think people use ChatGPT" into a ranked list with names and counts.
- The CASB or secure web gateway you may already own. Many of these can classify AI traffic and, on the inspecting tiers, see the payload of an upload rather than only the destination.
- Browser and endpoint telemetry. The paste itself happens in a browser. Extensions and endpoint DLP can flag a large clipboard drop into a known AI text box before it leaves the machine.
Once you can see the traffic, the rest follows in order. Name the approved tools and the tier with a no-training data agreement, so people have a sanctioned path instead of a personal account. Write an acceptable-use rule that says what may and may not be pasted, in plain language, with examples. Keep an audit log of what is flowing to which service, so that when someone asks "did our codebase end up in a public model," you can answer from records rather than from hope.
That last point is the one most programs skip and the one regulators and customers increasingly ask about. The difference between a tense incident-response call and a routine one is whether you have a trail. "We blocked it" is a posture. "Here is exactly what was sent, by whom, on which day, and here is the gap we have since closed" is a control.
The takeaway
The DBIR number worth remembering is not 858,440. It is the ranking. Your source code is the most likely thing to walk out the door through an AI text box, your team is already using these tools whether or not you approved them, and the leak makes no noise on its way out. You cannot govern what you cannot see, so start with visibility you already have sitting in your DNS and proxy logs, then build the policy and the audit trail on top of evidence instead of assumption.
Pick one week. Pull the AI-destination traffic for it, rank it by volume and by user, and look at the top of the list. Almost everyone who runs that query is surprised by what is there, which is the point: the surprise is the measure of how little you could see before.