If You Had 60 Days to Purge DeepSeek From Your Network, Could You Even Find It?

The US Secretary of Homeland Security has ordered DeepSeek banned across all federal agencies. IT teams have 60 days to purge it from their systems, with exemptions going through CISA. The stated concerns: data sovereignty, weak Chinese data-protection laws, and security vulnerabilities in a foreign-hosted model.

Now forget the federal government for a moment. Think about what happens when your CFO reads that headline over breakfast. By 9:15 AM there's a ticket in your queue: "Legal needs written confirmation by Friday that DeepSeek is not used anywhere in the company."

Can you answer that question? Honestly?

If your environment looks like most, your "answer process" is: pull an installed-applications report from the RMM, ask around in the team chat, maybe grep a week of firewall logs (if logging is even enabled), and hope nothing surfaces after you've signed the memo. What that process misses: the developer using DeepSeek in a browser tab, the API key buried in a Python reporting script, the support lead who installed a desktop client, and the intern running Ollama on a spare tower under his desk.

That's the real lesson of the DeepSeek ban for IT teams. It isn't about one model. It's a stress test of a question almost nobody can answer with confidence: do you actually know what's running on your network right now?

The Problem: Your Inventory Is a Snapshot, Not a State

Agent-based tools only see agented machines

Your RMM — ConnectWise Automate, NinjaOne, Datto RMM, whichever — is very good at managing the 240 machines that have agents installed. It is completely blind to everything else: the printers scattered across departments, the 14 IP cameras on their own VLAN, the vendor's loaner laptop, the smart TV in the conference room, the Raspberry Pi someone deployed in 2023 for a "temporary" dashboard. None of those have agents. None of them show up in your compliance reports. All of them can talk to whatever they want.

Browser-based AI leaves no footprint an agent can see

DeepSeek's primary interface is a web app and an API. It installs nothing. Scan your uninstall keys and you find nothing, because there's nothing to find. Unless you're watching DNS queries or egress traffic at the network level, browser-based AI usage is invisible to every agent-based tool you own. That's true for ChatGPT, Gemini, Claude, and a hundred others — DeepSeek is just the one that made the news.

Your discovery data is stale the moment it's collected

Most teams run network scans monthly at best, usually quarterly before an audit. Some still work from a Visio diagram last touched in 2019 by a network admin who left two jobs ago. The result: when you need ground truth about what's connected where, you don't have it. You have a rough guess — and a guess is a terrible thing to put in writing to a legal department.

Then the silos make it worse

Even when the data exists, it lives in four places that don't talk: the RMM knows about agented endpoints, the firewall knows about flows, the switches know about MAC addresses — if SNMP is even enabled, which on half your access switches it isn't — and the helpdesk knows only what users complain about. Answering "where is this used?" means manually reconciling exports from all four in a spreadsheet. Ask any MSP tech how long that takes for a single client and watch the thousand-yard stare.

What it costs in practice

Here's a scenario that will feel familiar. A client in a regulated industry forwards you the DHS announcement and asks the same question legal asked federal agencies: prove it's not here, within 60 days. With siloed tools:

• Two techs spend three hours pulling installed-app reports across every managed endpoint — which catches nothing used in a browser.
• The firewall at HQ has logging enabled; the branch units don't, so half the sites can't be checked at all.
• Someone does a physical walkthrough and finds a smart display and a contractor access point that appear in zero documentation.
• The final report still contains a line reading "unidentified devices: 11."

That's most of a week of senior technician time, and the answer is still "mostly no." And here's the kicker: the same blindness that hides AI tools also hides the rogue DHCP server that took down a VLAN last month, the unpatched camera that keeps crashing the access switch, the second router plugged into the wall port by someone who "just wanted better Wi-Fi." This isn't only a compliance problem. It's an uptime problem.

How AlertMonitor Closes the Gap

Continuous discovery, not quarterly scans

AlertMonitor discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Not just machines with agents. Everything that touches the network shows up, including the devices your RMM has never heard of.

A live topology map that reflects reality

The map is always current. When a new device appears, an alert fires immediately with full context: what it is (the MAC vendor OUI tells you "Raspberry Pi" before you even walk over there), which switch and port it's connected to, and which VLAN it landed on. When a switch drops offline or a link goes down, you get that alert with the same network context — not a bare "host unreachable" ping failure that sends you hunting through three tools to figure out where the box even is.

So when the purge request lands, the workflow looks like this:

A purge request that consumed most of a tech's week becomes a 30-minute exercise — and the evidence you hand over is a live map, not a guess.

The same visibility pays off every other day

The purge request is the exceptional case. The daily value is quieter: the new device on the warehouse VLAN gets investigated in minutes instead of being discovered during a quarterly audit; the flapping link between the core switch and IDF-2 is pinpointed to a specific port before users notice; and if you run an MSP, every client gets a live per-site map in one NOC view instead of twelve tabs across five tools.

What You Can Do Today

If you're staring down an AI-audit request — or you just want to know what's actually out there — start with these four checks. They're not glamorous. They work.

1. Sweep managed endpoints for installed AI clients

# Audit managed Windows machines for installed AI tools and local LLM apps
$computers = Get-Content C:/audit/computers.txt
$patterns  = "DeepSeek","Ollama","LM Studio","GPT4All","Jan"

Invoke-Command -ComputerName $computers -ScriptBlock {
    param($patterns)
    $keys = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
            "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
    Get-ItemProperty $keys -ErrorAction SilentlyContinue |
        Where-Object {
            $name = $_.DisplayName
            ($patterns | Where-Object { $name -like "*$_*" })
        } |
        Select-Object @{n="Computer";e={$env:COMPUTERNAME}},
                      DisplayName, DisplayVersion, Publisher
} -ArgumentList $patterns |
  Export-Csv C:/audit/ai-tools-installed.csv -NoTypeInformation

This catches desktop clients — Ollama, LM Studio, GPT4All, vendor desktop apps. Remember that it cannot see browser usage, which is exactly why the network-level checks below matter.

2. Check DNS for AI service lookups

If you run Windows Server DNS, the query log tells you which machines have been reaching out to which AI services:

# Search Windows DNS server analytical logs for AI domain lookups
# (View > Show Analytic and Debug Logs > enable the Analytical log if it returns nothing)
$domains = "deepseek","openai","anthropic","ollama","gemini"
Get-WinEvent -LogName "Microsoft-Windows-DNS-Server/Analytical" -Oldest |
    Where-Object {
        $msg = $_.Message
        ($domains | Where-Object { $msg -like "*$_*" })
    } |
    Select-Object TimeCreated, Message |
    Export-Csv C:/audit/dns-ai-lookups.csv -NoTypeInformation

3. Find local inference servers hiding on the LAN

Local LLM servers are the shadow IT nobody checks for. Ollama listens on TCP 11434 by default:

# Find machines listening for local AI inference traffic (Ollama defaults to port 11434)
Invoke-Command -ComputerName (Get-Content C:/audit/computers.txt) -ScriptBlock {
    Get-NetTCPConnection -State Listen -LocalPort 11434 -ErrorAction SilentlyContinue |
        Select-Object @{n="Computer";e={$env:COMPUTERNAME}},
                      LocalAddress, LocalPort, OwningProcess
}

4. Pull MAC tables from your switches — the ground truth

This is the check that finds everything else, including agentless devices:

# Pull the ARP table (ipNetToMedia) from a core switch
snmpwalk -v2c -c "$COMMUNITY" 10.0.0.2 .1.3.6.1.2.1.4.22.1.2

# Map a MAC address to a physical switch port (dot1dTpFdbTable)
snmpwalk -v2c -c "$COMMUNITY" 10.0.0.5 .1.3.6.1.2.1.17.4.3.1.2

Every MAC in those tables is a device on your network. If you can't match a MAC to an entry in your documentation, you've found your answer — and probably a few surprises.

5. Stop doing this manually

Steps 1–4 answer the question once. They don't keep the answer true, because networks change daily. This is the part AlertMonitor automates: continuous discovery over SNMP, ARP, and active scanning keeps the map current, and a new-device alert means the next shadow AI server gets flagged the moment it touches the network — not 60 days later during a fire drill. Turn on discovery, enable new-device alerts, and schedule a weekly topology export as your standing compliance evidence.

The Takeaway

The federal government needed an executive order and a 60-day deadline to deal with one AI tool. You don't need an executive order. You need to know what's on your network — and for most teams, the first honest answer is "we'd have to go find out." That answer is fixable, and it starts with treating network discovery as a continuous function rather than a quarterly chore. When the next "prove it" request lands — and after DeepSeek, it's a when, not an if — the teams with a live map answer it before lunch. Everyone else opens a spreadsheet.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources