Finding shadow AI on a Windows fleet without reading a single prompt

Your AI inventory has a blind spot, and it’s exactly the shape of the tools that bypass your network monitoring.

Every shadow-AI product on the market watches traffic. They’re good at “someone pasted source into chat.openai.com.” None of them can see a model running entirely on a workstation - Ollama serving on localhost:11434, a model directory sitting on disk - because there’s no traffic to inspect. The data never leaves the box.

Let me concede the obvious objection up front, because a sharp security lead will raise it: a local model is arguably the safest place for sensitive data. It never leaves. So if your worry is data exfiltration, the local model is the wrong villain - which is exactly why the DLP and CASB tools ignore it. They’re not incapable of seeing it; they decided it isn’t their threat.

So why does it matter? Because you can’t govern what you can’t see, and you can’t attest to an inventory with a known hole in it. When an auditor asks you to prove what AI is touching regulated data, “everything except the local stuff” is not an answer. The value here isn’t that local models are a five-alarm fire - it’s completeness: an AI inventory that includes the one category every other tool structurally misses. That’s the whole pitch, and I’m not going to inflate it past that.

When I added AI visibility to RFF, I set two rules before I wrote a line of it.

Rule 1: content-blind, forever

RFF will never read a prompt, a response, or a byte of traffic. Not “we don’t today” - can’t, by design. The signal is identity and metadata only: what’s installed, what’s listening, what’s on disk. The same class of fact RFF already collects every day for installed-software and patch inventory.

I ran this stuff in hospitals for years. Anything that reads content has to clear a privacy review, a legal review, and a “what happens when this leaks” conversation, and it should. Inventory-grade facts - “box X has Ollama installed” - don’t. I want this to pass a privacy review on the first read, and I want to never be in the business of being a DLP product. The minute you start inspecting prompts you’re competing with companies that have raised nine figures to do exactly that, and you’ve quietly become the thing your customers have to audit.

Content-blind isn’t a limitation I’m apologizing for. It’s the point.

Rule 2: no new process, no new clock

The detection rides the daily inventory pass the agent already runs. There’s no new background service, no new privilege, no new attack surface, no new thing to sign and ship. Collecting “is Ollama installed” is the same shape of work as collecting “is Chrome installed” - same schedule, same channel, same least-privilege footprint. Adding a separate process for it would multiply the signing, MSI, update, and SYSTEM-attack-surface cost for a job the agent is already built to do.

And it’s targeted, not a firehose. RFF does not dump a full process list off every box forever - that’s a surveillance and data-volume problem dressed up as a feature. It collects specific, cataloged evidence: known AI app names in the uninstall registry, known local-model runtime binaries, known listening ports, known model directories. Filter first, then report.

How the detection actually works

There are a few signal types, and they’re ranked by how much you can trust them:

installed app (registry)   ─ strongest, has a real uninstall entry
listening port             ─ "this was serving at last sweep"
on-disk model directory    ─ durable, "this exists"
running process            ─ weakest identity on its own

The installed-app signal reads the same Add/Remove Programs registry keys Windows itself uses - the exact mechanism behind fleet-wide uninstall. If there’s a DisplayName, RFF can both see it and, later, remove it.

The local-runner signals are the part nobody else fills. A listening socket on 11434 is Ollama’s signature; a model directory on disk is durable evidence that survives a reboot. There’s no network traffic to give these away, so a network-based tool can’t - RFF catalogs the runners by name: Ollama, LM Studio, GPT4All, Msty, NVIDIA ChatRTX, AnythingLLM, ComfyUI, and a growing list. Not because a local model is uniquely dangerous, but because an inventory that omits them isn’t complete.

A note on honesty, because I put it right in the source comment: this is signature-based. RFF detects what’s in the catalog and says nothing about what isn’t - this is visibility, not airtight control. The catalog rots weekly (there’s a new AI tool every Tuesday), so keeping it current is the actual work. More on where the edges are at the end.

The precision lock: why “Cursor” alone is only a maybe

Here’s the part I’m most careful about, because the cost of getting it wrong is a false-positive uninstall on a clinical or production box.

Some AI tool names are distinctive - “ChatGPT”, “Perplexity”, “Windsurf”. A match on one of those is a real signal. But some are collision-prone: “Copilot” shows up in a dozen unrelated extensions, “Claude” is somebody’s first name, and “Cursor” matches mouse-cursor utilities and cursor-theme packs that have nothing to do with Anysphere’s editor.

So every match gets a confidence:

High - a distinctive name and the vendor’s publisher corroborate it. “Cursor” published by “Anysphere” → that’s the editor.
Medium - a distinctive name, but no publisher to back it up.
Low - only a broad, collision-prone token matched. “Cute Cursors” by “CursorFX Co” reads low, and it should.

That tiering isn’t cosmetic. It gates what’s allowed to be removed automatically. The single predicate that decides it is:

public static bool IsBulkRemovable(AiToolHit hit) =>
    hit.MatchedOn == "installed" && hit.Confidence == "high";

Only a high-confidence installed app - a real registry entry with a publisher that corroborates - is ever eligible for non-interactive or bulk removal. A listening port has no DisplayName to uninstall. A medium or low match stays human-confirmed. The blast-radius case - wiping something because a mouse-cursor utility carried the token “Cursor” - is exactly what this is built to refuse.

When you do find a local runner, it’s not nothing

I conceded above that local models aren’t a data-exfil threat. So why catalog the runners at all? Because a local runner is unvetted, internet-sourced server software, and that’s a category IT has always had to manage - AI or not.

It’s a network service with a CVE history. Ollama ships a server that listens on a port. In mid-2024 it had a real remote-code-execution bug - CVE-2024-37032, “Probllama,” a path traversal that let an attacker overwrite files and get RCE. People bind these to 0.0.0.0 more often than you’d hope. “Is there an unpatched Ollama listening on this box?” is a patch-management question, and patch management is RFF’s day job.
The model files themselves are a supply-chain surface. Pickle-based model weights can execute arbitrary code on load - that’s the whole reason the safetensors format exists. Pulling a random model off the internet is running untrusted code as the logged-in user.

But here’s the honest boundary, because it matters: RFF detects that the runtime is present - not what the model file contains. I’ll tell you “Ollama is on this box, and here’s whether it’s a version with a known hole.” I do not crack open the weights and tell you they’re malicious - that’s a content-level job I’m deliberately not doing (see Rule 1). The deliverable is the same one RFF gives you for any unvetted server software: it’s here, decide if it’s sanctioned, then patch it or remove it.

From visibility to governance

Seeing the tools is step one. The workflow people actually want is the boring allow-list one: sanctioned vs unsanctioned, plus an action.

In RFF you bless a tool - fleet-wide, or for a specific group (“the design team can have Cursor; nobody else”). Anything sanctioned drops off the drift report. Anything unsanctioned and high-confidence is a candidate for removal. The group rule is deliberately fail-safe: if any group a device belongs to sanctions a tool, that device keeps it, even during a fleet-wide sweep. When in doubt, RFF leaves it alone.

Removal reuses the exact same uninstall engine as the manual fleet uninstall - one source of truth for “which device × which tool gets removed,” so the manual path and the automated path can’t drift apart. The agent resolves the uninstall command locally from the registry; the server only ever ships a name, never a command. (Same reasoning as the uninstall post: machine-specific paths go stale, and shipping commands is a command-injection surface I don’t want.)

The automated sweep is off by default and, when armed, has guardrails I lifted straight from our Patch Tuesday roller:

Approval-gated - the sweep queues uninstall jobs; an admin still clicks approve. It doesn’t fire on its own.
Canary rings - it stages a tool across small waves, not the whole fleet at once.
A health gate - if a wave’s success rate drops below threshold, the next ring doesn’t roll. One toggle can’t nuke a fleet.

I’m pre-revenue and running this against a lab fleet, so I built the right-sized version of that - not a multi-day soak-window orchestrator. But the safety shape is the same: a single approval can’t touch every machine.

What it deliberately does not do

No prompt inspection. No content. No traffic. Said it twice already; it’s the whole thesis.
No 30-minute usage-frequency timeline. I looked hard at “sample what’s running every half hour and draw a surveillance graph.” It’s the wrong axis. Nobody’s buying-decision hinges on a per-keystroke AI-usage chart, and building one drifts you toward surveillance for a signal you don’t need. Coverage and action win; sampling the same fact more often doesn’t.
Cloud-service detection is separate and still content-blind. Spotting that a box talks to api.openai.com is a different, network-level signal - and even that is “which endpoint,” never “what was said.”

What this is, honestly

This isn’t a revolution. It’s signature-based: I detect what’s in the catalog and say nothing about what isn’t. A determined user with a renamed binary evades until I catalog it. Anyone selling you complete shadow-AI detection is selling you a confidence they can’t actually have.

What I’m selling is smaller and truer: the AI inventory you didn’t have - including the local-model hole nobody else fills - content-blind enough to survive a privacy review, and honest about exactly where its edges are. If you need a nine-figure DLP platform to inspect prompts, go buy one. If what you actually need is to answer “what AI is running on my fleet,” including the stuff that never touches the network, that shouldn’t cost extra.

So it’s bundled free, up to your first 100 endpoints like everything else in RFF. Detection is free; the governance layer - sanctioning and the staged auto-remediation above - is the paid part, because that’s the bit that does work for you. Seeing what’s there is table stakes, not an upsell.

RFF is a Windows fleet management tool - patch, deploy, audit, remote desktop, and now AI visibility, all from a browser tab, no VPN. Free for your first 100 endpoints - getrff.com.