Shadow AI is the use of artificial intelligence for business without IT's knowledge, approval, or oversight. It includes unreviewed chatbots, coding assistants, agents, and AI features inside otherwise familiar software. Those tools can leave gaps in security visibility and create opportunities for data leaks or breaches.
At Blue Lantern Security, we see visibility as the foundation of security. Detection, analysis, and response depend on knowing what is happening in your environment. An unknown AI connection leaves part of that picture missing, making risks easier to overlook.
For a small business, that does not mean starting with a system that needs someone to investigate alerts all day. Our approach to AI exposure begins with a concrete question: which AI applications have been granted access to your company data, and how much access do they have?
How is shadow AI different from shadow IT?
Shadow IT is the use of software or technology for business without IT's knowledge or approval. Shadow AI is the AI-specific part of that problem. A personal file-sharing account can be shadow IT; an unapproved AI assistant processing the files is shadow AI.
The underlying security problem is familiar: unknown tools, unreviewed access, and incomplete visibility. Agents can increase the speed at which that problem causes harm. An agent with the necessary permissions can read files, call APIs, change records, or send messages in a sequence of automated actions. A mistake can spread before a person has reviewed the first result.
That is why we treat permissions and visibility as early priorities. Machine-speed execution makes a poorly understood access boundary more consequential.
What does shadow AI look like at work?
Consider these everyday scenarios:
- A customer support reply. An employee pastes a ticket containing customer details into a personal AI account that has not been approved for that information.
- A document assistant. Someone connects an AI writing tool to Google Drive without reviewing its permissions or whether access should remain after the task.
- A browser extension. An employee installs an unreviewed AI summarizer with access to work pages, without checking where it sends their content.
- A meeting assistant. A team enables AI transcription in an existing service without checking whether it is approved for confidential calls.
- A coding agent. A developer gives an unreviewed agent access to a project containing source code and configuration files with credentials.
- A new customer workflow. A team uses AI-generated code to connect customer requests to an external AI service, then deploys the application without security review.
Shadow AI can therefore appear inside software the company already uses. Approval for a service does not necessarily cover every new AI feature, account type, or data use.
When is AI use approved rather than shadow AI?
The decision depends on the account, task, data, and actions, as well as the tool itself.
A business might approve an assistant's company-managed account for drafting public marketing copy. Uploading confidential customer contracts to a personal account would need a different review. Paying for the service or signing in with a work email is not the same as approval.
An approved app can also hold unnecessarily broad permissions. That deserves an access review, but it does not automatically make the app shadow AI. Compare the actual use and grants with the organization's approval records.
How common is shadow AI?
In research commissioned by Microsoft and conducted by Censuswide in October 2025, 71% of 2,003 surveyed UK employees reported having used unapproved consumer AI tools at work; 51% reported doing so weekly. Respondents cited familiarity with personal tools and the absence of approved workplace options among their reasons. These are UK survey findings rather than a measurement of every business today. Microsoft's write-up covers the methodology.
What are the risks of shadow AI?
The concerns are practical: company intellectual property or customer data can reach an unreviewed provider, an assistant can retain unnecessary access, and incorrect outputs or unwanted actions can affect real work. Missing records make investigating those events harder.
The details matter. Processing, retention, and training practices vary by service and account. A connector also does not automatically receive every file: Google Drive distinguishes per-file access from broader reading permissions, for example. Review the actual grant and the provider's terms.
How can a business find shadow AI?
Start with three questions: Which AI tools are being used? What can they access? What data has actually been shared? Each requires different evidence.
| Where to look | What it can help reveal | What it cannot show on its own |
|---|---|---|
| Employee conversations and subscription records | Tools, accounts, owners, and the work they support | A complete inventory, especially of free or undisclosed tools |
| Google Workspace or Microsoft Entra app grants | Connected applications and their granted permissions | Every chatbot visit, pasted prompt, or file already accessed |
| Managed browser, network, and device records | Connections to known AI services or installed AI applications | Every AI feature, activity outside monitored devices, or prompt contents |
| AI service logs and supported session transcripts | Recorded activity and, where available, submitted content | Activity from uncovered accounts or content outside retention limits |
| Data loss prevention tools | Sensitive sharing that matches configured policies | Perfect classification or coverage of unsupported workflows |
Knowing an AI service was contacted does not tell you which company information it received. Match the evidence you collect to the question you need to answer.
Start by checking what the AI tool can log
When approving AI tooling, one early step is to check what logging is available and turn on the records you will need. To investigate company information pasted into a chat, you need more than a record that somebody signed in: you need the content itself, where the service supports collecting it.
Anthropic's Compliance API is one example. For eligible Claude Enterprise deployments, it provides access to conversation data and supported Claude Code session transcripts, including CLI and Desktop use. It requires administrative enablement and the appropriate access key.
Check the coverage carefully: the API's Activity Feed does not contain prompt text, and transcript coverage excludes personal accounts and certain deployment and retention arrangements. Logging supplies evidence for review; it does not automatically detect intellectual property or prevent disclosure.
Decide who will review those records and protect access to them. Content logs can themselves contain the sensitive information you are trying to safeguard.
Where DLP helps, and what it asks of your team
Data loss prevention (DLP) tools can inspect content and apply policies to sensitive information being shared. That provides a form of protection an app-permissions inventory cannot deliver.
The operational challenge is distinguishing an allowed transfer from an unwanted one. Uploading a customer document to an approved business system may be legitimate; pasting its contents into an unapproved AI account may violate policy. Identifying sensitive content is only part of that decision. Destination, account, permissions, and business context also matter.
Our concern for small businesses is the workload when those rules produce false positives. Repeatedly investigating legitimate activity consumes limited security time and can create alert fatigue. DLP needs tuning: Microsoft, for example, recommends simulation to assess policies and reduce false positives before enforcement.
There is also a workflow tradeoff. Inline inspection places a control in the path of an employee's action, allowing it to evaluate a submission before permitting it. That can prevent exposure, but policy mistakes or service problems can affect legitimate work. Test the impact and set up a way to resolve incorrect blocks. This applies to inline enforcement; DLP can also operate through monitoring and other deployment models.
Blue Lantern Security treats AI exposure as an application access problem
Our AI exposure management focuses on the direct access third-party AI tools have already been granted in your environment. Reviewing that access gives a small business a concrete place to start without inspecting every employee prompt or file transfer.
Through the Gmail organization integration, Blue Lantern Security inventories users' third-party OAuth grants and identifies known AI apps and the permissions they hold. Through the Outlook organization integration, it reviews application access in Microsoft Entra, including user versus organization-wide grants and unverified publishers holding data permissions. See the Gmail integration details and Outlook integration details.
Enable Daily AI exposure scan in the integration's settings with the required permissions. It runs once daily, with results in Monitoring Hub → AI Exposure. The scan reads app identities and granted permission scopes, never message or file contents.
This is a lighter starting point for an access review, not a replacement for a full DLP solution. A grant shows potential access, not proof that a file was read or shared. Local tools and personal AI activity without a grant in the connected environment fall outside this review. New grants may appear in the next successful daily scan.
Use the findings to work out which connections have a business purpose and remove unnecessary access in Google Workspace or Microsoft Entra. A technically granted permission still needs an organizational approval decision. Our guide to reviewing AI app access explains that process in more detail.
For the steps from a finding to an access decision, use the Google Workspace walkthrough or the Microsoft 365 walkthrough. If you are deciding which protections your team needs, see AI access monitoring vs. DLP for small businesses.
A practical first review for a small business
- Identify the tools and owners. Ask what people use, compare that with available records, and document the approved account and purpose.
- Check logging and coverage. Turn on logging where the tool supports it, set retention, and assign someone to review the records.
- Review direct access. Prioritize broad permissions involving customer data, confidential files, credentials, or powerful actions. Remove grants that are no longer needed.
- Choose additional controls deliberately. Where sensitive data sharing needs protection, evaluate DLP coverage, tune policies, and plan how alerts and incorrect blocks will be handled.
- Revisit changes. Review new connections, features, and permissions. If disclosure is suspected, investigate it; revoking a grant does not delete copies already held by a provider.
The objective is visibility you can act on and controls your team can maintain. Start with what AI can access, find out what evidence is available, and build protection around the data and workflows that need it.
Questions about shadow AI
Can a local AI model be shadow AI?
Yes. A model running locally can still be used without approval or oversight. Local processing changes where computation happens; it does not settle which files the tool should access or which actions it should take.
Should a business ban AI to prevent shadow AI?
A business may need to block a risky tool or prohibit sensitive data in an unapproved service. Pair those restrictions with useful approved options and a straightforward review process, so employees can complete legitimate work within the rules.