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 threat model

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:

• The model will sometimes be confidently wrong.
• Prompt text (ticket bodies, log lines, file names) can contain instructions nobody intended.
• A single check, whether a prompt rule or a regex, will eventually be bypassed or misconfigured.

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.

Layer 1: a hard block, on the server

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.

Two design points matter here:

• It is deterministic. A model can be talked into things. A pattern check on the server can't be argued with, whatever the prompt says.
• It runs on the server, not in the agent or the prompt. If the safeguard lived in the system prompt, a prompt injection could try to override it. If it lived on the endpoint, a compromised endpoint could skip it. Server-side means the check sits on the path every command has to take.

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")
    ...

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.

Layer 2: an AI reviewer for risky commands

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.

Layer 3: permission modes with auto-expiry

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:

• Read-only
• Single agent
• Bulk operations
• Destructive

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.

Layer 4: an audit log of everything

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:

• You can reconstruct what happened after an incident.
• You can tell "the AI did it" from "a technician did it" and see who approved what.
• You get evidence for reviewing and tuning the other layers: which commands the reviewer blocked, which were confirmed anyway.

Layer 5: your own infrastructure

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.

Two related facts:

• The AI runs on your own AI subscription, via what we call the AI Bridge. There are no extra per-request charges from us. This is a pricing contrast with RMMs that sell metered AI credits. It also means your prompts and context go to whichever model provider you connect, which is a data-flow decision you make.
• The agent is a Rust binary, about 30 MB of RAM, for Windows 7 and later (x86/x64) and Linux (Ubuntu and other distributions). It has auto-update with beta/prod channels, staged rollout and built-in kill switches. Clients can also end a remote session themselves from the tray with an "End session" button.

How the layers fit together

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

• The command matches the hard block. It can't run without explicit operator confirmation.
• If it gets as far as review, the senior model assesses it and can block or redirect.
• Whatever mode is active limits what the session may do at all, and the riskiest modes expire.
• Whatever happens ends up in the audit log.
• All of it runs on a server you host.

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.

What we don't claim

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

No guarantee of safety. Layers reduce risk. They are not a proof. A command nobody anticipated, in a form the hard block doesn't match, could reach the reviewer, and the reviewer is a model.

A blocklist is a blocklist. Obfuscated commands, indirect execution (scripts that call destructive operations internally) and tools we haven't listed are the classic ways around pattern matching. The reviewer and permission modes exist because of this, and they don't close the gap fully.

The human can be the weak point. "Explicit operator confirmation" only works if the operator reads what they confirm. Confirmation fatigue is real.

Details we haven't published. The site doesn't state timer durations, the reviewer model's identity, the full definition of "destructive", how modes get assigned, audit-log retention, or whether a reviewer's block can be overridden. I won't guess at them here. If those matter to you, ask us before you rely on them.

The numbers are vendor claims. Anything quantitative on our site, including the incident-resolution and productivity figures, is stated by us and is not independently verified. This post doesn't rely on them.

No third-party audit or red-team report yet. We think one is the right next step for a design like this. It doesn't exist as a public document today.

BYO model shifts responsibility. Using your own AI subscription means data goes to your chosen provider. That's your call, and your compliance question.

Takeaways if you're building something similar

• Put the first safeguard outside the model. A deterministic server-side check can't be prompt-injected.
• Don't give standing privileges. Modes with expiry timers turn "the AI is allowed to do X" into a temporary state.
• Use a second model as a reviewer, not as the only guard. It catches what patterns can't, and it is itself fallible.
• Log everything with actor, target, time and result. You'll need it the first time something goes wrong.
• Keep a human approval step for destructive work, and design the UI so confirming isn't a reflex.
• Say publicly where it can fail. It's the only way a skeptical buyer can judge the design.

Questions for you

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: i***@recondeck.com. ReconDeck is developed by KLIK.BEL, Minsk. I'm affiliated with the vendor.