Shadow AI: Managing Employee Use of Generative AI Tools

Shadow AI is the use of generative AI tools that your organization hasn't approved or doesn't know about. Blocking it outright rarely works, because people find another browser, another device or another tool. What works is a sequence: find out which tools are already in use, give people an approved option with proper data terms, write a short acceptable-use policy tied to your data classification, back it up with DLP and browser controls, and train people on the rules.

This post walks through each step for IT and security teams that don't have a dedicated AI governance function.

What is shadow AI and why does it matter?

Shadow AI is a subset of shadow IT. An employee signs up for a chatbot with a personal email address, installs an AI writing extension, or connects a meeting transcription app to their calendar. None of it went through procurement or security review.

The risks are specific and practical:

• Data leaving your control. Anything pasted into a prompt or uploaded as a file goes to a third party. Under some consumer terms, it may be retained and used to improve the provider's models.
• No contract, no DPA. If personal data goes into a tool with no data processing agreement, you may have a privacy compliance problem regardless of what the provider does with it.
• Broad permissions. Browser extensions and "sign in with" integrations often request access to every page you visit, or to your whole mailbox and file storage.
• Unchecked output. Generated text, code and analysis can be confidently wrong. Code can also carry licensing questions or insecure patterns.
• No visibility. When something goes wrong, you can't investigate activity in an account you don't own.

Most of this comes from people trying to do their jobs faster, not from bad intent. Your approach should reflect that.

How do you find out which AI tools employees are using?

You can't govern what you can't see. Build an AI tool register from several sources:

• Web and DNS logs. Your proxy, secure web gateway or DNS filtering service can report traffic to known AI services. Many filtering products now have a generative AI category.
• SSO and OAuth grants. Review which third-party apps users have authorized against your identity provider, email and file storage, and what scopes they hold.
• Browser extensions. If you manage browsers centrally, pull the list of installed extensions and look for AI assistants.
• Expenses. Card statements and expense claims turn up individual and team subscriptions.
• SaaS admin consoles. Check which AI features are enabled in the platforms you already pay for.
• Ask people. A short, blame-free survey often surfaces more than logs do, including why people chose each tool.

For each tool, record who uses it, for what, with what data, under which account type, and what permissions it holds. That register becomes the starting point for your approved list.

Why offer an approved AI tool?

If the only sanctioned answer is "no," people will keep using whatever they already have. Giving them a supported option with proper terms removes most of the reason to go around you.

When you evaluate a business or enterprise AI offering, check the contract rather than the marketing page:

• A commitment not to train models on your prompts, files or outputs
• Clear retention periods for prompts and outputs, and whether you can shorten them
• A data processing agreement and a published subprocessor list
• Data residency options if you need them
• SSO, so accounts are tied to your identity provider and removed when people leave
• Admin controls over features, connectors and file uploads
• Audit logs you can export or query
• Independent assurance, such as a SOC 2 report or ISO/IEC 27001 certificate, covering the AI service

Then make the approved tool easy to find, easy to request and good enough that people actually prefer it.

What should a generative AI acceptable-use policy cover?

Keep the policy short enough that people will read it. Two pages is plenty. It should cover:

1. Scope. Standalone AI tools, AI features inside existing software, browser extensions, and direct API use by developers.
2. Approved tools. Where the current list lives and how to request a new tool.
3. Accounts. Work data goes only into work accounts on approved tools, never personal accounts.
4. Data rules. What can and can't go into prompts, tied to your classification levels (see below).
5. Human review. People remain responsible for anything they send, publish, ship or decide using AI output.
6. Restricted uses. For example, no AI-only decisions about hiring, performance or customer eligibility without human review, and no connecting AI tools to systems of record without approval.
7. Code. Review generated code like any other contribution, and never paste secrets, keys or credentials into prompts.
8. Reporting. How to report a mistake, such as pasting the wrong file, without fear of punishment. Early reports let you act while it still matters.

How should data classification apply to AI prompts?

The simplest rule people can remember is that a prompt is a data transfer. Map your existing classification levels to what's allowed:

If you don't have a classification scheme yet, this is a good reason to create one. Even three levels are enough to make the rules usable.

Which technical controls help? DLP and browser controls

Policy sets expectations. Technical controls catch the mistakes. Useful layers include:

• Web filtering with a redirect. Block or warn on unapproved AI services, and point people to the approved one instead of showing a bare block page.
• Tenant restrictions. Where the approved provider supports it, allow only sign-ins to your organization's tenant, so people can't use a personal account on the same service.
• DLP on uploads and paste. Inspect content sent to AI services for patterns such as payment card numbers, national ID numbers, API keys and documents carrying sensitivity labels. Browser-level or endpoint DLP can catch paste events that network inspection misses.
• Managed browser policies. Use an extension allowlist so AI extensions need approval before they can read pages and form data.
• OAuth consent policies. Require admin approval for third-party apps that request access to mail, files or calendars.
• Logging. Send audit logs from approved AI tools to wherever you already review security events.

Start with warnings and coaching messages rather than hard blocks where you can. They teach the rule at the moment it matters and generate fewer workarounds.

What about AI features inside existing SaaS?

A lot of AI use doesn't involve a new tool at all. It comes through an assistant that a vendor added to software you already run: your productivity suite, CRM, help desk, meeting platform or code repository.

Treat these like any other significant change from a vendor:

• Check the defaults. Some features are enabled for all users unless an admin turns them off.
• Read the updated terms. Look for changes to data processing terms and new subprocessors, such as the model provider.
• Fix oversharing first. An assistant that can search everything a user can access will surface files that were technically shared but practically hidden. Review permissions on file shares and sites before rolling out assistants that search across them.
• Roll out in stages. Enable features for a pilot group, review the logs and expand from there.

Add these features to your AI tool register alongside standalone tools.

How should you train employees on AI use?

Training works best when it's short, specific and tied to real tasks. Cover:

• Which tools are approved and how to get access
• What data can't go into prompts, with concrete examples from your business
• Why outputs need checking, including how models can produce plausible but false answers
• How to request a new tool and how to report a mistake

Add role-specific material where the risk is higher. Developers need guidance on code review, licensing and secrets. HR and finance teams need to know which personal data rules apply.

If you operate in the EU, the AI literacy duty in Article 4 of the EU AI Act has applied since February 2, 2025. It requires providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy among staff and others who operate or use those systems on their behalf. A documented training program is a sensible way to show you've done that.

Where do the NIST AI frameworks fit?

You don't need a formal framework to manage shadow AI, but two NIST documents are useful references. The AI Risk Management Framework (AI RMF 1.0), released in January 2023, organizes AI risk work into four functions: Govern, Map, Measure and Manage.

Its companion, the Generative AI Profile (NIST AI 600-1), published in July 2024, lists risks that generative AI creates or worsens. Several map directly onto shadow AI, including data privacy, information security, intellectual property, confabulation and value chain and component integration. It's a handy checklist when you review a new tool.

Frequently asked questions

Should we just block all generative AI tools?

Blanket blocks tend to push use onto personal devices and accounts, where you have no visibility at all. Blocking unapproved services while offering a sanctioned one is usually more effective.

Does an enterprise AI agreement make any data safe to use?

No. It improves your contractual position and controls, but the tool still becomes another place your data lives. Your classification rules still apply, and restricted data should only go where it has been specifically approved.

How often should we review the approved AI tool list?

Quarterly is a reasonable pace. New tools, new features in existing software and changes to vendor terms arrive often, and a stale list is one of the main reasons people go around the process.

Next steps

• Build an AI tool register from web logs, OAuth grants, extensions, expenses and a short survey.
• Choose at least one approved tool with contractual data protections and SSO.
• Publish a two-page acceptable-use policy linked to your data classification levels.
• Add web filtering redirects, DLP rules for AI services and an extension allowlist.
• Review AI features in your existing SaaS, starting with default settings and file permissions.
• Run short, practical training and repeat it when the approved list changes.

People will use AI whether or not there's a policy. Your job is to make the safe path the easy one.