A user can't log in. Something's off with their account. You ask your AI agent to fix it.
It does. It deletes the user and creates a fresh one. Problem solved.
Except now their history, their data, and their whole setup are gone. The agent didn't go rogue. It did exactly what you asked, in the most direct way it could find.
Here's the thing about AI agents. They're relentless about finishing the job. Give one a goal and API access, and it'll find a path to done. It won't always be the path you had in mind.
Our CEO, Jeff Farris, put it plainly in our recent webinar on MSP automation: an agent is going to solve the problem, and that's a problem.
Ambiguity makes it worse. Say you're cleaning up a tool you've stopped using, and you tell an agent to delete all the users. You know which tool you mean. The agent might not. If it reaches your PSA first, that's a very long afternoon.
Stories like this keep surfacing. Almost none of them are about bad AI. They're about AI with too much room and too few checkpoints.
The answer isn't keeping agents away from your stack. It's deciding ahead of time how much room each action gets.
A simple way to think about it:
Most guardrail decisions land in one of those three. Here's how each works in practice.
Looking up a user. Pulling ticket details. Checking an alert. If an action only reads data, there's not much to undo, and stopping for approval just slows everyone down.
That matters more than it sounds. If an automation asks permission every time it looks something up, your team will start clicking Approve without reading. At that point, the approval step isn't doing anything.
Anything that writes is different. Creating a company, changing a user, closing a ticket, resetting a password. Those are the steps where a wrong guess costs you.
In CloudRadial AutomationAI, read actions run on their own. Actions that create, edit, or change something stop and wait for approval by default. Your team gets a notification and decides.
The same goes for agents. Picture one working through your RMM alerts. By default, it figures out the fix and then waits for a person to approve it before acting.
You don't have to approve the same thing forever, though. You can approve a step once, approve it for all future runs of that workflow, or switch an agent to auto-approve once its results have earned your trust.
Think of it like a new tech. They check with you for the first few weeks. Once they've proven themselves on a task, you stop making them ask.
The point is that you set the tolerance. Not the agent.
Here's an underrated guardrail: don't use an agent for the parts that don't need judgment.
If you know exactly how a user gets added to a group, write it as a script. A script does the same thing every time. No interpretation, no creative shortcuts.
AutomationAI workflows can mix PowerShell, C#, and Python steps with AI agent steps. So the predictable parts follow the same path every time, and the agent only handles the calls that actually need thinking.
You can also hand an agent written rules instead of letting it improvise. One example from the webinar: an automation that checks every ten minutes whether the techs assigned to tickets are out of office. When someone is, it reassigns the ticket using rules written into a knowledge file, not the agent's best guess.
Approvals catch mistakes in the moment. Limiting access stops them earlier.
Every API you connect is a list of things an agent could do. Some you want. Some you'd rather it never touch, like deleting users out of your PSA.
In AutomationAI, extensions are how automations talk to each tool, and you can trim an extension down to only the tool calls you want available. Need an agent to look things up in a system but never change it? Build a read-only extension. If the delete call isn't there, the agent can't use it.
Before anything runs for real, see what it would do.
AutomationAI's plan mode walks through an automation and shows you the steps it would take. When the plan looks right, you switch it to run live. Same habit as a change window: dry run first, then the real thing.
Guardrails aren't only about stopping the wrong action. They're also about knowing what happened afterward.
When 20 techs run automations from 20 laptops, nobody can say who changed what, for which client, on which day. A central log fixes that.
AutomationAI records every run and every step, so you can see exactly what an automation did, and where it failed if it did. You can also log the results back to the ticket in your PSA, so the record lives where your team already works.
You don't need a guardrail plan for every automation on day one. Pick one your team already runs often, like adding a user or working a noisy alert, and walk through it step by step.
Mark every step that changes something. Those get approvals. Anything that only looks things up can run on its own. And if a step does the exact same thing every time, ask whether it should be a script instead of an agent.
Run it in plan mode a few times and actually read what it would do. Once it's live, watch what lands in your approval queue. If your team keeps approving the same harmless step, the checkpoint is in the wrong place, and it's teaching people to click without reading. Move it.
After a few weeks of clean results, you'll know which agent actions have earned auto-approve. Turn it on for those. Keep approvals on the steps where a wrong call would sting.
Then keep reading the log. A guardrail gives your team a checkpoint. It still takes a person to look at what's in front of them.
We dug into guardrails, along with multi-tenancy, logging, and extensibility, in our latest webinar on MSP automation. Jeff Farris, Ricky Cecchini, and Nick Westgate walk through it live, including approvals in action. Watch the on-demand recording.
Guardrails are the rules that control what an AI agent can do on its own and when it has to stop and ask. For MSPs, they usually cover which actions need human approval, which tools and API calls an agent can reach, and how every action gets logged. In AutomationAI, read actions run on their own and changes wait for approval by default.
Anything that creates, changes, or deletes data: adding users, changing permissions, closing tickets, resetting passwords. Actions that only read data usually don't need approval, and requiring it there tends to train people to click through without reading.
Both. Use scripts for steps you already know how to do the same way every time, and save agents for the parts that need judgment. AutomationAI workflows can combine PowerShell, C#, and Python steps with AI agent steps in the same automation.
Yes, if the platform lets you control which API calls it can use. In AutomationAI, you can trim an extension to only the tool calls you want, including building a read-only extension, so the agent can't take actions that aren't available to it.
Run it in a plan or dry-run mode first so you can see the steps it would take, then switch it to live once the plan looks right. AutomationAI offers plan and live modes for both AI requests and workflows.
Use one central log instead of scripts scattered across tech laptops. AutomationAI records every run and every step, and can log the results back to the related ticket in your PSA.