Your AI Browser Agents Are Invisible to Network Monitoring — BragJack Just Proved Why That's Dangerous

Your helpdesk just got Copilot. Your engineers are running Perplexity Comet. Someone on the network team swears by Claude in Chrome. And according to BragJack — the proof-of-concept that earned more than $20,000 in bug bounties and two CVEs — a single malicious browser extension can seize control of every one of those AI agents across Chrome, Edge, Opera Neon, Perplexity Comet, and Claude in Chrome. No further user interaction required. Once the extension is installed, the agent is not yours anymore.

Here is the uncomfortable question for everyone running IT: if an AI browser agent on one of your workstations got hijacked tomorrow, how long would it take you to even know that agent existed? For most teams the honest answer is: never. Not because you are bad at your job, but because the browser layer is a blind spot in nearly every monitoring, RMM, and network discovery stack deployed today.

The Problem in Depth

AI agents are unmanaged assets wearing a browser's costume. Your discovery scan sees the workstation. Your RMM sees "Google Chrome 131." Your firewall sees HTTPS to known CDN ranges. What none of them sees is that inside that browser lives an autonomous agent with the user's authenticated sessions — permission to read mail, open tickets, query the ERP, and act on the user's behalf without asking.

BragJack demonstrated that one malicious extension is enough to commandeer that agent across five different AI browser products. The install is the whole attack: after that, no clicks, no phishing follow-up, nothing. For an IT team, that changes the model from "a user made a mistake" to "software on a machine I own is acting autonomously with user credentials."

Why existing tools miss it:

• Standalone network monitors were built for servers, switches, and SNMP. They watch the infrastructure you explicitly added. A browser agent running on a managed workstation generates zero alerts because it looks like ordinary web traffic.
• RMM inventories don't parse the browser layer. Ask your RMM what is installed on the finance manager's laptop and it lists Chrome. It does not list the 14 extensions inside Chrome, which profile they are in, or that one profile has an AI agent with standing access to your ticketing system.
• Discovery is periodic, not continuous. Plenty of teams still run quarterly scans and keep the topology in a Visio diagram that was accurate in 2022. A new device, a contractor's laptop, a rogue access point — none of it exists to you until the next scan, up to 90 days later.
• The tools don't talk to each other. Firewall logs, RMM inventory, and the helpdesk live in three products with three databases. Correlating "new host appeared on VLAN 20" with "that user filed a ticket about a weird extension" is a human job done in spreadsheets.

What this costs in practice. A typical MSP runs discovery on a 30-day schedule across 40 client sites. That is up to 30 days in which an unmanaged endpoint — including one running AI browser agents — operates with no visibility, no inventory entry, and no ticket trail. Internal IT teams fare no better: when a rogue extension incident finally surfaces, it arrives as a vague helpdesk ticket ("Chrome is acting weird"), gets triaged by a tier-one tech with zero network context, and burns hours of senior time answering the first real question: what is on this machine and what is it talking to? Multiply that across every machine where nobody can answer that question confidently, and you get the real damage — long MTTR, alert fatigue from tools that cry wolf about irrelevant noise while staying silent about what matters, SLA reports stitched together from two systems that disagree, and an IT manager who cannot produce an accurate asset list for an audit, let alone an incident review.

How AlertMonitor Solves This

AlertMonitor approaches this from the layer where blind spots actually live: the network itself.

• Continuous, multi-protocol discovery. AlertMonitor constantly 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 quarterly. Continuously. The moment a new device appears on any segment, it is on the map.
• A live topology map, not a diagram. The map reflects the real network state right now. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full context: which switch, which port, which VLAN, what changed.
• New-device alerts that become actionable immediately. An unknown endpoint appearing on the finance VLAN is not just a ping — it is an alert with network context, routed to the right people, and optionally auto-converted into a helpdesk ticket so triage starts in seconds, not at the next audit.
• RMM remote execution closes the endpoint gap. Because monitoring, RMM, helpdesk, and patching share one platform, the same console that says "new host detected" lets you push a script to that host and audit browsers, extensions, and running agent processes — without opening a fourth tool.

Old workflow: quarterly scan → spreadsheet diff → discover unknown host three weeks late → open the RMM → realize the RMM agent was never installed on it → remote in manually → check extensions by hand → write it up.

AlertMonitor workflow: new host appears → instant alert with switch, port, and VLAN context → auto-ticket created → one-click remote session from the same console → deploy the extension audit script below → resolved before the coffee is cold.

Teams running this pattern report the same shift: asset discovery stops being a quarterly chore measured in days and becomes a background process measured in seconds. That is the difference between learning about a rogue endpoint from an end user and knowing about it before it does anything.

Practical Steps You Can Take Today

1. Baseline what is actually on your network right now. AlertMonitor does this continuously, but run the manual ARP-based version once and see how much you don't know:

# Sweep a /24 — every host that answers is a device you should be able to name
$Subnet = "192.168.1."
$Live = foreach ($i in 1..254) {
    $ip = "$Subnet$i"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) {
        $mac = (arp -a $ip | Select-String '([0-9a-f]{2}-){5}[0-9a-f]{2}').Matches.Value
        [PSCustomObject]@{ IP = $ip; MAC = $mac; Seen = Get-Date }
    }
}
$Live | Export-Csv -Path "C:\Reports\live-hosts-baseline.csv" -NoTypeInformation
Write-Host "$($Live.Count) live hosts found. Can you name every one of them?"

If that count is higher than your asset list, congratulations — you just found your blind spot.

2. Inventory browser extensions across your endpoints. This is the layer BragJack attacks and the layer your software inventory has never reported on. Deploy this as a scheduled script from AlertMonitor's RMM so it runs daily across every Windows endpoint with results collected centrally:

# Collect installed extensions for Chrome and Edge across all user profiles
$Report = @()
$Browsers = [ordered]@{
    "Chrome" = "$env:LOCALAPPDATA\Google\Chrome\User Data"
    "Edge"   = "$env:LOCALAPPDATA\Microsoft\Edge\User Data"
}
foreach ($browser in $Browsers.Keys) {
    Get-ChildItem -Path $Browsers[$browser] -Directory -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -match '^(Default|Profile)' } |
        ForEach-Object {
            $profile = $_
            Get-ChildItem -Path (Join-Path $_.FullName "Extensions\*\*\manifest.") -ErrorAction SilentlyContinue |
                ForEach-Object {
                    $m = Get-Content $_.FullName -Raw | ConvertFrom-Json
                    $Report += [PSCustomObject]@{
                        Computer = $env:COMPUTERNAME
                        User     = $env:USERNAME
                        Browser  = $browser
                        Profile  = $profile.Name
                        Name     = $m.name
                        Version  = $m.version
                        ExtID    = $_.Directory.Parent.Name
                    }
                }
        }
}
$Report | Sort-Object Browser, Profile | Format-Table Name, Version, ExtID -AutoSize
$Report | Export-Csv -Path "C:\Reports\extension-inventory.csv" -NoTypeInformation

3. Know what your browser processes talk to. When an agent acts on its own, its connections are the footprint — and this is the first command you run when triaging a machine:

# List remote endpoints your browser processes are connected to
$BrowserPIDs = (Get-Process -Name chrome, msedge, opera -ErrorAction SilentlyContinue).Id
Get-NetTCPConnection -ErrorAction SilentlyContinue |
    Where-Object { $BrowserPIDs -contains $_.OwningProcess -and $_.RemoteAddress -notmatch '^(127\.|::1)' } |
    Select-Object LocalAddress, RemoteAddress, RemotePort, State, OwningProcess |
    Sort-Object RemoteAddress -Unique | Format-Table -AutoSize

4. Wire it together in AlertMonitor:

• Enable continuous discovery with new-device alerts on every VLAN, and set unknown-host alerts to auto-create a helpdesk ticket pre-filled with switch, port, and VLAN context.
• Schedule the extension audit as a daily RMM job across all endpoints and review the consolidated report weekly.
• Tag machines running AI browser agents as a device group, so any anomaly on those hosts escalates at higher priority and reaches the right technician first.

None of this requires new headcount or a fifth tool. It requires the tools you already pay for to share one map, one alert stream, and one console — which is exactly what AlertMonitor was built for. BragJack was a proof of concept that paid out $20,000 in bounties. The real-world version will not announce itself. The only defense that scales is knowing, at all times, what is on your network and what it is doing. That is not a security pitch. That is operational visibility — and it should have been true yesterday.

Related Resources

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