Shadow AI: Seeing and Governing AI Use on Your Network

By Taylor Thomas · 2026-08-30

Shadow AI happens when a category of tool becomes useful faster than any organization can evaluate it. Employees signed up individually, with a browser and an email address, and got value the first afternoon. The headline risk this primer follows is not malware — it is data leaving on purpose, typed into a text box by someone doing their job.

Why This Lands on the Network Team

Malware defenses key on malicious content and behavior — inbound payloads, command-and-control callbacks, exfiltration indicators — and an authorized user submitting data to a reputable AI service presents none of them. Shadow AI, on its network-visible face, is an outbound disclosure problem: source code pasted into a chat window, a customer list summarized, a strategy document rewritten into a memo — each an ordinary encrypted session to a reputable destination.

A device whose traffic crosses a path you operate without an opaque intermediary exposes connection metadata regardless of browser or personal account — the leverage, and its limit: a device that leaves the path, or wraps its traffic in a tunnel or relay, takes the signal with it.

The Signals You Already Have

Discovery is often possible with telemetry you already generate — first verify it is collected and retained.

Name resolution is the broadest signal. Reaching a service by hostname means resolving it somewhere; through resolvers you operate, the logs enumerate the names looked up without touching session contents. Read them as a first-pass inventory, not a usage record: a lookup is not proof a session followed, and caching means repeat use often generates no new query. It holds only while clients use your resolvers: encrypted DNS pointed at a third-party resolver removes those queries from your logs — the connection to the resolver stays visible, not what was asked — making resolver policy part of the visibility design. The DNS control layer is covered in what is Umbrella DNS security.

Egress addresses and session metadata carry the next layer. Encryption protects the contents of a session, not its existence: the address a client connects to, the volume, its direction, the pattern’s regularity — and, where the client sends cleartext SNI without Encrypted Client Hello, the TLS server name — survive. That name is the server addressed, not always the application behind it; where the SNI is absent, encrypted, or uncaptured, naming the service behind an address is an inference that shared cloud and CDN address space regularly defeats without resolver or gateway data to correlate.

Proxy and gateway logs are the richest source where traffic passes through a gateway: they add hostname and category context, and can attach activity to a person rather than an address where the gateway authenticates users or another identity source maps the session. Per-request detail is not free: without decryption an explicit proxy sees the connection target, a transparent gateway may see less, and the path and query of encrypted requests stay hidden either way.

Discovery Is Not Yet an Inventory

A common failure treats a list of resolved domains as an inventory of use. A single curious visit and a daily automated integration moving thousands of documents look identical in a deduplicated domain list yet are different problems.

Separating them means reading volume, direction, and rhythm. Sustained outbound volume on a regular cadence suggests the automated or habitual — worth finding early: it may be a dependency someone will defend.

That measure prioritizes the sustained and automated; it proves neither integration depth nor sensitivity. The case this article opened with — a customer list pasted into a chat window — can be a few kilobytes inside a session whose streamed responses make it look inbound-dominant, indistinguishable from ordinary browsing. Traffic shape alone cannot tell you whether encrypted content was sensitive.

Governing Without Driving It Underground

Blocking everything is an understandable instinct and a limited response: it does not remove the need, and some of the work moves to a personal phone on cellular, keeping the risk and losing the visibility.

The pattern that holds is a sanctioned path good enough that people prefer it, plus graduated controls on everything else. Category policy at the DNS or gateway layer controls many known standalone services — subject to categorization accuracy, and, at domain or category granularity, blind to AI features that share their host SaaS’s domains. Inline data-loss inspection can enforce what may be sent to a permitted destination, though inspecting session contents on the wire means decrypting them at that point — with its own privacy, performance, and trust obligations, and pinned or app-layer encryption still out of reach of that point. Reserve outright blocking for services whose risk exceeds tolerance.

Underneath sits the ordinary discipline: policy expressed per user, device posture, application, and data classification rather than per subnet. The identity and posture signals come from the zero-trust stack described in zero trust network access; the outbound enforcement — gateway, DNS-security, and DLP machinery — reaches roaming users through an endpoint client or cloud gateway. Treating AI services as one more class of SaaS destination, not a novel category needing novel machinery, keeps the problem tractable.

The visibility, gateway, and policy layers this depends on are the substance of the SCAZT 300-740 exam — the same controls that governed the previous decade of shadow IT. The tools are new; the discipline is not. Start with the first lesson.

Frequently Asked Questions

What is shadow AI?

Shadow AI is the use of AI services that an organization has not reviewed or approved — nor, where applicable, brought under contract — the same pattern as shadow IT, applied to a category of tool that employees adopt individually and immediately. In most cases it is not malicious; it is someone solving a real problem with the fastest tool available.

Can you detect AI use when the traffic is encrypted?

Partly, and that is usually enough for discovery. TLS conceals the content of a session but not the fact of it: name lookups through resolvers you monitor, the address the client connects to, the shape and volume of the traffic — and, where the client sends a cleartext SNI without Encrypted Client Hello, the TLS server name — remain observable. That name is not always the application behind it, and where the SNI is unavailable, mapping an address to a specific service is an inference that shared cloud hosting can defeat, and reading the prompts themselves requires decryption — a much larger decision.

Is blocking AI tools the right response?

Blocking alone can displace some of the behavior rather than end it — to a phone or a home laptop, where the organization has little or no visibility. A widely recommended pattern is to provide a sanctioned path that is genuinely good enough to use, back it with endpoint controls and monitoring, and reserve blocking for services whose risk exceeds tolerance.