A staff member needs to summarise a long document, rewrite an email, analyse a spreadsheet, generate code or prepare a presentation. The organisation has not approved an AI tool for that task, so the employee opens a public AI service, signs in with a personal account and pastes the material there.
The work may be completed in minutes. The security team may never know the tool was used.
That is the basic shadow AI problem.
Shadow AI is the use of AI tools, models, assistants or integrations for organisational work without the knowledge, approval or governance of the people responsible for managing that technology and its risks. It is closely related to shadow IT. The UK National Cyber Security Centre describes shadow IT as unknown assets used for business purposes outside normal asset management and corporate processes. AI adds a new layer because users can send substantial amounts of business data to external models through a simple browser conversation.
Shadow AI does not mean that every unapproved AI session causes a data breach. The problem is that the organisation may no longer know what data left its controlled environment, which provider handled it, what contractual terms applied, how long it may be retained, whether it can be recovered, or what integrations and permissions were granted.
Why employees use shadow AI
The reasons are usually practical rather than malicious. Generative AI can reduce the effort needed for routine knowledge work, and employees naturally look for faster ways to complete tasks.
Typical shadow AI use includes:
- pasting meeting notes into a public chatbot for summarisation;
- uploading a customer spreadsheet for analysis;
- asking an AI assistant to rewrite confidential emails;
- sending source code to an unapproved coding assistant;
- connecting an AI service to cloud storage or email;
- using a personal AI account for company work;
- installing browser extensions or plugins that add AI features to existing workflows.
A policy that simply says “do not use AI” may therefore be ignored if employees have a genuine productivity need and no approved alternative. Good governance has to manage both sides of the problem: the security risk and the business demand that created the workaround.
The main risk is loss of visibility and control
A security programme cannot protect a system it does not know exists.
When an organisation approves a cloud service, it can usually perform some level of vendor assessment, contract review, identity integration, access control, logging, retention configuration and incident planning. With shadow AI, those controls may be absent.
This changes a familiar workflow:
| Security question | Approved AI service | Shadow AI use |
|---|---|---|
| Who is using it? | Usually tied to managed identity | May use personal accounts |
| What data is permitted? | Can be defined by policy and controls | User decides ad hoc |
| What terms apply? | Reviewed centrally | May be accepted individually |
| Can access be revoked? | Usually centrally managed | May depend on personal account control |
| Is activity logged? | Often available to administrators | Organisation may have little visibility |
| Are integrations reviewed? | Can be scoped and approved | Permissions may be granted directly by users |
| Can incidents be investigated? | Known provider and account context | Evidence may be incomplete |
The table does not imply that every approved AI service is automatically safe. Approval should be based on a real assessment. The advantage is that an approved service can at least be brought into the organisation’s normal risk-management process.
Sensitive data can cross a boundary very easily
Generative AI interfaces encourage users to provide context. Better context often produces better answers, so users may gradually paste more information than they initially intended.
That context can include names, financial details, internal strategies, source code, credentials, legal documents, customer data or unpublished business information. OWASP’s LLM02:2025 guidance specifically identifies personally identifiable information, financial details, confidential business data, security credentials and legal documents as examples of sensitive information that LLM applications need to protect.
The exact privacy and retention risk depends on the specific provider, product tier, configuration, contract and settings. It is inaccurate to claim that every AI provider trains on every prompt. Some services provide enterprise controls, different retention options or commitments about model training. Others may operate under consumer terms that are unsuitable for organisational data.
The practical security question is therefore not simply, “Is this AI tool safe?”
It is:
“Is this particular service, under these exact terms and settings, approved to receive this category of organisational data?”
That is a much more useful question because it connects AI use to data classification and vendor assurance.
My guide on protecting sensitive data, API keys and credentials when using AI tools explores the data-handling side of this problem in more detail.
Personal accounts create an identity and offboarding problem
Suppose an employee uses a personal email address to create an AI account and then uses that account for company work.
Even if the AI provider itself is secure, the organisation now has an identity-management gap. The security team may not be able to enforce multifactor authentication, review sign-in events, recover the account, revoke sessions or guarantee that access ends when the employee leaves.
The same issue appears when an employee stores prompt history, uploaded files, generated documents, custom assistants or project context inside a personally controlled workspace.
This is one reason enterprise identity matters. Single sign-on, centrally managed accounts, role assignment and offboarding are not administrative decoration. They help answer a critical question: who can still access organisational information tomorrow?
AI integrations can turn a simple chatbot into a privileged application
The risk increases when an AI tool can connect to email, calendars, source repositories, document stores, ticketing systems, databases or automation platforms.
A standalone chatbot that receives manually pasted text has one type of exposure. An AI agent with permission to search cloud drives, send messages or invoke business tools has a much larger trust boundary.
If a user authorises an unapproved AI integration through OAuth or another delegated access mechanism, the organisation may unintentionally create a new data path into sensitive systems. The problem is not only what the user types into the chat. The integration may be able to retrieve data automatically within the permissions it was granted.
This is closely related to the risks described in AI agents and cybersecurity and MCP security risks. Model capability should not automatically become system authority.
For high-impact integrations, review at least:
- what data the tool can read;
- what actions it can perform;
- whether permissions are broader than the actual task;
- whether administrators can revoke access centrally;
- what logs exist for AI-triggered actions;
- whether human approval is required for sensitive operations.
Shadow AI can bypass existing data-loss controls
Many organisations spend years building controls around email, managed cloud storage, endpoint security, identity and approved SaaS platforms. Shadow AI can create a new outbound path that was not considered when those controls were designed.
For example, a company may prevent employees from sending a confidential document to an external email address but still allow a browser session to upload the same document to an unapproved AI service. From the user’s perspective, both actions may feel harmless because the recipient is a tool rather than a person.
This is why AI security cannot be handled only as an awareness topic. Technical controls may also be necessary, depending on the organisation’s risk level. These can include managed browser controls, SaaS discovery, DNS or proxy visibility, data loss prevention, endpoint controls, identity restrictions and controls over third-party OAuth applications.
Technical blocking alone is still incomplete. If employees repeatedly need a capability, the organisation should understand why and provide a safe route where practical.
The output can create a second risk
Shadow AI risk is not limited to data going into a model. The generated output can also enter business systems without appropriate review.
An employee may use an unapproved AI tool to produce:
- code that is committed to a production repository;
- legal or policy wording that is treated as authoritative;
- a spreadsheet formula that changes financial calculations;
- a customer response containing incorrect information;
- a shell command copied into an administrative terminal;
- research claims that were never verified.
The core problem is over-trust. AI output can be useful while still being wrong, incomplete or insecure. The NCSC’s AI guidance notes that generative AI can produce incorrect statements as facts and is vulnerable to issues such as prompt injection. NIST’s Generative AI Profile similarly places AI use within a broader process of governance, mapping, measurement and management rather than treating model output as inherently trustworthy.
For software development, see AI coding assistants and security, which explains why generated code should pass through the same review and assurance process as code from any other source.
A practical control model for shadow AI
The strongest response is usually not a single product. It is a small governance system that makes approved AI easier to use than unapproved AI.
1. Discover what people are actually using
Start with visibility rather than punishment. Identify common AI services, browser extensions, coding assistants and integrations being used for work.
Discovery methods can include employee surveys, help-desk conversations, SaaS discovery, identity logs, proxy or DNS telemetry, expense records and reviews of authorised third-party applications. The method should be proportionate and consistent with employee privacy obligations.
The goal is to understand workflows. If twenty employees are independently using AI to summarise documents, that is evidence of a business requirement that should be addressed centrally.
2. Define data classes that may and may not be used
A useful AI policy should translate existing data classification into simple decisions.
For example:
- public information may be permitted in approved tools;
- internal information may require an approved enterprise workspace;
- regulated, customer, credential or highly confidential data may require stronger controls or may be prohibited entirely;
- secrets such as passwords, private keys and API credentials should not be pasted into ordinary AI conversations.
The exact categories must match the organisation’s legal, contractual and business obligations. Avoid vague instructions such as “do not share sensitive data” if employees have no practical definition of sensitive.
3. Provide approved tools with useful capabilities
If the approved platform is difficult to access or much less capable than public alternatives, shadow use is likely to continue.
An approved AI service should be evaluated for the actual work employees need to perform. Depending on the use case, assessment may cover contractual terms, retention, training-data commitments, tenant isolation, administrator controls, identity integration, logging, incident response, regional processing, subprocessors and integration permissions.
Approval is not permanent. Material product changes should trigger reassessment.
4. Use least privilege for integrations
An AI assistant that only needs to summarise selected documents should not automatically receive write access to an entire cloud drive. A coding assistant should not receive production credentials merely because it can execute commands.
Scope permissions to the minimum required data and actions. Separate read-only analysis from state-changing actions where practical. Require additional approval for operations with significant business impact.
5. Keep human review around consequential output
AI can accelerate drafting and analysis, but important decisions still need accountable review.
The higher the consequence, the stronger the review should be. Generated marketing copy and a production firewall change should not have the same approval process. Neither should a brainstorming summary and a legal interpretation.
6. Create a simple exception path
Employees will sometimes discover a genuinely useful AI service that has not yet been reviewed. Give them a clear way to request assessment instead of forcing them to choose between abandoning the tool and using it secretly.
A lightweight intake form can ask:
- What problem does the tool solve?
- What type of data will it receive?
- Does it connect to company systems?
- What permissions does it request?
- Who needs access?
- Is there an approved alternative?
This creates a repeatable path from shadow use to governed use.
What employees should do before using a new AI tool for work
A short personal check can prevent many shadow AI problems:
- Confirm whether the tool is approved for business use.
- Check whether the account should use organisational identity rather than a personal email address.
- Identify the classification of the data you plan to enter.
- Do not paste passwords, API keys, private keys or authentication tokens.
- Do not upload customer, employee, legal, financial or confidential material unless policy explicitly permits it for that service.
- Review requested integrations and permissions before granting access.
- Verify important AI-generated facts, code and decisions before using them operationally.
- If the tool is genuinely useful but not approved, request review instead of quietly building a business process around it.
Shadow AI is ultimately a governance signal
It is tempting to frame shadow AI as an employee-behaviour problem. Sometimes policy violations do need to be addressed, but widespread shadow use often signals something else: people have found a capability they need faster than governance has adapted.
The security objective should be to bring useful AI into known, reviewable and controllable paths.
NIST’s AI Risk Management Framework is useful here because its four core functions, Govern, Map, Measure and Manage, fit the problem well. Organisations need governance for acceptable use, mapping of AI systems and data flows, measurement of relevant risks, and ongoing management as tools and use cases change.
The NCSC’s shadow IT guidance makes the same broader point from a traditional security perspective: unknown technology becomes difficult to secure because it sits outside normal asset and risk processes.
Shadow AI therefore should not be treated as a reason to reject AI. It is a reason to make AI adoption visible.
When employees have approved tools, clear data rules, managed identities, proportionate technical controls and a simple way to request new capabilities, the organisation can benefit from AI without allowing important business data and permissions to disappear into unmanaged workflows.