The short answer
“Shadow AI” refers to the unauthorized use of consumer AI assistants, browser extensions, or personal API accounts by employees to process corporate data or source code. It occurs when official AI procurement is slow, leaving staff to use personal tools on corporate laptops to meet deadlines.
Detecting Shadow AI requires a combination of DNS and proxy log inspection, Endpoint Detection and Response (EDR) browser extension inventorying, CASB (Cloud Access Security Broker) policies, and setting up legitimate enterprise AI pathways.
The 4 Primary Shadow AI Discovery Vectors
Security teams can identify unapproved AI activity across four technical channels:
1. Network Proxy & DNS Logs
Inspect outbound network traffic for API requests and web domain connections to known consumer AI endpoints.
- Search DNS and proxy logs for connections to consumer endpoints (e.g., OpenAI, Anthropic, Midjourney, Perplexity, or Hugging Face).
- Look specifically for API traffic originating from developer workstations using non-standard user agents or personal authorization tokens.
2. Browser Extension Inventory (EDR / MDM)
Browser extensions represent the highest-risk Shadow AI vector because they automatically capture webpage text, form entries, and editor tabs.
- Use your Mobile Device Management (MDM) or EDR agents (such as Jamf, Intune, or CrowdStrike) to audit installed browser extensions across all managed devices.
- Flag extensions requesting permissions to read all site data (
http://*/*andhttps://*/*) or editor tabs.
3. Financial Expense Audit
Shadow AI often leaves a paper trail in corporate expense reports.
- Audit corporate credit card statements for recurring $20–$30 monthly subscription charges from AI SaaS vendors.
- Identify staff expensing personal individual subscriptions rather than operating under enterprise workspace seats. As noted in our guide on free vs paid AI tools terms, individual subscriptions operate under consumer terms without enterprise privacy protections.
4. Git Repository & CI/CD Pipeline Scanning
Developers using unapproved AI tools may accidentally commit configuration files or API keys into repositories.
- Scan repositories for committed AI configuration files, local prompt logs, or personal API keys.
- Check developer
.vscode/settings.jsonfiles for unapproved AI extension settings.
Shadow AI Risk Remediation Workflow
┌─────────────────────────────────────────────────────────┐
│ 1. Detect Unapproved Tool │
│ (via EDR Extension Audit or DNS Proxy Log Alert) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2. Assess Data Exposure Risk │
│ (Determine if source code or PII was transmitted) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. Enforce Technical Block │
│ (Block via CASB/DNS & Force Extension Removal) │
└────────────────────────────┬────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 4. Provide Approved Alternative │
│ (Onboard employee to Enterprise Workspace with DPA) │
└─────────────────────────────────────────────────────────┘What these four vectors will not find
Every discovery method above depends on the activity crossing infrastructure you control. A significant fraction does not, and being clear about the blind spots prevents a discovery exercise from producing false confidence.
The personal device. An engineer photographing a screen with their phone, or retyping a stack trace into a chatbot on a personal laptop, generates no corporate telemetry at all. This is the largest gap and no technical control closes it.
AI features inside approved tools. The higher-volume problem in most organisations is not a rogue extension — it is the AI summarisation, drafting or code-completion feature that a vendor you already approved switched on in an update. Traffic goes to a domain already on your allowlist, from an application already sanctioned, under a contract signed before the feature existed. Nothing alerts.
Enterprise search across the whole estate. Where an assistant is granted broad access to a document store, the exposure is not what people paste in. It is what the tool can already reach on their behalf, including files with inherited permissions nobody has audited. RAG security: what leaks and how covers that failure mode.
Encrypted traffic without inspection. Domain-level visibility tells you someone contacted a provider. It does not tell you what they sent. Without TLS inspection — which carries its own legal and privacy constraints, particularly for employee monitoring in the EU — you have connection metadata and nothing more.
Treat a discovery exercise as establishing a floor: these are the tools in use that we can see. The real number is higher.
Triage: not every finding is an incident
A first sweep typically returns a long list, and treating every entry with equal urgency is how these programmes lose credibility. Sort by what was actually exposed, not by whether a rule fired.
The questions that separate a serious finding from noise:
- What class of data plausibly went in? Public documentation and a marketing draft are not the same as customer records, credentials, or source code from a regulated system.
- Personal account or enterprise tenant? A personal free-tier account typically operates under consumer terms — where inputs may train models by default and no DPA exists. The same provider under an enterprise agreement is a different legal posture entirely. This distinction usually matters more than which vendor it was. Free vs paid AI tools: what actually changes in the terms covers it.
- Is there a controller-to-processor relationship? If personal data went to a provider with no DPA in place, you have a potential Article 28 problem regardless of how the data behaved afterwards, and that is a documentation question your DPO needs.
- Can it be retracted? Some providers offer deletion and confirmation. Knowing which do, in advance, converts a panic into a procedure.
Record the answers. A shadow AI finding is evidence for a DPIA and for a SOC 2 or ISO audit trail, and it is much easier to write up at the time. Do you need a DPIA for an AI tool? covers when the threshold is met.
Why it happens, which determines whether it stops
Shadow AI is almost never defiance. In the overwhelming majority of cases it is someone trying to do their job with a tool that works, because the sanctioned path was slower, worse, or did not exist.
That has a direct operational implication: the time between an employee requesting a tool and being able to use it is the variable that controls your shadow AI rate. An organisation with a six-week approval process will have shadow AI permanently, at any level of enforcement, because the alternative to waiting is always available and never audited.
Blocking without a substitute reliably relocates the activity to devices you cannot see, which is worse than the original problem — you have converted a visible risk into an invisible one and told yourself it is fixed.
The interventions that actually change behaviour, in order of effect:
- A fast approval path with a real service level. Days, not weeks, with a lightweight assessment for low-risk uses and the full review reserved for tools touching regulated data.
- A default sanctioned tool that is genuinely good. If the approved assistant is materially worse than the consumer one, people will use the consumer one. This is a procurement decision, not a policy decision.
- Amnesty when you launch. Ask people to declare what they are using, with an explicit commitment that nobody is disciplined for answering honestly. You will learn more in a week than DNS logs tell you in a quarter, including about the personal-device usage no tool can see.
- Clear rules about data classes rather than tool names. “No customer data, no credentials, no unreleased financials, in any AI tool” survives new products entering the market. A blocklist of vendor names does not. Writing an AI acceptable use policy that people follow covers how to draft it.
Technical Countermeasures for Security Teams
To mitigate Shadow AI risks systematically:
Enforce Browser Extension Allowlisting
Transition from blocklisting specific extensions to an explicit allowlist enforced via Group Policy (GPO) or MDM. Block all unapproved extensions by default.
Implement CASB & DNS Category Blocking
Configure Cloud Access Security Brokers (CASB) or Secure Web Gateways (SWG) to categorize generative AI tools. Block traffic to consumer AI sites while allowing authenticated traffic to enterprise workspace endpoints.
Route to the tenant rather than blocking outright
Where a provider supports it, enforcing that traffic to their domain carries your enterprise workspace identity — and rejecting personal-account sessions — is stronger than a blanket block. The employee keeps the tool, you keep the contract, the logging and the retention terms. Support for this varies by provider and is worth asking about during procurement.
Provide Legitimate Enterprise Pathways
Blocking Shadow AI without providing a functional alternative leads developers to seek workarounds (such as using personal mobile devices or unmanaged laptops). Provide sanctioned enterprise AI seats governed by a signed Data Processing Addendum (DPA).
Re-run discovery on a schedule
This is not a project with an end date. New tools launch continuously, existing vendors add AI features silently, and staff change. A quarterly sweep against the same four vectors, with the results compared to the previous run, turns a one-off audit into a control you can evidence.
To evaluate sanctioned tools against security standards, review our guide on how to judge an AI provider, and how to get a DPA for an AI tool for the contractual step that turns a tolerated tool into a sanctioned one.