Your Network Map Is Lying to You: Live Discovery for the Age of AI Desktop Agents

OpenAI just shipped an update that looks small and isn't: the browser built into the ChatGPT desktop app now supports Chrome extensions — 1Password included — with its own logins, tabs, downloads, and persistent cookies, kept separate from the user's normal Chrome profile. OpenAI also added enterprise controls, which is welcome. But read it the way an IT team should: another piece of persistent, semi-autonomous software just landed on your endpoints, and in most organizations IT will find out about it when a user mentions it in passing — or when something breaks.

Nobody here is arguing against ChatGPT. Your users will adopt it regardless, and it genuinely makes them faster. The point is what it represents: the estate you support changes every week. New agents, new browser profiles, new devices plugged into switches you have never seen. The only real question is whether your network visibility shows today's network or last quarter's.

If you are the sysadmin who learned about a rogue device because it caused an IP conflict, or the MSP tech with a Visio diagram in one tab and three monitoring tools in the others, keep reading.

The Problem: Your Discovery Runs Weekly. Your Network Changes Daily.

Scheduled scans are a snapshot, not visibility

Most networks are "discovered" by a scheduled job: an nmap sweep in a cron entry, a weekly Spiceworks scan, a quarterly asset spreadsheet nobody trusts. Everything that happens between scans is invisible. A user plugs a cheap consumer switch into a conference room drop on Monday. Your next scan runs Friday. Between those two points that switch can create a loop, hold a stale IP that collides with a server, or simply sit there as the one device you cannot account for at the next audit.

Poll-based monitoring only watches what you told it to watch

SolarWinds, PRTG, Nagios, Zabbix — capable tools, all with the same structural limitation: a device is monitored only after a human adds it. If you do not know a device exists, it never appears on a dashboard, never triggers an alert, never shows up in a dependency map. When the unmanaged switch nobody onboarded starts a broadcast storm, the monitoring console stays perfectly green while users cannot reach the file server. These tools do not have blind spots by accident. They have them by design.

RMM agents cover only the managed half of the estate

NinjaOne, ConnectWise RMM, Datto RMM — agents earn their keep on endpoints. But agents only exist where someone deployed them. Printers, IP cameras, access points, unmanaged switches, the conference room mini PC, the vendor laptop someone brought in — no agent, no visibility. On a typical mid-size network, unmanaged devices are easily a third of what is actually connected, and they are exactly the portion most likely to change without anyone telling IT.

The "map" is a Visio file from two years ago

Ask three techs what is connected to the core switch and you will get three answers, then somebody opens the Visio diagram last edited before the office move. Diagrams are documentation, not telemetry. They are wrong the moment someone moves a cable — and someone moves a cable every week.

Why these gaps exist

Not incompetence — architecture. Discovery, monitoring, RMM, and helpdesk were built as separate products, often by separate vendors, and "integration" usually means an API and a support article. Discovery writes to a database the monitoring tool never reads. Alerts fire without topology context, so nobody knows which upstream switch or which client site is affected. The helpdesk has no idea what device the user is even talking about. Each tool is individually reasonable; together they make your team the integration layer — at 9 a.m. with a full queue, or at 2 a.m. with a page.

What it actually costs

• MTTR inflation. The first 20–40 minutes of a typical network incident is not fixing anything — it is identification. What changed? What is on that uplink? Which switch is that, and which port?
• A very normal Tuesday. 9:40 a.m., three tickets: "cannot reach the shared drive." Old workflow: remote into a machine, ping, tracert, SSH into switches, hunt for a MAC address, and finally discover an unmanaged switch someone added last week. Resolution time: about 75 minutes.
• Technician hours. Fifteen network-adjacent tickets a week with 20–25 minutes of "what is that device and where is it" overhead is five to six hours per tech, per week, spent playing detective. That is most of a workday, every week, per person.
• SLA and audit exposure. SLA clocks run while techs trace cables. Cyber-insurance questionnaires and compliance frameworks ask for a complete asset inventory, and "roughly, from a scan in March" is not an answer.

How AlertMonitor Keeps the Map Honest

Continuous discovery, not scheduled snapshots

AlertMonitor continuously 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 a weekly cron job: continuous. When a new device appears, it shows up in minutes with the context that matters: what it is, where it is connected, which port, which upstream switch.

A topology map that reflects right now

The live topology map is always current. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full network context — the affected link, the parent device, the blast radius. Nobody opens Visio at 2 a.m. because the map on screen is the network as it exists at 2 a.m.

Change detection built into alerting

Most monitoring answers "is it down?" AlertMonitor also answers "what changed?" New device on the accounting VLAN. Link between core switch A and distribution switch B dropped. Access point offline at the branch. Alerts route into the same platform as your helpdesk and RMM, so the ticket that gets created already links to the device, the map, and its history.

The workflow, side by side

Old way: ticket → remote session → ping and tracert → SSH into switches → MAC hunt → guess. Forty to seventy-five minutes before fixing even starts.

AlertMonitor: change alert arrives with device, port, and topology context → click the device on the live map → act. Identification is measured in seconds, not sprints between tabs.

And because discovery, monitoring, helpdesk, and patching share one platform, the camera facilities just installed shows up as a discovered device with an alert, gets an asset record, lands on the map, and — if it needs patching or a config check — is handled in the same console. No fourth tab.

Practical Steps You Can Take Today

1. Build a baseline inventory right now

Before any platform changes your life, get ground truth. Run this from a workstation on the VLAN — the ping sweep populates ARP, and the export gives you a dated inventory (it takes a few minutes, get coffee):

# Ping sweep a /24, then export the ARP table as a device inventory
$subnet = "192.168.10"
1..254 | ForEach-Object {
    Test-Connection -ComputerName "$subnet.$_" -Count 1 -Quiet | Out-Null
}

Get-NetNeighbor -AddressFamily IPv4 |
    Where-Object { $_.IPAddress -like "$subnet.*" } |
    Select-Object IPAddress, LinkLayerAddress, State |
    Sort-Object IPAddress |
    Export-Csv "C:\Reports\network-inventory-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

2. Spot new devices by diffing today against yesterday

# List devices present in today's inventory but not yesterday's
diff "network-inventory-$(date -d yesterday +%Y%m%d).csv" \
     "network-inventory-$(date +%Y%m%d).csv" | grep '^>'

Every > line is a device someone added without telling you. Run this once and you will never trust a quarterly scan again.

3. See what new desktop software is actually doing

When users adopt tools like the ChatGPT desktop app and its built-in browser, check which processes hold live connections on a workstation:

# List processes with established network connections
Get-NetTCPConnection -State Established | ForEach-Object {
    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Process    = $proc.ProcessName
        PID        = $_.OwningProcess
        RemoteAddr = $_.RemoteAddress
        RemotePort = $_.RemotePort
    }
} | Sort-Object Process | Format-Table -AutoSize

4. Ask your switches what they see

The switch is the source of truth. Pull interface status and descriptions directly:

# Check port status and descriptions on a switch via SNMP
COMMUNITY="your-snmp-community"
SWITCH="192.168.10.2"

snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifOperStatus snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifAlias

If ifAlias descriptions come back empty, that is your weekend project — and a sign you are running on memory instead of metadata.

5. Move from snapshots to continuous with AlertMonitor

The manual steps above prove the point; they just do not scale. In AlertMonitor:

1. Add SNMP credentials for your switches, firewalls, and access points, and define the subnets to scan.
2. Let continuous discovery build the live topology map, then verify your core links once.
3. Create alert policies for what matters — new device detected, switch offline, link down, device flapping — routed to the right tech or client queue.
4. Connect the helpdesk so change alerts create tickets with device and map context attached.
5. Archive the Visio file. The map is the network now.

The Bottom Line

ChatGPT's new desktop browser with extensions and persistent logins is just the newest wave in a permanent trend: the estate you support changes constantly, and most of that change is invisible to quarterly scans and static diagrams. Teams that run on live discovery and a live topology map stop learning about their network from outages — and start catching change before it becomes an incident.

Related Resources

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