Autonomy is easy to demo. Containment isn't. Twenty questions to ask your endpoint management, network management and monitoring vendors before you turn it on.
Over the past year, a growing number of vendors in endpoint management, network management, remote monitoring and management (RMM), and IT monitoring and observability have announced AI agents for their platforms. Some investigate problems and recommend fixes. Some open the platform to outside AI tools through Model Context Protocol (MCP) servers. Some require a technician to approve every change before it reaches a device. And some offer settings where the agent decides what to change and makes the change without asking anyone.
I've spent 30+ years in the endpoint management space, and what bothers me about many of these announcements isn't the technology. It's what's missing from them. When a launch spends ten paragraphs on what the agent can do and a sentence on how it's contained, customer safety has been put in second place, whatever the intent. A vendor asking for authority over production systems should explain how it protects customers as part of the launch. Customers shouldn't have to pull that explanation out of the vendor with pointed questions after the feature ships.
So this post is about those questions. I'm not going to name the vendors I'm concerned about, because the problem isn't any one company. It's that autonomy is fast becoming a feature vendors feel they have to offer, and buyers need a way to tell AI that has been contained from AI that has simply been switched on. Everything here applies to any platform with privileged reach across your environment: endpoint management, network management, RMM and monitoring. For short, I'll call them management and monitoring platforms.
What this is not about
AI has a real place in managing and monitoring infrastructure. It can investigate a failure across thousands of devices faster than any person. It can correlate, summarize, explain and plan. Connecting AI to one of these platforms through a standard interface like MCP isn't the problem; the MCP specification itself recommends that a person always be able to deny a tool call. "What if" planning isn't the problem. Neither is automation that requires a person to approve each change before it runs.
There are two lines I care about, and they're independent of each other.
Execution. AI can investigate and propose. A person approves the specific action before it executes.
Data. Even read-only analysis can be unacceptable if it sends sensitive information about your environment to an outside inference provider without your control.
Mandatory approval doesn't solve data exposure. Keeping inference inside your own environment doesn't make autonomous changes safe. A vendor has to answer for both.
Why management and monitoring platforms raise the stakes
An endpoint management platform is already one of the most privileged systems in any enterprise. It runs code as SYSTEM or root on every device it manages. It installs and removes software, changes configuration and reboots servers. A network management platform holds administrative credentials for your switches, routers and firewalls, and can push configuration to all of them at once. Monitoring platforms are close behind. They hold credentials for the servers, network devices and applications they poll, run agents across your systems, and can often run scripts or restart services when an alert fires.
Attackers know this, and they have already shown they will go after management and monitoring software to reach everything it touches. When one of these platforms is compromised, the attacker inherits its reach: its credentials, its agents and its ability to push changes everywhere, fast.
Add an AI that decides what to do, and a mistaken decision is no longer a bad recommendation on a screen. It's a privileged action across thousands of devices. An action can be authorized, correctly executed and fully audited, and still be a disaster. The audit log tells you what happened. It doesn't stop anything from happening.
There's a second problem, specific to this category, that I don't see discussed nearly enough: much of the data the AI reads comes from the very devices it manages, and from the people using them. Device names. Installed software names. Event log messages. File paths. Service descriptions. User names. Help desk tickets typed by end users. For decades that data was only displayed in a console. Now an AI reads it and decides what to do about it.
That matters because large language models can't reliably tell data from instructions. This is prompt injection, and it sits at the top of the OWASP Top 10 for LLM Applications. The UK's National Cyber Security Centre (NCSC) has gone further, warning that prompt injection may never be fully mitigated the way SQL injection was, and describing the model as an "inherently confusable deputy." Put that deputy inside a management or monitoring platform and it may be holding administrative rights to everything the platform touches.
Consider a help desk agent that reads a ticket, investigates the device and applies a fix. A user, or an attacker who has phished one, submits a ticket containing text written for the AI rather than for the technician. Or malware on one machine gives itself a service description written the same way. The AI reads it with the same attention it gives everything else. If it's allowed to act on what it reads, the attacker no longer needs admin rights. They only need the AI to have them.
Monitoring and network data make this worse, because so much of it records what outsiders send or what devices say about themselves. An attacker doesn't need a foothold on anything to get text into a log. A failed login with a crafted user name, or a web request with a crafted header, lands in a log that an AI may later read while it investigates an alert. Network data works the same way: any device plugged into your network can announce its own name and description to the switch it's connected to, and network tools collect those announcements to map your topology.
The NCSC's guidance is that when a model processes input from someone, its privileges should drop to that person's level. Apply that here and the conclusion is uncomfortable: an AI that reads telemetry and logs from your whole environment should not also hold the authority to change that environment on its own. The right design assumption isn't "the AI will behave." It's "the AI will eventually be manipulated, or simply wrong, so what can it do when that happens?"
Why the market keeps getting this wrong
Autonomy demos well. Watching an agent find a problem and fix it by itself is compelling in a fifteen-minute demo. Containment doesn't demo at all. An agent that stops, shows exactly what it intends to change, waits for a person to approve it and refuses to touch more than fifty devices at once looks slow on stage. In practice it often is slower. That's the point.
That's the competitive trap. Once one vendor ships an autonomous mode, others feel pressure to follow, and the fastest thing to ship is the capability, not the safeguards. Buyers who reward the capability without demanding evidence of containment are teaching the market to keep doing it. Offering that kind of authority without safeguards a customer can verify is, in my view, negligent.
The burden belongs with the vendor. Documenting an autonomy setting is not the same as demonstrating that its limits hold when something goes wrong. If a vendor wants this level of trust, it should show you who decides what's risky, what independently enforces the limits, how far a failure can spread and where your data goes, before you turn the feature on.
Not everyone is getting this wrong. When CrowdStrike introduced its AI Kill Switch, CEO George Kurtz described it as a control that sits outside the model and acts while the agent runs, "where an agent can't argue with it, rewrite it, or wait it out." That is the right test for every safeguard in this post. His broader argument is right too: being able to stop an agent is what lets a company use more of them, not fewer. Containment isn't the enemy of AI adoption. It's what makes adoption possible.
On a platform with this kind of reach, a stop button can't be the only control, because a change pushed to ten thousand devices can finish before anyone reaches for it. On a network, a bad change can also cut off the path the stop command would have to travel. The approval has to come before execution, and the limits have to live where the model can't touch them.
Twenty questions to ask before you turn it on
These apply to every vendor, including us. Ask them in writing, and get the answers in writing.
Who can make a change
1. Can the AI make any change to a production device without a named person approving that specific change?
Not "the plan." Not "this category of fix." That change, on those devices. If the answer is "it depends on the autonomy level you choose," ask what the default is, who can change it, and whether changing it is logged and alerted. A setting that turns approval off is a setting an attacker, or a hurried admin, can turn off too.
2. Who decides what counts as "low risk"?
Some products skip approval for actions they classify as low risk. If the AI is doing the classifying, there's no approval gate, just the AI's opinion of its own plan. Risk classification should be fixed by the platform, visible to you and outside the model's influence.
3. What exactly does the approver see, and does the platform execute exactly that?
Approving a natural-language summary isn't approving an action. The approver should see the exact script or command, its parameters and the full list of target devices. The platform should then run only what was approved, and if anything changes, approval should start over. An approval step that fires so often people stop reading it isn't a control either.
4. Can approvals be pre-granted?
Standing approvals, "always allow" rules and auto-approval policies turn an approval step into autonomy with extra steps. Ask whether they exist, who can create them and whether any are on by default.
5. Can the person who asked for the change approve it? Can the AI?
Separation of duties is a basic control for high-impact changes made by people. It should apply at least as strongly when the request comes from an AI. Ask whether the credentials the AI holds can reach the approval function at all.
What actually enforces the limits
6. Where are the limits enforced?
If the rules live in the model's instructions ("never reboot a domain controller," "never touch the core routers"), they're suggestions, and a manipulated or confused model can ignore them. Limits have to be enforced by the platform's own authorization layer, outside the model, so they hold even when the model doesn't. OWASP's guidance on excessive agency says the same: authorization belongs in the systems the AI calls, not in the AI's judgment. Ask the same question about any outside AI agent you connect through an MCP server or API. Do the same limits and approvals apply to it, or can a write through the API go around them?
7. What identity does the AI act as?
Its own identity, with only the permissions it needs? A signed-in administrator's full session? A shared, long-lived API key? Can you tell from the audit log whether a person or the AI took an action, and can you revoke the AI's access without affecting anyone else? When something goes wrong, can you reconstruct what the AI read, what it proposed, who approved it and what actually ran?
8. If the AI writes a script or a configuration change, who reviews it before it can run?
Generated code is the most direct path from a manipulated model to your devices, and a generated configuration change is its network equivalent. Ask whether AI-written scripts and configurations go through the same review, approval and publishing controls as ones written by people, and whether the agents on your endpoints refuse content that hasn't been through them. If the platform signs whatever the AI produces, the signature means nothing.
How far a mistake can spread
9. What's the largest number of devices a single AI-initiated action can touch?
Can it target "all devices"? Are changes staged in rings, with automatic stops when failures cross a threshold? A mistake on five machines is an incident. The same mistake on fifty thousand is an outage. On a network, position matters as much as count. A bad change to two core switches can do more damage than the same change to five hundred laptops.
10. How do I stop it, and does stopping work when the AI or the vendor's cloud is down or compromised?
Is there a stop control that cancels work already in flight? Is it enforced on the systems doing the work, or does it depend on the same service that's misbehaving? A stop control has to pass the same test as every other limit: outside the model, enforced where the work happens.
11. Which actions can't be undone, and are they excluded?
Wiping or retiring a device, removing security tools, resetting credentials, deleting data. Irreversible actions should never be AI-initiated without a person approving each one, and there's a good argument they shouldn't be AI-initiated at all.
On a monitoring platform, treat anything that silences alerts or turns monitoring off the same way. The change can be reversed. Whatever happened while you were blind can't.
On a network, put changes to firewall rules, routing and access lists in the same category. A bad one can cut off the path you'd need to undo it, or quietly open a door that stays open.
What the AI reads, and who wrote it
12. What does the AI read when it decides what to do, and which of it can an attacker influence?
Ask the vendor to walk through it field by field: device names, software inventory, logs, alerts, tickets, file names, network neighbor data. Then ask what keeps text in those fields from being treated as instructions. Be wary of anyone who says they've solved prompt injection. The NCSC specifically advises skepticism toward products that claim to stop it, and favoring those that understand how to reduce it. The honest answer is architectural: the AI can't do damage it isn't permitted to do.
13. Has the AI functionality been independently tested?
By whom, against what scope, and how recently? The testing should cover prompt injection and tool misuse specifically. A SOC 2 report or a general penetration test tells you something about a vendor's controls. It doesn't tell you whether its AI can be talked into something.
Where your data goes
14. Which AI providers process my data, in which regions, and under what terms?
Is the list published? Will you be notified before it changes? Unless a vendor hosts the model itself, an AI feature means your data is processed by another company's model service, under terms you didn't negotiate. That isn't automatically wrong, but you should know exactly who that company is.
15. What exactly is sent?
Inventory, vulnerability findings, user names, IP addresses, logs, network topology, device configurations, script contents? Is anything redacted before it leaves? Keep in mind that inventory combined with vulnerability data is a map of which machines are exposed to what, and network and monitoring data add the routes between them. That is a valuable thing to have sitting somewhere you don't control. Network device configurations often hold credentials and keys as well.
16. What's retained, for how long, and who can see it?
Include the vendor's own logs, debugging traces and any monitoring services it uses, plus whatever the model provider keeps. "We don't train on your data" answers one question out of several. It says nothing about retention, access or location.
17. Is AI off until I turn it on, and can I keep it inside my environment?
Does an upgrade ever switch AI features on by itself? Can you point the feature at a model endpoint you control? If you turn AI off, is that enforced on the server, and does the data flow actually stop?
Who answers for it
18. How will I know when you change the model or its instructions?
The AI you evaluate during procurement may not be the AI running six months later. Swapping models or rewriting prompts can change behavior as much as a code release. Ask whether those changes are versioned, tested and announced.
19. Who on your team owns the security of the AI features, and can I talk to them?
A vendor that has done this work will put an engineer on the call who can answer every question above in detail. A vendor that hasn't will send you a datasheet.
20. What does the contract say when the AI gets it wrong?
Read the AI terms. If a vendor markets its AI as able to act on its own while disclaiming responsibility for what it does, that tells you how much the vendor trusts it.
Answers that sound like answers
You'll hear some of these. Each sounds reassuring and answers none of the questions above.
- "You choose the level of autonomy." What's the default, and who can change it?
- "It uses your existing RBAC." Role-based access control limits what an identity may do. It doesn't decide whether a particular action is wise, and it doesn't stop a manipulated agent from using every permission it has.
- "Every action is fully audited." An audit log records the damage. It doesn't prevent it. OWASP is explicit that logging and rate limits can reduce the damage from excessive agency but won't prevent it.
- "Your data is encrypted in transit and at rest." Encryption protects data from parties who aren't supposed to receive it. The AI provider is supposed to receive it.
- "We never train on your data." Retention, access and location are separate questions.
- "Our guardrails prevent misuse." Where are they enforced? Inside the model, or outside it?
- "Governed," "trusted," "responsible," "enterprise-grade." Descriptions, not evidence.
The standard is simple
If a vendor can't answer these questions clearly, in writing, before you turn the feature on, the feature isn't ready for your environment. That isn't a judgment about AI. It's the standard you'd apply to any new path to privileged access across every system you own.
Where Patchblox stands
We expect to be asked every one of these questions, and we should be. Here are our short answers.
Patchblox's AI interface is read-only. It's an MCP server that can query your data, and it cannot change a device. There is no setting that turns write access on.
It's built for AI that you run and control. AI clients authenticate as their own service identity with short-lived tokens, read through a dedicated, restricted database role, and every query they run is recorded in the audit trail. Patchblox doesn't send your environment's data to any AI provider.
If we ever let AI propose changes, every one will require approval from your administrators through multi-admin approval, and the AI will have no way to approve its own work.
That makes for a less exciting demo. We're fine with that.