Shadow AI discovery: read DNS evidence carefully

Use DNS logs as a starting point for shadow AI discovery, with each conclusion tied to the signal actually collected. A resolver can record a requested hostname and its policy decision. Establishing an application connection, service account, prompt submission or completed upload requires additional evidence.

DNS translates names into information clients use to reach services. A name lookup can happen before a person opens a page, through a background process or as part of a later interaction. Build the discovery record around that limited observation.

Cloudflare Gateway provides the concrete examples here. This guide proposes read-only interpretation and controlled tests; no employee activity or customer deployment was inspected.

Read the event before counting AI use

Cloudflare's Gateway activity-log documentation describes records for inspected DNS queries, network packets and HTTP requests. Those are separate event classes with different fields and meanings.

The Gateway DNS export schema includes the queried name, time, query type, policy action, resolver decision and response details. User, device and registration fields can be available depending on the collection path.

Start with the statement the record supports: a particular name was queried through this resolver at this time. An AI-service classification helps prioritise investigation. Confirm the destination's actual function before attaching a stronger usage claim, especially where related services share infrastructure.

Keep the DNS decision at the lookup stage

Cloudflare's DNS-policy documentation explains that these policies act during name lookup. An allow result records permission at that stage. A block records the resolver's handling of the observed query.

The next stages require their own evidence: connection establishment, application interaction, account context and any content transfer. A successful DNS response can be followed by no connection at all. Conversely, a client may reuse an earlier answer or an existing connection.

When presenting a discovery finding, name both the observation and the unanswered question. For example, record the hostname and resolver decision, then ask the application owner whether that destination supports an approved workflow. Avoid interpreting a lookup count as a prompt or upload count.

Check what the identity field represents

Gateway can associate events with a registered client or a configured DNS location. An email field may identify client registration, while non-identity collection paths can use a synthetic identity value. Device names and registration identifiers also need careful interpretation.

Ask how each field was populated and whether a shared device, forwarded query or network address translation affects attribution. A resolver identity and an account signed into the destination AI service are separate facts.

Keep person-level conclusions proportionate to the evidence and the organisation's authorised monitoring purpose. Start with service ownership and collection coverage. Workforce investigations require their own governance, access controls and applicable legal review.

Account for caches and resolver scope

RFC 1034 describes DNS caching and time-to-live behaviour. A client or intermediate resolver can answer from a cache, leaving no fresh query at Gateway during the observation window.

Gateway's cached-response field describes a response to a query that reached Gateway. It cannot reveal every answer served earlier by a different cache. Include the observation window and collection path when comparing event counts.

Encrypted DNS also needs a precise scope statement. Cloudflare supports DNS over HTTPS, including browser configuration. Filtering depends on queries reaching the intended Gateway endpoint. Encryption alone leaves that routing question unresolved.

Cloudflare's Local Domain Fallback documentation states that matching queries bypass Gateway DNS policies and logging. Check relevant exclusions and logging configuration before interpreting an empty result.

Use two contrasting controlled observations

Choose a dedicated test device and an organisation-controlled harmless hostname. First perform only a name lookup. Confirm the resolver event and independently check that the controlled destination received no application request. This demonstrates the difference between those observations without involving a public AI account.

Next perform an authorised request to the controlled destination. Compare resolver, connection and server observations by time and test identifier. Repeat within the documented cache interval to see which collection layer observes another event. Keep cache behaviour and logging delay separate.

Record the resolver endpoint, client mode, available identity fields, exclusions and reporting window alongside the results. Where a signal is absent, investigate configuration and coverage before drawing a conclusion about use.

Turn discovery into an owned question

For each candidate AI destination, record the observed name, classification source, collection scope, attribution confidence and responsible reviewer. Link any corroborating evidence separately. Define what remains necessary before a policy or incident decision.

Our shadow AI proof-of-coverage guide covers browser, desktop and API routes more broadly. DNS evidence contributes one useful part of that review, with a clear boundary around what it can establish.

Map your shadow AI discovery signals with Promptective.