Network and DNS Evidence
What the network tells you about AI tool use, how to read it, and the substantial part of the picture it misses.
Discovery · Analysis
Network and DNS logs show which services are being reached from managed devices. It is the fastest discovery source and the one most likely to be misread.
Applying the boundary described in “Network and DNS Evidence” requires a clear operational purpose and a record that can be reviewed without reading private content. Teams considering the planning resource can use workload and time evidence to understand how approved processes are actually used, while keeping AI discovery, security telemetry and employee monitoring separate and proportionate.
For an independent benchmark, compare the local approach with OWASP GenAI Security Project; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.
What it shows
Which AI services are being contacted, and roughly how often.
From which network segments, which maps to sites and sometimes departments.
Trend over time, which shows adoption.
Enough to build a list of services to investigate, which is what discovery needs.
What it does not show
What was sent. Volume is not content, and treating a large upload as a data breach without looking is a mistake in both directions.
Whether it was work or personal. A lunchtime query is in the same logs.
Anything on personal devices or off-network, which after any blocking attempt is where much of the activity lives.
And API traffic from automations, which looks different from browser traffic and is easy to miss.
Reading it proportionately
A service appearing in DNS logs means somebody looked it up, not that data went anywhere.
Page loads and queries are indistinguishable without deeper inspection.
Use it to build the list of services, then investigate the ones that matter by asking.
The embedded-feature problem
AI features inside approved tools generate traffic to the approved domain.
Which means they are invisible to this method entirely.
Check your approved tools' AI features separately, because they are the largest blind spot in network-based discovery and the fastest-growing one.
What to do with the list
Group by: clearly consumer AI services, business services with AI features, developer tools, and unknown.
The unknown group is worth a look — it frequently contains an extension or an integration nobody knew about.
Then work by service rather than by user.
The restraint point
These logs can identify who contacted what, and that capability should be used carefully.
For discovery you need counts by service, not names.
Aggregate before the data leaves the security team, because a list of names circulating is what turns an inventory exercise into an investigation.
Where this fits
Good for breadth: which services exist in the estate.
Poor for depth: what is actually happening with them.
It is the first source to consult and never the only one.
What to check
Can you produce a list of AI services contacted in the last month, by count rather than by user?
Have you checked AI features in your approved tools separately?
Is there API traffic you have not looked at?
And does the output leave the security team aggregated?
The point
Network logs show which services were contacted, not what was sent.
Use them to build the list, then investigate by asking.
Underlying all of this
Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.
The recurring pattern
The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.