An engineer pastes a production config into a chat model to debug it faster. The model endpoint sits on a domain your gateway has never seen. The session is logged in, the token is valid, the read is allowed. Nothing in your stack objects, because nothing in your stack was wrong. A sensitive file just left the building through a door you held open.
That is shadow AI. Not a rogue app on the network, but sanctioned people pushing real data into models nobody approved, using access you handed them on purpose.
Most teams fight it by naming the tools. Block the domains. Publish an approved list. Tell people not to paste. Then a new model ships, and the list is stale before the wiki page renders. You are playing a naming game against a catalog that grows weekly and never repeats.
Shadow AI is not a tool problem. It is a movement problem. Govern the wrong thing and you lose by default.
Why the blocklist loses
Every conventional defense against shadow AI rests on one assumption: that you can enumerate the bad tools before they move data.
A CASB or a secure web gateway blocks the AI domains it already knows. An identity-provider allowlist permits the sanctioned model and denies the rest. A DLP rule fires when a known pattern leaves through a known channel. All of it works only on tools you already named.
The catalog of AI tools is now effectively infinite and refreshes faster than any review cycle. New model endpoints, new wrappers, new browser extensions, new agents bolted onto SaaS apps you already pay for. Each one moves data through access your people already hold: a logged-in session, an API token, an OS-level paste. By the time a tool reaches your list, it has been quietly moving data for weeks.
Enumeration also fails in a quieter way. It tells you the day you wrote a rule. It tells you nothing about the day before, and nothing about the move that matches no rule you thought to write.
The move is the unit, not the app
You do not need to recognize the tool. You need to see the data leave.
Strip away the logo at the far end and every shadow-AI leak has the same shape on your side. A known identity reads data it is allowed to read, then sends that data somewhere it does not normally go. The destination is new. The volume is off. The hour is odd. The job behind the move does not usually touch this path. The permission was real. The pattern is the breach.
That shape is visible whether the tool is two days old or two years old, because it lives in the movement, not in the tool's reputation. A summarizer you have never heard of draining a customer table looks identical to a known-bad endpoint doing the same thing: an identity moving high-value data to a place it has not moved it before. Identify the app, and you are always late. Watch the move, and the app's name stops mattering.
The catalog is unbounded. The movement is finite, and it is yours.
Watching the move at runtime
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It never sits between your data and its destination, and it does not read your data to know a move is wrong. Roughly 0.1% of one core and 4 to 8 MB of memory per host, single-tenant inside your own cloud.
Each move resolves to a probabilistic, source-dependent identity: which user, which process, which destination, and whether this fits what that identity normally does. An engineer's session starts streaming a config file to a model endpoint this host has never spoken to. The deviation lights up across layers at once. The destination is new for this identity. The data is sensitive. The job behind the move is a code editor, not the batch process that usually touches that path.
One signal alone is noise. People reach new endpoints all day. Stack them on a high-value read and you have a pattern, and a pattern is a case, not an alert.
Because the collector watches movement instead of recognizing tools, the next AI product your team adopts is covered the moment it moves data, not the moment someone files it on a list. No rule to write, no domain to learn, no signature to push. A tool that did not exist when you deployed Hilt answers to the same question as everything else: does this identity normally move this data, this way, to this place.
What this does not replace
The gateway and CASB you already run do real work here. They give you the policy plane: sanctioned model here, blocked categories there, the AI usage you can decide about in advance. Hilt does not replace that. If you want to forbid a whole category of tool, that decision belongs in your gateway, not in a runtime governor.
Hilt adds the layer those tools were never built to cover: the move no rule anticipated, run by a legitimate user through access you granted on purpose, to a destination nobody listed. Your gateway governs the tools you chose to think about. Runtime governance covers the ones you did not, including the one that ships after you finish reading this.
When the pattern is dangerous, Hilt isolates the host at the network from the control plane, quarantine, never by filtering packets in the path. The collector observes the move and writes the case. The response happens at the network, off your traffic.
Questions worth asking
If you are weighing how to handle shadow AI, the useful questions are not about which tools a vendor blocks. They are about the tool nobody has named yet.
Does coverage depend on a list? Ask whether a brand-new AI endpoint is governed on day one, or only after someone adds it. If the answer is a blocklist or an allowlist, your coverage is exactly as fresh as your list.
Does it govern the move or recognize the app? A system that resolves each move to an identity, the user, the process, the destination, and scores it against how data normally moves does not care what the tool is called. A system that matches known signatures cares very much, and falls behind.
Does it have to read your data? Metadata-only by default means you see that a sensitive table left for a strange destination without inspecting its contents. Content-aware inspection is there when you want it, never the price of admission.
Where does the data stay? Watching AI-bound movement should not route your most sensitive moves through a vendor's SaaS to be judged. The path from kernel event to written case runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and events never leave your account.
Govern the move, not the catalog
You cannot win shadow AI by naming the tools. The list is stale on arrival, and the danger was never the tool's identity. It was the data leaving on access you granted on purpose, to a place it does not normally go.
See that move while it happens, at runtime, and the next unapproved AI tool is one more move to govern, not one more fire to chase.
If your current stack cannot tell you that an engineer's session just streamed a sensitive config to a model endpoint this host has never touched, resolved to the job behind it and scored against how that data normally moves, that is the gap. Bring an endpoint you are worried about to a 30-minute technical call and we will walk the move through together.