How to Handle Shadow AI in Your Company

When employees use AI tools for work without company approval or oversight, they create what organizations call shadow AI. It includes public chatbots used through personal accounts, AI features built into software, coding assistants, browser extensions, and AI agents. Agents can connect to company files or services and take actions.

Make useful AI available through an approved option, set clear rules for data and higher-risk tasks, and use controls that match the risks of unapproved tools. A blanket ban can push AI use further out of view, while unrestricted use can expose sensitive information or let an AI tool act without proper oversight. Choose controls based on what information employees share, what the AI does, and what it can access.

Find where employees use AI

Start by finding out which AI tools employees use and what work they do with them. Ask business units about their tools and tasks. Where appropriate, review purchasing records, sign-in activity, network or cloud-service reports, and activity recorded on devices or in browsers. Include AI features inside existing products, coding assistants, and agents employees build with tools that require little or no code.

No single source gives a complete list. A network report can show that someone visited an AI service, but not what they entered. Personal accounts and devices the company does not manage can also hide activity from company controls. Treat the list as a working picture, and invite employees to report tools and uses without fear of discipline for asking a question.

The scale of employee-led use makes that approach practical. In a 2024 Microsoft and LinkedIn survey, 78% of surveyed AI users said they brought their own AI tools to work. That figure describes AI users in the survey, not all workers or all companies. In Netskope’s 2025 observations of customer environments, 72% of generative AI users accessed popular tools through personal accounts. These results come from different populations and methods, so they should not be combined into a single estimate of company-wide use. They do indicate why relying only on approved-tool lists leaves blind spots. See the Microsoft and LinkedIn survey and Netskope’s 2025 observations.

Judge each use by its data, task, and access

For each way employees use AI, ask three questions: What information do they enter? What decision or task does the AI support? What can the AI access or change? Together, the answers distinguish polishing public-facing copy and using an agent that can read employee records or change code used in production.

Use the company’s existing data categories to set rules for AI. For example, a policy could let employees summarize public information with an approved tool while barring them from entering confidential customer records, credentials, regulated personal information, or unreleased source code into unapproved services. Explain how employees can request an exception or an approved alternative.

An AI agent deserves closer review when it connects to files, business systems, or code, or when it can take actions. Least privilege means giving the agent only the access it needs for its assigned task. Prompt injection is an attempt to manipulate an AI by placing instructions in user input or content the AI reads. If the AI can use connected tools, that manipulation can lead to data disclosure or unauthorized actions. OWASP recommends limiting access and requiring human approval for high-risk actions in its prompt-injection guidance.

Use a risk framework to structure decisions, rather than treating every AI use the same way. The NIST Generative AI Profile recommends evaluating risks in context, including privacy, intellectual property, information security, and third-party services. NIST’s framework is voluntary guidance, not a universal policy or legal requirement.

Give employees a useful approved option

An approved tool reduces shadow use only when employees can use it for real work. Make reviewed tools easy to find. State which account or settings employees must use, and explain which tasks and data each tool supports. If an approved tool cannot handle a common task, employees have reason to look elsewhere.

Check the provider’s terms and settings to learn how it handles prompts and uploaded files, how long it stores them, whether it uses them to improve models, who can access them, and how it handles deletion and incident notices. These details vary by product and plan. They also depend on settings and contract, so check the terms for the specific service. NIST recommends due diligence and contract controls for third-party AI. The Federal Trade Commission has emphasized that providers must honor their privacy and confidentiality commitments.

Match review effort to risk. A tool used to draft text from public information calls for a different level of oversight than an agent connected to sensitive records. For consequential work, consider whether employees need a managed service, tighter access restrictions, or a restricted internal environment.

Use blocking and monitoring for specific risks

Technical controls can support company rules. Data-loss prevention (DLP) tools look for sensitive information and can warn about or block certain attempts to share it. When these products support the AI service, use DLP controls alongside access settings, audit records, labels that mark data sensitivity, and rules for how long to keep data. These controls do not show every AI interaction. Microsoft’s Purview documentation describes controls for supported AI interactions and browser-based AI sites. Check the product documentation to confirm which services and settings your company uses support them.

Block a specific service or activity when its data handling is unassessed or its risks are unacceptable. Pair the block with an approved alternative and a way to request access. A blanket block does not resolve the underlying work need, and industry guidance from Gartner warns that employees may work around controls when sanctioned tools do not support their tasks. That warning is guidance, not proof that every ban will lead to circumvention.

Train employees to check AI-generated work, use the right account, avoid entering restricted information into unapproved tools, and report accidental disclosures. Make the reporting route easy to find. When someone reports a mistake, security and privacy staff can establish what information was shared and which service and account were involved, then decide whether to contact the provider or follow existing incident procedures.

Prepare for incidents and review the rules

Assign responsibility across security, IT, privacy, legal, procurement, and the business areas that use AI. For a suspected disclosure, identify the data submitted and the service and account that handled it. Check whether it included personal data, credentials, or intellectual property. Then use the company’s incident and legal procedures to decide on containment and any required notification. Applicable obligations depend on the data, organization, and jurisdiction, so legal counsel should assess them.

Track a few measures to see whether the approach works. Record how much known AI use has an owner and gets reviewed, whether employees use approved tools, how often controls alert on sensitive data, and how long approval takes for legitimate requests. Ask employees whether approved tools meet their needs. These measures help management; they are not standardized industry benchmarks.

Interpret the financial findings with care. In IBM’s 2025 breach study, one in five organizations studied reported a breach linked to shadow AI. Organizations with high shadow-AI use had average breach costs $670,000 higher than those with low or no such use. The study covered organizations that had experienced breaches. Its cost comparison does not show that shadow AI alone caused the difference or predict costs for a particular company. The IBM report gives companies a reason to investigate their exposure, not a forecast of their costs.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com