Your RMM Can Run a Script on 500 Endpoints in 90 Seconds. Who Approves What It Runs?

The incident described in OWASP's GenAI exploit roundup is hard to shake: an AI agent connected to a real inbox began deleting messages, and reportedly kept going despite attempts to stop it. No attacker. No malware. Just live access, destructive capability, and nobody standing between the agent and the Delete key.

If you operate an RMM platform, read that again — because you manage something with far more reach than an inbox. Your RMM can execute PowerShell on every Windows endpoint in the fleet, silently push software, reboot servers, and rewrite local admin groups. And now every vendor in the space, riding the same wave that brought us "AI-powered remediation" and "self-healing endpoints," is wiring agents directly into that capability.

The CIO article behind this post frames the shift precisely: a year ago we worried about what AI says. Now we have to worry about what it does. A bad recommendation leaves you time to catch it. An agent with credentials turns the same bad decision into an API call, a privilege change, or a deleted resource before anyone notices.

For IT teams and MSPs, the RMM is exactly where that distinction lives or dies.

From Recommendation to API Call: The New Blast Radius

Your monitoring tool telling you a disk is filling up is a recommendation. You still have to log in, decide, and act. There is a human between the bad data and the bad outcome.

Your RMM running a "disk cleanup" script across a device group is an action. The decision and the execution are the same click. When that decision is wrong — a path variable that matches more than you expected, a filter that accidentally catches a production server, a maintenance window set to the wrong timezone — the bad outcome deploys at the speed of your network, not the speed of your approval process.

That is the uncomfortable math: the same automation that saves you a 2 AM disk-full page can cause a 2 AM everything-down page. The variable is not the technology. It is whether a human approval gate exists between "script selected" and "script executed at scale."

Where RMM Automation Actually Burns Teams

Talk to enough sysadmins and MSP techs and the same failure stories repeat:

Fire-and-forget script execution. Paste PowerShell, select a device group, hit Run. Output lands in a script log nobody opens unless something breaks. No staging, no dry-run enforcement, no second pair of eyes.

Auto-remediation without guardrails. "When alert fires, run script" rules written once and forgotten. Nobody ever formally defined which actions are safe enough to run unattended — restarting a service — versus which deserve a human in front of them — deleting files, changing ACLs, rebooting production.

Fragmented audit trails. The alert lives in the monitoring tool. The action lives in the RMM. The ticket may or may not exist in the helpdesk. When a user reports the line-of-business app died at 14:37, reconstructing "what script ran, on which machines, with what output" means exporting three logs and praying the timestamps line up. If you cannot answer that question in under a minute, every automation you have deployed is a liability you cannot account for.

The MSP multiplier. Run 12 client environments off one console and one bad script becomes 12 uncomfortable client calls. If you cannot produce an exact record of what executed and who approved it, you are apologizing blind — and possibly breaching the exact trust your contract is built on.

The root cause is architectural, not carelessness. Most RMM products grew out of remote-control tools; scripting, patching, monitoring, and ticketing were bolted on as separate modules or acquired separately. "Integration" between your monitor, your RMM, and your helpdesk usually means CSV exports and an API key glued together by whichever tech drew the short straw.

The business impact is measurable: mean time to resolve doubles when your tech is the human API shuttling data between three consoles. SLA reports get assembled by hand because monitoring data and ticket data cannot agree. End users learn to route around IT entirely. And your best technicians burn out — not from fixing problems, but from reconciling tools that refuse to talk to each other.

The Fix: Blast Radius Decides How Many Humans Approve

The article's core principle translates directly to endpoint management: the more destructive and the wider the reach of an action, the more approval it needs before execution.

That principle has to live in the platform, not in a wiki page nobody re-reads. Here is how AlertMonitor implements it:

One timeline for alerts, scripts, and tickets. AlertMonitor's RMM runs inside the same platform as infrastructure monitoring, helpdesk, patching, and network topology mapping. Every automated remediation and every manual technician action lands in the same device timeline as the alert that triggered it. There is no separate script log to excavate at 2 AM — you filter the device's timeline and see exactly what ran, what it returned, and what changed.

Script results feed back into monitoring data. When you run a script across a device group from the same console you monitor from, structured output returns into the monitoring layer. If the "fix" did not actually fix anything, the alert does not clear. You know in minutes instead of at the next user complaint.

Tiered execution: unattended vs. second-approval. Safe, reversible remediations — restarting a stuck service, clearing a print queue, re-registering a patch agent — run automatically with full logging. Destructive or fleet-wide actions — file deletion, reboots, permission changes, anything touching production server groups — route through a second approval. A named human confirms before the script touches a single endpoint. This is the article's "second approval," enforced by the platform instead of by memory and goodwill.

Staged rollout is the default, not a discipline. Push to a pilot batch, watch results appear in the same timeline, then promote to the full group. The runaway-loop scenario — a bad ForEach chewing through devices faster than anyone can react — dies here, because you see batch one's output before batch two starts.

Audited remote sessions without tab-switching. Technicians open remote sessions from the same console, and every session is logged — who, which device, when, what ran. No shadow remote tools, no "wait, which of my five open tabs was I in?"

The Workflow, Side by Side

The fragmented way — four tools, 40 minutes: Alert fires in the monitoring console → tech opens a separate RMM in another tab → finds the right device group → pastes the script → reads raw output in a third tab → copies findings into the helpdesk ticket in a fourth → hopes the alert clears. If the fix fails, start over.

AlertMonitor — one console, minutes: Alert fires → the device timeline already shows related metrics and recent actions → tech runs the script directly from the alert context → structured output lands beside the alert → the ticket updates itself → the alert clears only when monitoring confirms the condition actually resolved. If the action is destructive, it waits for the second approval first — visible to the whole team in the same timeline.

The measurable difference: what took 40 minutes of swivel-chair work takes a few. The audit question "what ran on SRV-DB-01 last Tuesday?" becomes a timeline filter, not an afternoon of log archaeology.

Practical Steps to Take This Week

1. Inventory every automation rule and saved script in your current stack. Classify each as auto-safe, needs-approval, or retired. Most teams find scripts nobody remembers approving.

2. Enforce dry-runs on anything destructive. PowerShell makes this almost free:

# Preview what a temp-file cleanup WOULD delete — run this before every deployment
Get-ChildItem "C:\Windows\Temp" -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } |
    Remove-Item -WhatIf

Read the output. Then read it again. On a server, "temp" is rarely just temp.

3. Know your blast radius before you push anything. Before scheduling any cleanup or mass change, pull the facts across the whole group:

$servers = Get-Content "C:\Scripts\servers.txt"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object @{n='Server';e={$_.PSComputerName}},
                  @{n='Drive';e={$_.DeviceID}},
                  @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
                  @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object { $_.FreePct -lt 15 } |
    Sort-Object FreePct |
    Format-Table -AutoSize

If you cannot run that against the group in one step from your monitoring console, your RMM and monitoring are still strangers.

4. Make scripts return structured output. Raw text dies in logs. JSON feeds the timeline. This is the pattern for anything you push via AlertMonitor's RMM:

$services = "Spooler", "wuauserv", "WinRM"
$result = foreach ($svc in $services) {
    $s = Get-Service -Name $svc -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Host      = $env:COMPUTERNAME
        Service   = $svc
        Status    = if ($s) { $s.Status.ToString() } else { "NotFound" }
        CheckedAt = (Get-Date).ToString("u")
    }
}
$result | ConvertTo-Json -Compress

Same idea across your Linux fleet:

#!/bin/bash
# Patch compliance snapshot for Ubuntu/Debian — JSON output feeds the AlertMonitor timeline
mapfile -t updates < <(apt list --upgradable 2>/dev/null | grep "/")
security=$(printf '%s\n' "${updates[@]}" | grep -c "security" || true)
printf '{"host":"%s","pending_updates":%d,"security_updates":%d,"checked_at":"%s"}\n' \
  "$(hostname)" "${#updates[@]}" "$security" "$(date -u +%FT%TZ)"

5. Stage every fleet-wide change. Pilot on 10–25 devices, verify output in the timeline, then promote to the full group — with the second-approval gate in front of anything that deletes, reboots, or changes permissions.

6. Test your audit trail. Pick a random device from last month and answer: what ran on it, when, and who approved it? If that takes more than a minute, the problem is not your process — it is your tooling.

The Bottom Line

The OWASP inbox agent did not need a sophisticated attacker. It needed live access, destructive capability, and no second approval. Every RMM console sitting in your stack today has more reach than that inbox — and the AI features arriving in it will only widen that reach.

The teams that win are not the ones that refuse automation. They are the ones that made the second approval a platform feature, made every action visible in one timeline, and made the distance from alert to safe resolution shorter than the distance from alert to panic.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources