How we try to stop an AI operator in an RMM from running format C: (5 layers, and where they stop)

Disclosure: I work on ReconDeck, a self-hosted RMM with a built-in AI operator. This post describes how its safety design works, based on what we publish on recondeck.com. It is vendor material, so read it with that in mind.

Letting an LLM run PowerShell as SYSTEM on client machines is the thing most MSP owners fear about AI in RMM. It is a reasonable fear. A model that is wrong 1 time in 200 is still a problem when it can run Remove-Item -Recurse on a customer's file server.

This post walks through how we approach it: five layers, each assuming the previous one failed. I'll also say what we don't claim, because "AI safety" posts that skip that part aren't worth much.

The operator is an AI agent that works inside the RMM console. It diagnoses incidents on Windows and Linux machines and proposes fixes. We assume:

So no single layer is trusted. The design goal is that a destructive command needs to get past several independent mechanisms, and that a human is on the hook for the ones that matter.

The first layer is not an AI at all. Destructive commands are blocked server-side, before they are dispatched to the agent. Our published examples are format, del and Remove-Item -Recurse. Running one of those requires explicit operator confirmation.

A sketch of the idea (illustrative pseudocode, not our source):

HARD_BLOCK = [ r " \bformat\b ", r " \bdel\b ", r " Remove-Item\s+.*-Recurse " ] def dispatch ( cmd, session ): if any ( re. search ( p, cmd, re. I ) for p in HARD_BLOCK ): if not session. operator_confirmed ( cmd ): return Blocked ( " destructive: needs explicit operator confirmation " )... Enter fullscreen mode Exit fullscreen mode The obvious weakness is the one every blocklist has: it only catches what it recognizes. That is why it is layer 1 and not the whole answer.

Before a dangerous command runs, a second, "senior" model assesses the risk. It can block the command or propose an alternative.

The demo on our site shows this. The operator proposes format C: on a machine named 017-001. The reviewer stops it, explains that it would wipe the OS with no recovery, and suggests alternatives: sdelete with confirmation, or an MDM reset with rollback.

Why have a model review a model? A blocklist can't judge intent. A reviewer can see that a command that looks harmless is aimed at the wrong target, or that a cleanup script would touch more than the ticket needs. The reviewer is also a different call with a different job, so it doesn't share the first model's momentum toward "just do what was asked."

The cost is that this layer is probabilistic. It reduces risk and doesn't remove it, which is why it comes after the deterministic layer and not instead of it.

The operator doesn't hold standing power. It works in named permission modes, each with its own permissions and an auto-expiry timer. The modes we list are:

The idea is least privilege over time. Diagnosing a slow PC needs read-only. Fixing one machine needs single-agent. Touching a whole fleet needs bulk operations, which is a separate permission from the rest. The riskiest mode is not a permanent setting: it expires on a timer, so the system falls back to a safe state if someone forgets to switch it off.

This also limits the damage of a mistake. A bad command in read-only mode can't change anything. A bad command in single-agent mode can only hit one machine.

Every AI and operator action is recorded: who acted, what was done, when, on which agent, and the result. The log is visible in the console.

An audit log doesn't prevent anything. It does three other jobs:

The server runs in the customer's data center. This layer is about control and data flow more than command safety, but it matters for the same reason: the system that enforces layers 1 to 4 sits on infrastructure you operate, not on a vendor's multi-tenant cloud.

Take the demo case, an AI that decides to reformat a drive:

The human stays in the loop where it counts. The AI diagnoses and proposes, and the technician approves. This matches where the market is: other vendors also keep a human approval step (NinjaOne has said fully autonomous AI won't arrive in 2026). We don't think "fully autonomous" is the right pitch today, and we don't sell it.

This is the section I'd want to read as an MSP owner.

If you run an MSP or manage a fleet: what would you need to see before letting an AI touch production endpoints? A public red-team report? A dry-run mode? Per-command approval for every write? I'd like to hear what's missing from this design.

More on the design: recondeck.com/en/. Contact: info@recondeck.com.

ReconDeck is developed by KLIK.BEL, Minsk. I'm affiliated with the vendor.