Detecting Shadow AI: Finding Unsanctioned AI Use in Your Logs

An engineer pastes a stack trace — customer IDs and an internal hostname included — into ChatGPT to debug it faster. A sales rep drops the quarterly pipeline into a "summarise this" prompt. Someone connects a browser extension that ships every page they read to an LLM "for productivity". None of it went through IT. None of it is logged anywhere the security team looks. That is Shadow AI, and by the time most SMBs think about a policy, the data has already left.

Every article on Shadow AI ends the same way: "write a policy, train your staff, raise awareness". Useful, but it assumes you can see the problem. You can't govern what you can't detect. This guide is about the detection half — the part your logs can actually answer.

What Shadow AI actually is

Shadow AI is the use of AI tools and services inside an organisation without the knowledge, approval or oversight of IT and security. It is the direct descendant of Shadow IT (the unsanctioned SaaS app, the personal Dropbox), with two differences that make it worse:

• It leaks data by design. A Shadow IT app stores your files; a Shadow AI prompt sends your data to a third party's model the moment someone hits enter. The exfiltration is the feature.
• It spreads faster. There is no install, no admin right, no procurement. A browser tab and a copy-paste are enough, so adoption outruns any governance cycle.

The category is broad on purpose: public chat assistants (ChatGPT, Claude, Gemini, Copilot), AI features silently added to tools you already use, browser extensions, "AI note-taker" bots that join your meetings, and code assistants pulling from — and pushing to — external models.

Why it is a real risk (not just a compliance checkbox)

• Data leakage. Source code, customer PII, contracts, credentials pasted into a prompt can be retained, used for training, or exposed. For an SMB this is the whole crown jewels, not a fragment.
• Compliance exposure. Under GDPR, and for those in scope of NIS2, sending personal or sensitive data to an unvetted processor is a reportable gap. "We didn't know employees were doing it" is not a defence — it is the finding.
• A new attack surface. Shadow AI tools are themselves targets: prompt injection, poisoned extensions, malicious "AI" apps that are really data siphons. The unsanctioned tool is unmonitored, so a compromise there is invisible.
• No audit trail. When an incident touches AI-handled data, you cannot answer "what left, to whom, when" — because nothing recorded it.

The risk is not that AI is used. It is that it is used invisibly. Which turns the whole problem into a detection problem.

The core: how to detect Shadow AI

You detect Shadow AI the same way you detect any unsanctioned egress — you already have the telemetry, you just have to point it at the right destinations. Three layers, cheapest first.

1. The DNS / network layer (highest signal, lowest cost)

Every generative-AI service is reached over a handful of known hostnames. If you log DNS queries (and you should — it is the single highest-value security log an SMB can keep), unsanctioned AI use shows up as resolutions to those domains from hosts that have no business reaching them.

A non-exhaustive starter list of endpoints to watch:

api.openai.com          chatgpt.com            openai.com
api.anthropic.com       claude.ai
gemini.google.com       generativelanguage.googleapis.com
copilot.microsoft.com   api.githubcopilot.com
perplexity.ai           api.mistral.ai           huggingface.co

The same list works at the firewall/NIDS layer (Suricata, Zeek) and in your web proxy or DNS filter (pfSense, Pi-hole, a secure web gateway). The point is not to block first — it is to see first.

2. A working Sigma rule

Here is a portable detection you can drop into any Sigma-compatible SIEM. It fires on DNS queries to known AI endpoints and excludes an allowlisted subnet — the one place your approved AI pilot is allowed to run — so you surface the shadow, not the sanctioned.

title: Unsanctioned Generative AI Service Access
id: 6f1c2b8a-4a3d-4c21-9b0e-7c2f5a9d1e44
status: experimental
description: Detects DNS queries to public generative-AI SaaS endpoints from hosts
  that are not on the approved-tool allowlist. Surfaces Shadow AI egress before data leaves.
logsource:
  category: dns_query
detection:
  ai_endpoints:
    QueryName|contains:
      - 'api.openai.com'
      - 'chatgpt.com'
      - 'claude.ai'
      - 'api.anthropic.com'
      - 'gemini.google.com'
      - 'copilot.microsoft.com'
      - 'perplexity.ai'
      - 'api.mistral.ai'
  sanctioned_pilot:
    src_ip:
      - '10.20.10.0/24'   # <-- your approved AI pilot subnet
  condition: ai_endpoints and not sanctioned_pilot
falsepositives:
  - Approved AI tooling on hosts not yet added to the allowlist
  - Security tooling that resolves these domains for its own detection
level: medium
tags:
  - attack.exfiltration
  - attack.t1567.002

The pattern generalises: keep the endpoint list current, keep the allowlist honest, and route the alert to whoever owns AI governance. One rule turns an invisible behaviour into a triageable event.

3. Proxy and endpoint layers (for the how, not just the what)

DNS tells you that a host reached an AI service. To know what left, add:

• Web proxy / CASB logs — request size and frequency to AI endpoints (a 40 KB POST to an LLM API is a paste of something substantial, not idle browsing).
• Endpoint telemetry — browser extensions installed, processes talking to AI SDKs, clipboard-heavy sessions against a known AI tab.

You do not need all three to start. DNS alone moves you from blind to aware in an afternoon.

From detection to governance

Detection is what makes governance real. Once the DNS rule is live, you can:

1. Measure the actual usage — which teams, which tools, how often. You will be surprised; everyone is.
2. Sanction the good, block the rest — approve a vetted tool on a controlled subnet (your allowlist), and the rule now only fires on the shadow.
3. Write the policy against evidence — a charter backed by "here is what we saw" lands where a generic memo does not.

This is exactly where a part-time CISO earns their keep: turning the detection signal into an approved-tool list, a data-handling rule, and staff guidance that fits how people actually work — instead of a ban everyone routes around.

FAQ

Shadow AI vs Shadow IT — what's the difference? Shadow IT is any unsanctioned tool or service. Shadow AI is the subset that sends your data into an external model. The distinction matters because the risk is not storage, it is transmission and retention by a third party.

How do I detect ChatGPT use at work? Log DNS queries and alert on resolutions to chatgpt.com / api.openai.com from hosts outside your approved-AI allowlist. The Sigma rule above does exactly this and extends to every major provider.

Is blocking these domains enough? Blocking without detection is brittle: users switch to the next tool, a mobile hotspot, or a new endpoint you haven't listed. Detect first so you know what to block and can see when someone routes around it.

Does this apply to us under NIS2? If you are in scope, sending personal or sensitive data to an unvetted processor is a governance gap you are expected to manage. Detecting Shadow AI is how you demonstrate you actually can.

Shadow AI is not a reason to ban AI — the productivity is real. It is a reason to make the invisible visible, then decide deliberately. ThreatClaw ships detection content exactly like the rule above in its Sigma feed, and its LLM red-team feed covers the other side — the AI tools you do approve. Start by turning on DNS logging and watching those endpoints; you cannot govern what you cannot see.