Fifteen years ago, security teams coined the term "shadow IT" to describe the phenomenon of employees using unauthorised cloud services — Dropbox, personal Gmail, consumer file sharing — without IT knowledge or approval. The risk model was about data governance: files leaving the organisation's controlled storage environment and landing in third-party infrastructure with unknown security postures.
Shadow AI is a fundamentally more dangerous version of the same problem. And it's growing faster.
These statistics, drawn from Netskope's 2026 Cloud and Threat Report and corroborated by our own telemetry across AIGuard-protected enterprise environments, paint a picture that should concern every CISO. The average large enterprise has more AI applications in active use than the average security team can meaningfully evaluate, and the overwhelming majority of those applications have never been reviewed for data security, model training policies, or regulatory compliance.
Why Shadow AI Is Worse Than Shadow IT
The distinction matters. When an employee used Dropbox without IT approval in 2012, they were moving files. The files existed in the organisation's systems before the Dropbox upload, and the primary risk was that a copy was now somewhere the organisation couldn't control. Bad, but bounded.
When an employee uses an unsanctioned AI tool today, they're not moving files. They're generating a new artefact — the prompt — that may contain information that has never existed in any other form. A conversation with ChatGPT about a strategic acquisition target doesn't involve uploading any files. It involves a person typing thoughts, context, and analysis that exists only in their head and in the chat interface. There is no "original file" that security teams can track or protect.
Furthermore, prompt data has a unique characteristic that makes it particularly sensitive: it often represents the synthesis of multiple sensitive information sources. An analyst asking an AI to "compare our Q4 revenue projections with the analyst consensus and help me draft the variance explanation" is combining financial projections (material non-public information), knowledge of internal discussions, and a forthcoming investor communication — all in a single prompt that traditional DLP has no framework for evaluating.
The Discovery Methodology
Effective shadow AI discovery requires combining signals from multiple telemetry sources, because no single source provides complete visibility.
DNS Log Analysis
DNS resolution requests to AI provider domains — api.openai.com, claude.ai, generativelanguage.googleapis.com, api.anthropic.com, and hundreds of wrapper applications built on these APIs — appear in enterprise DNS logs and are typically not filtered. A systematic analysis of DNS logs across all corporate devices and network egress points will surface the majority of AI applications in active use, including many that security teams didn't know existed.
Proxy and Firewall Log Analysis
For organisations with a forward proxy in place, HTTP CONNECT and TLS SNI logs provide finer-grained visibility than DNS alone. You can see not just which AI domains are being resolved but which specific applications employees are reaching, from which systems, at what times, and with what traffic volumes. Volume is a useful signal: a user generating 50MB of outbound traffic to an AI API is using it very differently from a user generating 50KB.
Browser Extension Telemetry
Where enterprise browser management is in place, browser extension telemetry can identify AI-powered browser extensions — coding assistants, writing tools, meeting summarisers — that operate entirely within the browser context and may not generate distinctive network traffic patterns. AIGuard's browser extension approach monitors AI interactions at the point of input, providing a visibility layer that is complementary to network-based discovery.
SaaS Application Discovery via OAuth Grants
Many AI tools are accessed by granting OAuth permissions to corporate Google Workspace or Microsoft 365 accounts. Reviewing the OAuth grant log for your identity provider will surface AI applications that employees have connected to their work accounts — often with broader permissions than they realise.
Risk Scoring Framework for AI Applications
Discovery surfaces a long list of applications. Risk scoring turns that list into a prioritised action plan. AIGuard's AI application risk scoring model evaluates seven dimensions:
Building the Sanctioned AI Catalog
The sanctioned AI catalog is the operational output of the discovery and risk-scoring process: a curated, maintained list of AI applications that the organisation has evaluated, approved for specified use cases, and classified by the data types they may and may not receive.
A well-structured catalog entry for an AI application should include: the application name and all known domain variants; the risk tier (sanctioned / conditional / blocked); the data classification ceiling (e.g., "public and internal data only; no confidential or restricted"); applicable user roles; the date of last review; and the specific conditions of approval (e.g., "requires enterprise account with data processing agreement in place").
The catalog must be a living document, not a one-time effort. AI application security postures change — vendors get acquired, change their data usage policies, or suffer breaches. A quarterly review cycle is the minimum; monthly is better for applications handling sensitive data. AIGuard's SaaS AI Security module integrates with the risk scoring engine to automatically flag catalog entries when a vendor's security posture changes materially, prompting a review rather than requiring it to be discovered manually.
- Shadow AI differs from shadow IT in a critical way: sensitive data exits as prompts, not files — there's no "original" to track or protect.
- The average enterprise has 400+ AI apps in active use; discovery requires combining DNS logs, proxy logs, browser extension telemetry, and OAuth grant analysis.
- Risk scoring must cover data training policy, residency, certifications, compliance posture, and incident history — not just whether the vendor has a privacy policy.
- The sanctioned AI catalog is a living operational document, not a one-time policy output — it requires quarterly review at minimum.
- Blocking unknown AI apps without an approved alternative drives use underground; the goal is governed access, not blanket prohibition.
Blocking vs. Governing
A common mistake in initial shadow AI responses is to block all unapproved AI tools at the firewall or proxy level. This feels like action, but it reliably fails. Employees are using these tools because they solve real problems and make them meaningfully more productive. Blanket blocking doesn't eliminate that need — it drives usage underground, to mobile devices, home networks, and personal accounts that security teams have even less visibility into.
The right model is governed access, not prohibition. For most AI applications, the goal should be to provide a sanctioned, monitored pathway — ideally with DLP scanning in the traffic stream — rather than to block outright. Reserve blocking for the genuinely high-risk tier: tools with no security documentation, actively hostile data usage policies, or known breach histories. For everything else, make the approved path easier than the workaround.
Discover your shadow AI footprint in 24 hours
AIGuard can analyse your proxy and DNS logs to produce a complete shadow AI discovery report — no agents required, no disruption to existing workflows.
Request a Demo