How to prevent shadow AI in your organization

Most shadow AI never shows up in your software inventory, so there’s no installer to flag and no admin rights to escalate. An employee opens a public chatbot in a browser you’ve already approved, pastes in a block of source code or a customer spreadsheet, and the data has left the business before any endpoint control has a reason to fire.

The data-leakage risk is already visible in employee behavior. A 2025 global study by the University of Melbourne and KPMG found that almost half of employees who use AI at work admit to using it in ways that go against company policies, including uploading sensitive company information (such as financial, sales, or customer data) into free public AI tools.

That makes shadow AI a visibility problem first and a policy problem second. Banning AI tools outright doesn’t solve it; it just pushes the work onto personal devices where you can’t see it at all. So here’s how to actually prevent shadow AI.

A note on scope: the audit and containment steps below target Windows endpoints managed through an RMM. The browser and data steps rely on Microsoft and Google tooling, because that is where browser-only AI use and sensitive data become visible.

Why shadow AI is a growing risk

Shadow AI isn’t a fringe behavior you can wait out. In most organizations, AI usage is outpacing AI governance, and the data flowing into unmanaged AI services is exactly the kind IT is responsible for keeping contained. For the team managing the fleet, that means a growing share of sensitive work is happening in places existing controls were never built to see.

Microsoft and LinkedIn’s 2024 Work Trend Index surveyed 31,000 knowledge workers across 31 markets and found that 75% were already using generative AI at work. Of those users, 78% were bringing their own AI tools rather than using ones their organization provided, rising to 80% at small and medium-sized companies. Only 39% had received any AI training from their employer, and 52% said they were reluctant to admit using AI for their most important tasks.

» Learn more: What AI data governance reveals about trustworthy AI agents

What’s leaving the business

The AI tool itself is only part of the risk. What gets pasted into it is a separate problem. IBM’s Cost of a Data Breach Report 2026 found that 43% of breached organizations reported security incidents involving shadow AI, up from 20% the year before.

And since AI technology is evolving so rapidly, many organizations aren’t set up to catch potential governance issues. IBM found that 68% of organizations with AI-related breaches lacked AI-governance policies, and only 19% reported coordination between their governance and security teams.

» Need help? Here’s how to build an IT governance framework that works

What cleanup actually costs

When shadow AI does lead to a breach, it’s expensive. IBM also reported that security incidents involving shadow AI cost an average of 400,000 above the 2026 global average of 6 million on average, roughly $1 million above that average.

One of the best-documented examples comes from Samsung Electronics. In early 2023, shortly after the company began allowing employees to use ChatGPT, engineers pasted internal source code into the service to help with their work.

Nobody installed unauthorized software or bypassed a control. The tool was approved, but the data wasn’t. Once that code sat on an external provider’s servers, Samsung had no practical way to retrieve or delete it, so the response had to happen at the organizational level instead.

Here’s what they did:

• Restrict generative AI on company-owned computers, tablets, and phones, and on its internal networks
• Warn that violations could lead to termination
• Ask staff not to submit company information through AI tools on personal devices either
• Begin building internal AI tools for software development, summarization, and translation to replace what employees had been getting from public services

That’s the real cost of shadow AI for IT. It isn’t one leaked file but an organization-wide restriction, a security review, and an internal build, all triggered by a few accidental uploads.

» Learn more about the spread of shadow IT and what shadow IT is really costing your business

What shadow AI is and what it takes to catch it

Most organizations already have controls aimed at unauthorized software, but they often just create a false sense of coverage. Catching shadow AI takes a clear definition, an honest look at where existing restrictions stop, and layered controls that each cover what the others can’t see.

What counts as shadow AI

Shadow AI is any use of AI tools or services without organizational approval or oversight, which covers more than unapproved apps. An approved tool used in an unapproved way (such as a personal account on a sanctioned service or restricted data submitted to an allowed chatbot) is shadow AI too.

In practice, it shows up in several forms:

• Browser-based services: Public chatbots and AI assistants opened in an approved browser.
• Personal accounts: Employees signing into AI services with personal credentials instead of corporate identities.
• Browser extensions: AI writing, summarization, and meeting tools that can read page content.
• Desktop clients: Installed applications such as the ChatGPT Windows app.
• Local models: Tools like Ollama and LM Studio that run models directly on the endpoint.
• API access: Scripts and internal tools calling AI services programmatically.

Where existing controls fall short

The most common gap is controlling software installation without controlling web services. It’s standard organizational practice to remove local admin rights, maintain an approved software catalog, and assume unauthorized applications are covered, but none of that actually stops an employee from opening a public AI service in an approved browser and pasting in corporate data.

The acceptable-use policy often has the same blind spot. If it restricts unauthorized software but says nothing about externally hosted AI services, then employees responsible for shadow AI haven’t broken any rules or bypassed controls. The policy simply doesn’t cover the activity.

Closing that gap means defining AI use separately in policy, being sure to include the following:

• Approved services and accounts
• Prohibited data classifications
• Rules for browser-based services, extensions, APIs, and locally installed tools

Each of those rules then needs technical enforcement behind it. Policy and controls have to describe the same boundary.

The layers that close the gap

No single tool or solution sees every form of shadow AI. Each of these layers answers a different question:

Atera’s RMM provides the endpoint layer. Software Inventory gives a centralized view of conventionally installed applications across managed devices, including name, version, publisher, and install date. Remote scripting extends that view to what inventory alone won’t surface, such as per-user installations in individual profiles, local model tools like Ollama, AI-related processes and services, and browser extensions audited profile by profile.

How to detect, contain, and prevent shadow AI across your fleet

The layered model only works if each layer is put into practice, and here are the key steps you need to follow to do that.

Step 1: Build a baseline and audit your endpoints

Start with what an RMM agent already shows you, then use scripts to reach what inventory won’t surface, such as per-user installs, local model tools, and browser extensions that often live inside individual user profiles. That means a script running under the RMM’s own account needs to look into each profile directly rather than relying on its own %LOCALAPPDATA%.

Using Atera’s Software Inventory and remote scripting, follow these steps:

1. Review the application list in Atera’s Software Inventory to establish your starting baseline of conventionally installed software
2. Enumerate machine-wide installs by querying
   HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall* and HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall*
3. Enumerate per-user installs from loaded user hives under Registry::HKEY_USERS\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall*
4. Enumerate local user profiles and check each profile’s application directories, since not every user hive will be loaded when the script runs
5. Collect running processes, services, and executable paths to catch portable or per-user AI clients that don’t register as installed software
6. Enumerate each user’s Chrome and Edge profile directories and read the manifest.json file for every installed extension
7. Record each extension’s ID, name, version, permissions, host_permissions, and update_url. Give priority to extensions requesting broad host access, such as <all_urls>, since they can read the content of any page the user visits
8. Compare every finding against your approved software and extension baseline
9. Log each result with hostname, user, application or extension, version, path, detection source, and approved or unapproved status

Run the audit across the fleet with Atera’s remote scripting, targeting the devices or device groups you need. To keep the baseline current, schedule it as a recurring maintenance script through an automation profile, and if writing the audit script is the bottleneck, AI Copilot can generate it from a plain-language description of these checks.

The registry paths above are Windows-specific. For macOS and Linux endpoints, run equivalent checks through the same remote scripting approach, such as listing the /Applications folder and each user’s browser extension directories.

Step 2: Contain high-risk tools

When the audit turns up a high-risk AI application, act only on endpoints where it was positively detected. A blanket push across the whole fleet risks false positives and unnecessary disruption.

Here’s an example that uses the ChatGPT Windows app, which installs from the Microsoft Store:

1. Preserve the evidence that established the finding, including hostname, logged-on user, application name and version, executable path, running process, installation source, and detection time.
2. Check with the user’s manager (and HR or legal, if your policy requires it) before removing anything, and confirm the app doesn’t hold local data the user still needs.
3. Target the containment script only at the endpoints in that finding.
4. Test the script on a single endpoint before rolling it out. Microsoft Store apps install per user rather than machine-wide, so the script has to run in a context that can see that user’s apps, and it also needs WinGet to be available in that context.
5. Stop the running application with Stop-Process -Name ChatGPT -Force.
6. Uninstall it with winget uninstall --id 9NT1R1C2HH7J --exact --silent --disable-interactivity. If WinGet isn’t available when the script runs as SYSTEM, remove the Store package directly instead, for example Get-AppxPackage -AllUsers -Name "ChatGPT" | Remove-AppxPackage -AllUsers. Confirm the exact package name on a test device first so the wildcard doesn’t match anything else.
7. Capture the exit code from the uninstall.
8. Rerun application and process detection to verify the removal.
9. Log any failed removals for manual investigation.

Removal alone doesn’t stop a reinstall. Restricting the Microsoft Store closes one route, but the tool may also be available as a direct download or a web app.

» Learn more about remotely uninstalling apps with Atera

Step 3: Give employees a sanctioned alternative

Every containment action should point employees toward an approved option that meets the same need. There are three realistic choices, each with trade-offs.

Once you’ve chosen an option, the remaining work is making it easier to reach than the alternatives employees found themselves. Here are some tips:

• Add the approved AI client to your approved software baseline so it reads as compliant in future audits
• Deploy the client to the relevant device groups through Atera
• Add it to the pre-approved software Robin can install, so employees who ask for an AI tool get the sanctioned one on request
• Publish the AI section of your acceptable-use policy alongside the rollout, naming the approved services, accounts, and prohibited data classifications

» Looking to automate at scale? Here’s our chosen AI agent stack

Step 4: Close the routes back in

Prevention controls stop removed tools from returning and keep new ones from appearing between audits. Push each one fleet-wide through Atera’s remote scripting or your existing policy management:

1. Block unapproved Edge extensions by setting the ExtensionInstallBlocklist policy under HKLM\SOFTWARE\Policies\Microsoft\Edge. This is a list policy, so create it as a subkey with numbered string values rather than a single value. Use * as the first entry to block everything by default.
2. Allow approved Edge extensions by listing their IDs in ExtensionInstallAllowlist under the same key, again as numbered string values. Build the allowlist before you apply the block-all entry, and include the extensions people legitimately depend on, such as password managers, so you don’t break daily work.
3. Apply the same pair of policies for Chrome under HKLM\SOFTWARE\Policies\Google\Chrome
4. Restrict the Microsoft Store by setting RemoveWindowsStore to 1 under HKLM\SOFTWARE\Policies\Microsoft\WindowsStore. This policy is enforced only on Windows Enterprise and Education editions. It also blocks Store-delivered apps you do approve, so deliver sanctioned apps through Atera instead.
5. Use application control (App Control for Business or AppLocker) to block executables from user-writable locations such as %LOCALAPPDATA%\Programs, where per-user AI clients and local model tools typically install. Test in audit mode first, since legitimate per-user apps can live there too. Enforcement also depends on the Windows edition, so check support for your fleet before you plan around it.
6. Remove local administrator rights from standard user accounts where they still exist
7. Rerun the Step 1 audit after each policy change to confirm the controls are holding

Step 5: Cover what the endpoint can’t see

Browser-only AI use and the data employees submit are handled by web and data protection tools rather than the RMM. If you run Microsoft 365, Defender for Cloud Apps and Purview cover both layers. If you manage Chrome through Google, Chrome Enterprise Premium does a similar job inside the browser. In both cases, Atera’s role is deploying the browser policies these tools depend on and using scripted audits to confirm their agents are present on every device.

Block unapproved AI services with Microsoft Defender for Cloud Apps

Defender for Cloud Apps maintains a catalog of generative AI apps with risk scores. It discovers which ones are actually in use from traffic on devices onboarded to Microsoft Defender for Endpoint. When you mark an app as unsanctioned, Defender for Endpoint blocks it on those devices at the next policy sync:

1. Confirm your devices are onboarded to Defender for Endpoint and that the Defender for Endpoint integration is turned on in Defender for Cloud Apps. Also confirm that network protection is enabled in block mode on those devices, since that is what enforces the block.
2. In the Microsoft Defender portal, open the Cloud app catalog
3. Filter Category to Generative AI
4. Open the Discovered apps report to see which AI apps are in use and their risk scores
5. Mark your approved AI apps as Sanctioned
6. Mark the rest as Unsanctioned to block them on onboarded devices
7. Create an app discovery policy in Defender for Cloud Apps that alerts you when a new generative AI app appears in your environment.

Unsanctioning works at the domain level. It can’t distinguish a personal account from a corporate one on an approved service, so that gap falls to the data layer.

Stop sensitive data reaching AI services with Microsoft Purview DLP

Purview Endpoint DLP inspects activity on onboarded devices. It can audit, warn on, or block pasting and uploading sensitive content to specific websites, so you control what leaves even on AI services you allow. In Edge for Business, Purview can also inspect text typed or pasted into consumer AI prompts and block sensitive content before it’s submitted.

1. In Purview’s Endpoint DLP settings, scroll to Sensitive service domain groups
2. Select Create sensitive service domain group and add the AI domains you want to control, such as chatgpt.com and gemini.google.com
3. Create a DLP policy with Devices as the location
4. Add conditions for the sensitive information types that matter most to you, such as customer personal data and credentials
5. In the rule’s actions, under Service domain and browser activities, select Paste to supported browsers and attach your AI domain group directly to the rule. Paste restrictions only honor domain groups set inside the rule, not the global service domain list
6. Set the action for the AI domain group to audit while you tune the policy for false positives
7. Switch the action to warn or block once the rule is tuned
8. Deploy the Microsoft Purview extension to Chrome on Windows devices since Purview can’t enforce paste and upload rules in Chrome without it

Pro tip: Chrome Enterprise Premium applies URL filtering and DLP rules inside Chrome itself. You can warn or block users on generative AI sites and apply content-based rules to paste and file upload events. Predefined templates include one that fully blocks unsanctioned generative AI sites while allowing an approved option.

What about personal devices?

Everything above applies to managed devices. Personal phones and laptops sit outside these controls, which is why a ban alone pushes the risk out of sight. Where employees can reach corporate data from unmanaged devices, limit what those sessions can do with conditional access and session controls, and pair that with the sanctioned alternative from Step 3 so there is less reason to go around you.

» Don’t miss our picks for the best enterprise AI platforms for IT management

Visibility comes before prevention

Most employees using unapproved AI are just trying to finish their work, so they reach for whatever is fastest. Prevention holds when each layer accounts for that. Policy defines what’s allowed, browser and web controls cover the traffic endpoints can’t see, DLP tracks what data leaves, and the endpoint layer keeps an accurate record of what’s installed across the fleet.

Atera’s RMM handles that endpoint layer from a single location. Software Inventory and remote scripting surface AI clients, local models, and unapproved extensions across every managed device, and targeted removal deals with the ones that shouldn’t be there. Robin handles the other side by autonomously installing and configuring pre-approved software when employees ask for it, so the sanctioned AI tool is also the quickest one to get.

» Interested? Try Atera for free