Skip to content
Product

Shadow AI is a visibility problem before it is a policy problem

Blocking a list of known AI domains isn't governance. Here is what actually has to be measured first.

CFCyForte EngineeringProduct · Jul 28, 2026 · 7 min

Most organisations wrote an AI acceptable-use policy in the last eighteen months. Very few can tell you whether it's being followed. The policy names a handful of approved tools and prohibits the rest, and enforcement is a domain blocklist on the web proxy.

Three things a blocklist cannot tell you

  1. Which tools are actually in use. New AI products appear weekly, and a blocklist only knows what someone added to it.
  2. What left in the prompt. A domain is allowed or blocked. The content that went to it is invisible, so an incident can't be scoped afterwards.
  3. Whether the person was behaving unusually. Volume and destination mean nothing without a baseline for that individual.

Content, not destination

The useful unit of analysis is the content of the request, not the hostname it went to. Personal data, credentials, and source code are detectable in a payload. Once you inspect content, the governance question changes from which tools are allowed to which data classes may leave, and for whom. That is a policy you can actually enforce.

A useful first step

Before writing any policy, run discovery for two weeks and look at the list of destinations. The gap between what the policy assumes and what the traffic shows is usually the whole argument for doing this properly.

Then the frameworks follow

ISO 42001, the OWASP LLM Top 10, and the EU AI Act all expect you to know what your AI usage looks like. None of them can be answered from a blocklist. Once detection is content-aware, framework mapping becomes a reporting exercise rather than a research project.

Book a demo

See CyForte on your own alerts.

Thirty minutes with a security engineer, not a slide deck. Tell us the use case when you book and we will open the agent that owns it.