Shadow AI risk: The 4 behaviors that create real exposure

TL;DR

• Two employees on the same AI license can carry completely different risks, so a tool count tells you almost nothing about your exposure.
• Four behaviors carry the real risk: sensitive data in prompts, unreviewed AI output driving real decisions, AI features switched on inside approved SaaS platforms, and prompt content reaching third parties.
• Run discovery and publish a usage policy in parallel. Waiting for a complete inventory means running unguided for another quarter, and the inventory needs to  be as close to real-time as possible.

Two people use the same AI assistant all week. One drafts meeting notes with it. The other pastes a customer contract in to get the indemnity clause summarized. Same tool, same license, same line on your inventory, but only one of them created a problem you have to deal with. Using an approved tool doesn’t make the behavior safe. The difference is how much exposure the use case creates based on data involved.

Before we get into the behaviors around shadow AI, we have to define it first. We know that shadow AI includes the tools you don’t know your employees are using—think someone using a personal ChatGPT account instead of the approved enterprise AI tool. But it goes beyond that when it comes to risk. Shadow AI also includes approved AI tools that aren’t monitored for usage, because sanctioned tools carry risk, too. 

The 4 types of shadow AI risk

1. Sensitive data exposure through AI prompts

This is the most common one, and the least dramatic. Someone pastes source code, a customer record, an unreleased forecast, or a full contract into a public AI tool to get a faster answer. No malice, no policy violation they’re aware of, and depending on the tool’s terms and retention settings, no practical way to pull it back.

What makes this hard to govern is that it’s usually the people under the tightest deadlines, handling the most sensitive material.

2. Ungoverned decision-making

AI output landing in real work with nobody checking it. A vendor security questionnaire answered from an AI summary of a policy document. A customer-facing incident note drafted by an assistant and sent without review. A risk rating assigned partly because a model suggested it.

The data never left. The decision was still made on unreviewed output, and nothing in your logs distinguishes that decision from one a human reasoned through.

The expansion of this risk is unrestricted and overly-permissive tool calling. If you give an AI system (shadow or not) access to write code, send emails, or whatever else you need it to do, but no one is monitoring it and it does something bad like accessing sensitive keys, your ungoverned mess just gets bigger. 

3. AI features inside tools you already approved

Your customer relationship platform shipped an AI summarizer last quarter. Your ticketing system added an assistant. Your video conferencing tool now takes notes, which means it now processes every word of every meeting through a model.

None of these appear on a shadow AI tool list, because the underlying vendor passed your security review. The AI feature that arrived 18 months later did not. This category grows on its own, without anyone in your organization deciding anything.

4. Prompt content reaching third-party AI systems

Employees using AI features inside a partner’s or vendor’s platform, where your data goes into a model you have no relationship with and no visibility into. A contractor running your material through their own AI stack counts here too. Provenance matters. New AI tools show up constantly, and for a lot of them, you have no idea who’s actually running the model, where your prompts get processed, or how long they’re kept. Some are operated in jurisdictions with broad government-access laws. Some carry terms you’d never agree to if you read them. None of this shows up in your telemetry—it lives in contracts and Data Processing Agreements (DPAs), which is why it goes unexamined the longest. A DPA you don’t have (or never read) means no real visibility at all. So evaluate this deliberately; don’t just assume it’s fine.

Where non-human identity risk fits

Shadow AI usage risk and non-human identity risk get discussed together, and they’re related without being the same problem.

Non-human identity risk is about machine and service accounts: an AI agent with a provisioned identity, real permissions, and credentials that may outlive the project that created them. It’s an access governance problem, and the fix looks like access governance work.

Shadow AI usage risk is about people. What they put into AI tools, what they do with what comes out, and which AI features are running inside software they already had. Most of it happens without any identity being provisioned at all. And when it is logged under a person’s name, there’s often no way to tell who—or what—actually did it.

Both are worth work. They need different controls, and treating one as a subset of the other means whichever you deprioritize goes unaddressed.

Practical discovery, without waiting for perfect visibility

You still need to see what’s in use. Four sources get you most of the way, and none of them require a new purchase.

• Network and SaaS traffic. Outbound traffic to known AI service domains, pulled from your existing web proxy or secure web gateway logs. Blunt instrument, fast answer.
• Single sign-on (SSO) and expense records. SSO logs show sanctioned access. Expense reports and corporate card data catch the tools people bought themselves, which is usually the more interesting list.
• Vendor feature audits. Go back through your approved SaaS platforms and ask which have shipped AI features since their last review, and whether those features are on or off (or if you can even control that). It’s the fastest way to find risk you already own.
• Department conversations. Ask teams what they’re using and what they use it for. Framed as help rather than audit, this surfaces the usage patterns telemetry can’t show you.

Sequence matters less than people think. Start discovery now, and publish a usage policy in parallel. Waiting for a complete inventory is a losing game, so start now and update your inventory as frequently as possible. 

Write the policy around how people use AI

An approved-tools list is easy to write and easy to ignore, because it can’t answer the questions people actually have. A usage policy answers four:

1. What categories of data never go into an AI tool, sanctioned or not, stated in terms people recognize from their own work.
2. Which decisions require human review of AI output before they leave the building.
3. Who to tell when an approved tool ships a new AI feature, and what happens next.
4. Where to ask when the policy doesn’t obviously cover the situation. This one matters most. A policy without a low-friction question path gets guessed at.

Pair those four answers with the discovery work above, and you’re governing behavior.