Shadow AI: The Insider Threat Your Security Stack Can't See

Your sales manager is summarizing a client proposal in ChatGPT. Your legal team is using an AI writing tool to draft contracts. Your developer is asking an AI assistant to explain proprietary code. None of these tools went through IT approval. None of the data that just left your organization triggered a single alert.

This is what shadow AI looks like in practice. Nobody is trying to leak anything. They are trying to get work done faster. That is what makes it genuinely hard to address - the intent is completely legitimate, and the security exposure is completely real at the same time.

What Shadow AI Actually Looks Like

When someone in security talks about insider threat, the image that comes to mind is usually a disgruntled employee copying files before they quit. That category exists, but it is not where most organizations bleed data. Most data walks out the door through people who are trying to do their jobs well.

Shadow AI works the same way. When an employee uses an AI tool to get work done faster, the natural thing is to provide context. That means pasting the actual document, not a sanitized version. It means including real customer names, revenue numbers, deal terms - because vague input produces useless output. The more sensitive the work, the more sensitive the data that goes into the prompt.

In a single AI session, an employee can share more organizational context than would pass through traditional DLP systems in a month. And they do it without hesitation because the intent is to be productive.

The Samsung case from 2023 is the most documented example: engineers pasted proprietary source code into ChatGPT across three separate incidents within one month, all while trying to debug it faster. The company banned the tool after discovering what had happened. But Samsung's situation became public. Most organizations are sitting on the same problem and have no idea.

Why Your Current Controls Miss It

DLP tools were built for a different problem. They catch files going out by email, USB drives, bulk downloads to personal storage. They are good at those things. They were not designed to parse what an employee typed into a browser-based AI chat, or understand that asking an AI to "clean up this contract" just transmitted confidential deal terms to a third-party server.

Endpoint monitoring has the same blind spot. If an employee opens a browser and goes to ChatGPT, that traffic looks identical to any other HTTPS session. Without specific DNS or proxy logging for AI service domains, which most organizations do not have configured, nothing shows up in the logs.

So the picture most security teams have of their own data exposure is simply wrong. There is a category of sensitive data leaving the organization every day that does not appear in any report, has not been mapped by compliance, and has never been presented to the board.

The Regulatory Dimension Most Organizations Are Missing

Under GDPR, sending personal data to a third-party AI provider without a valid legal basis or data processing agreement is a transfer violation. The intent is irrelevant. The employee was trying to be productive - that does not change the legal exposure. The transfer happened, the obligation applies, and depending on the data involved, mandatory notification to a supervisory authority may be required.

Italy's data protection authority banned ChatGPT in 2023 specifically because of unauthorized data processing concerns. Germany, France, and Spain launched parallel investigations. The message from regulators was not subtle.

The same framework applies under HIPAA for health data, PCI-DSS for payment card data, and sector-specific regulations across financial services, healthcare, and critical infrastructure. In each case, sending regulated data to an unapproved AI provider creates direct liability.

In most organizations, the DPIA for shadow AI usage does not exist because nobody declared the usage to begin with. The DPO has no inventory of which AI tools employees are using. The security team has no traffic data showing AI service connections. And regulators are starting to ask specifically about AI governance programs during audits.

The Attack Surface You Are Handing Attackers

Set the regulatory piece aside for a moment. There is a separate security problem that is less discussed but just as real.

When employees use unapproved AI tools regularly, those providers accumulate a detailed picture of your organization. Your deals. Your code. Your strategy documents. Your HR issues. That data sits on infrastructure you have not vetted, under security standards you have not audited, with breach notification timelines that are not your vendor's legal obligation to meet on your schedule.

AI providers have been breached. In early 2025, an AI service provider suffered an incident that exposed conversation history for paying users. The organizations whose employees had used that service had no idea their data was there, no contractual notification rights, and no incident response plan for that scenario.

The vendor risk dimension of shadow AI is almost universally unmanaged. The AI tools employees chose to use last week are not in your vendor registry. They have not gone through a security questionnaire. There is no DPA in place. And you will not find out about a breach until it makes the news.

What the Right Response Looks Like

The first instinct is usually to block. Block the domains, issue a policy, send a memo. I understand why - but in practice, this makes the visibility problem worse. Employees blocked from AI tools they rely on will switch to personal devices or home networks. The data still moves. You just lose whatever logging you had.

The effective response is to build a framework employees can actually use, not one that drives the behavior underground.

Start with discovery. Before you can govern, you need to know what exists. DNS and proxy logs will tell you which AI domains are being accessed and at what volume. Employee surveys will tell you the use cases - often more revealing than the technical logs. Map the current state before designing the response.

Build an approved tooling list with data tiers. Not a blanket approval for all AI use. A specific list: these tools are approved, these are not. And critically: for approved tools, here is what data you can share - public information, internal documents with no personal data, anonymized data - and here is what you cannot share without explicit authorization: personal data, IP, regulated information, client-confidential material. The data classification rules matter more than the tool approval.

Implement technical controls at the DNS and proxy layer. Block unapproved AI domains at the network level - not as a permanent measure, but as a backstop that makes the approved path the path of least resistance. If approved tools are available and easy to access, most employees will use them. If the only way to access an unapproved tool is to route around the corporate network, the friction alone reduces casual usage significantly.

Update your DLP policies for conversational AI data flows. This means working with your DLP vendor on AI-aware policies, adding AI service domains to your monitoring scope, and developing detection logic for the types of sensitive data most likely to appear in prompts: customer identifiers, financial figures, source code patterns, contract language. It is not perfect detection, but it is far better than no detection.

Address the compliance gap directly. Have your data protection officer conduct a shadow AI audit. Establish which AI tools need data processing agreements. Run a DPIA for the approved tools. Document the policy. When a regulator asks what you have done about AI data governance, the answer needs to be more than "we told people not to use it."

Why This Needs to Be a Leadership Conversation

Most CISOs I speak with are already aware of shadow AI as a risk. The challenge is not technical knowledge - it is organizational. The business wants to accelerate AI adoption. Security governance is perceived as the thing that slows that down. So the conversation stalls.

Shadow AI needs to be framed as a business risk, not a compliance checkbox. When employees paste client data into an unvetted AI tool, the exposure is regulatory, legal, reputational, and competitive. The information your organization has that competitors do not is a real asset. If it is sitting on a third-party AI provider's servers with no contractual controls around it, that asset is at risk.

The CISO's job in this conversation is not to slow down AI adoption. It is to build the framework that makes AI adoption sustainable. Those are different things. Done right, the governance structure enables more AI use, not less, because employees have clear guidance on what is approved and what is off-limits.

Organizations that get ahead of this will have built that framework before an incident forces the conversation. That is a much easier position to be in.

The Bottom Line

Employees are going to use AI. That is not a security problem - it is a reality. The security problem is the absence of any governance around how they use it, what data goes in, and which providers are approved to hold that data.

Discovery, an approved tooling list, network-level controls, updated DLP policies, and a compliance review. None of this requires a large budget. All of it requires someone deciding to treat shadow AI as a priority before a breach or a regulatory inquiry forces the issue.

This is the second article in a five-part series on AI and enterprise security. Next: why AI governance policies fail without board-level accountability, and what it takes to build that in.