The risks of shadow AI are real and by now, most are aware. But mitigating that risk isn’t as easy as it may seem. When we talk to companies about shadow AI, most have done the following:
- Wrote an AI usage policy
- Approved a few tools org-wide
- Tried to block unapproved AI tools
And it’s not enough.
These are all important steps, but akin to buying a fancy safe without locking the door. Blocking AI sounds nice, but impossible. As long as your employees will benefit from adopting new AI, they will find ways to use it. AI is expanding across interfaces and popping up within every SaaS tool. With the number of tools expanding daily, your attempt to block usage doesn’t actually curb usage.
We’ll explain how to prevent the risks that come with shadow AI below.
Why Shadow AI Policies Fail on Their Own
A shadow AI policy defines which AI tools employees may use, on which tiers and accounts, with which categories of data, and what happens when someone needs a tool that is not on the list. You need one. It gives employees clarity, it gives legal a documented position when a regulator or customer asks how you govern AI, and it turns "nobody told me" into a settled question. Write it and keep it short enough that people actually read it.
Then be honest about what it does not do.
The policy as a playbook fails for three specific reasons:
It changes a document, not a behavior. Cyberhaven Labs found that 34.8% of data shared with AI tools is now sensitive, up from 10.7% two years earlier. That tripling happened during the exact period when most enterprises rolled out their AI policies. Employees did not miss the memo. They read it, weighed it against a deadline, and made the same trade they make with every friction-heavy control: the work wins.
Bans relocate the problem to where you have zero visibility. Block ChatGPT on the corporate network and the usage moves to a personal account on a personal phone, where no proxy log, CASB category, or endpoint agent will ever see it. The exposure did not shrink. Your ability to observe it did. As of 2025, 73.8% to 94.4% of workplace ChatGPT or Gemini accounts are non-corporate, which means the bulk of AI activity was already happening outside the tiers your contracts and controls cover before you blocked anything.
Enforcement-by-blame targets your best people. Mid-level employees are the heaviest shadow AI users, out-using their managers by roughly 3.5x. These are not careless employees; they are the ones under the most delivery pressure, using AI to hit it. A mitigation program built on catching and punishing them turns your security team against your highest-output staff and teaches everyone else to hide their usage better.
There is a deeper structural issue underneath all three: you cannot inventory your way out of a data-behavior problem. Shadow IT was a list of unsanctioned apps you could discover, block, or onboard. Shadow AI is a question of what data is moving into which model, on which tier, through which integration, prompt by prompt. A policy cannot see any of that, and neither can an app inventory.
How to Mitigate Shadow AI Risks: The Three Levers That Matter
Effective shadow AI mitigation rests on three levers, in this order:
- Continuous visibility and detection, because you cannot control usage you cannot see, and the usage changes weekly.
- Deep access controls, governing tier, model, skills, integrations, and the data inside prompts, not just which domains are blocked.
- A paved path, making the sanctioned option faster than the workaround, because shadow AI is a friction problem as much as a control problem.
1. Continuous Visibility and Detection (Not a One-Time Audit)
The first lever is knowing what is actually happening, all the time. Not what the SaaS inventory said in Q1. Not what the annual audit found. What AI tools were being used, where, what tiers, what models, and what data went into which AI tool this week.
One-time audits fail because the surface will not hold still, capturing one frame of a constantly moving picture. And they generally are not deep or broad enough.
AI usage in a real enterprise runs through the browser, through desktop and mobile apps, through multi-model routers that silently hand your prompt to whichever backend model is cheapest that day, through agent workflows that act without a human touching each step, and through AI features embedded in SaaS tools you approved years before those features existed. A point-in-time discovery exercise captures one frame of a moving picture. Knowing that 200 employees use a given tool tells you almost nothing. Knowing that one of them pasted a customer contract into its free tier on Tuesday tells you exactly where your exposure is.
Detection is its own discipline, with distinct layers, tools, and blind spots. Whatever detection capability you build must run continuously and see down to the level of tiers, models, and data-in-prompt, because that is the level the next lever operates at.
2. Deep Access Controls (Tier, Model, Skills, Integrations, Data-in-Prompt)
The second lever is where mitigation becomes engineering instead of a memo, and it is the lever most guidance skips entirely. The standard control vocabulary for shadow AI is allow or block, applied per tool. That granularity is wrong for this problem, because the risk was never just which tool. It is which tier, which model, which permissions, and which data. Four controls matter.
Enforce the right tier. The gap between an enterprise AI plan and a consumer one is contractual: enterprise tiers typically carve your data out of training and define retention, while free and consumer tiers historically have not. An employee using a personal free account for work erases that protection even when the tool itself is approved. And with 73.8% to 94.4% of workplace ChatGPT and Gemini accounts being non-corporate, tier drift is the default state, not the exception. A real control detects that a session is running on a personal or free account and steers or blocks it, rather than treating all traffic to an approved domain as safe.
Enforce the right model. Multi-model routers and AI tools with model-switching features mean the tool an employee opens is no longer the model that processes their data. A sanctioned assistant can route a prompt to an unvetted third-party model with no signal to the user and no BAA or DPA covering the destination. Model-level control means sensitive data can only be processed by models you have actually vetted, regardless of which front-end it entered through.
Scope agents, skills, and integrations to least privilege. To make an AI assistant useful, employees grant it access, and those OAuth grants tend to be broad, standing, and forgotten. Each one is a non-human identity holding a persistent token into your systems, and agentic AI turns that access into autonomous action. The control here is the same discipline you apply to human identities: least-privilege scopes on every grant, an inventory of which AI tools hold which tokens, and revocation of anything standing that no longer has an owner. IBM's finding sharpens the point: 13% of organizations reported a breach of their AI models or applications, and 97% of those lacked proper AI access controls. When AI systems get breached, missing access control is almost always at the scene.
Control the data inside the prompt. This is the channel traditional DLP misses, because DLP was built to pattern-match structured data in structured channels, a card number in an email, a tagged file on a USB drive. Shadow AI leaks through free-text prompts, pasted meeting transcripts, uploaded files, and agent-mediated retrievals that never resemble a classic exfiltration event. Data-in-prompt control means catching the sensitive content at the moment it enters an AI interaction and stopping or redacting it there, before it reaches the model. Given that 34.8% of what employees share with AI is sensitive, this is not an edge-case control. It governs a third of the traffic.
Run the four together and the posture changes shape. Instead of "ChatGPT: allowed," you get "ChatGPT: allowed on the enterprise tier, on corporate accounts, routing only to approved models, with scoped integrations, and with customer data stopped at the prompt."
3. A Paved Path: Make Sanctioned AI the Easy Choice
The third lever is the one competitors' guidance misses most consistently, because it does not look like security work. Shadow AI is what employees pick when the approved route is slower than the workaround. Every week your intake process takes to evaluate a tool is a week your top performers spend using it anyway, on personal accounts, because the work would not wait. Mitigation that ignores this dynamic is a dam with the pressure still rising behind it.
The paved path has three components. First, fast intake: a request-to-decision cycle for new AI tools measured in days, with a lightweight review tier for low-risk requests, because a 90-day review queue is functionally a ban and produces a ban's results. Second, a sanctioned catalog that tracks demand: if your detection data shows 40 engineers using an unsanctioned coding assistant, that is telling you what to evaluate next.
Finally, you need default-good options: enterprise tiers of the tools employees already prefer, provisioned with corporate accounts, so the compliant choice is the one already open in their browser. This sounds simpler than it is, as AI tool preferences differ greatly across functions. Legal will prefer using a tool like Harvey while designers may use Adobe or Figma. And within each may live multiple models and tiers. We recommend allowing as many tools as you can, preferring visibility over hidden usage.
The security logic is straightforward risk arithmetic. An approved tool on an enterprise contract, with a training carve-out, a DPA, and monitored usage, is a known risk you have priced and mitigated. The shadow alternative an employee reaches for instead is an unknown risk with none of that. You do not get to choose whether employees use AI; adoption data settled that. You only get to choose whether their usage happens inside contracts and controls or outside them. "Better path" beats "blocked path" because blocked paths get bypassed and better paths get used.
Shadow AI Best Practices Checklist
The full program, table stakes and levers together:
- Publish a short, specific AI policy. Which tools, which tiers, which data categories, and how to request something new. One page beats twelve.
- Buy enterprise tiers of the tools employees already use. Training carve-outs, DPAs where personal data is processed, BAAs where PHI is, retention terms you have read.
- Run continuous AI usage monitoring, not annual audits. Cover the browser, desktop and mobile apps, model routers, agents, and embedded SaaS AI, down to the prompt level.
- Enforce tier and account type. Detect personal and free-tier accounts on corporate work and steer them to the enterprise plan.
- Vet and enforce at the model level. No sensitive data to unvetted models, including through multi-model routers.
- Apply least privilege to AI integrations. Scope every OAuth grant, inventory non-human identities, revoke standing tokens without owners.
- Control sensitive data at the prompt. Stop or redact secrets, source code, customer data, and regulated data before they enter an AI interaction.
- Stand up fast intake and a living sanctioned catalog. Decisions in days, catalog updated from real demand signals.
- Fix permission hygiene before broad assistant rollouts. Enterprise assistants surface everything a user can technically reach; over-permissioning becomes exposure at the speed of a prompt.
Prevent, Detect, or Govern? Where Mitigation Actually Happens
Teams researching this problem ask three different questions, and it is worth being precise about how the answers fit together, because they are layers of one program rather than alternatives.
Prevention means stopping the risky event before it happens: paved-path adoption that removes the reason to go around you, plus deep access controls that block the dangerous action, the wrong tier, the unvetted model, the sensitive prompt, in real time. Prevention is where shadow AI mitigation does most of its work. Leaked data cannot be recalled, so a control that fires after the fact has already failed.
Detection means seeing AI usage as it happens across every surface it actually occurs on. Detection cannot undo an exposure, but it is the prerequisite for everything else: prevention rules are only as good as the visibility that informs them, and response is only as fast as discovery.
Governance means the wrapper: policy, training, procurement standards, audit trails, and evidence for regulators and customers. Governance makes the program defensible and repeatable. It does not, by itself, stop a single paste.
So, can you prevent shadow AI entirely? No. New tools ship daily, AI is now embedded in software you approved years ago, and your most productive people will always probe the edges of what is allowed. What you can prevent is the harm: the sensitive prompt to the free tier, the unvetted model in the routing path, the standing token nobody owns. Mitigation is prevention aimed at the data rather than at the tool list, with detection feeding it and governance wrapping it.
