It is 17:30 on a Friday and an MSP owner is looking at a settings page. There is one toggle on it. It says “autonomous”. The vendor’s account manager has asked twice this quarter why it is still off, and the honest answer is a domain controller at a law firm and what happens the first time the automation is wrong on it at 3 am. So the toggle stays off, the team keeps paying for automation nobody uses, and the on-call phone keeps ringing for disks that fill up the same way every month.
Because a single toggle asks for total trust before the tool has earned any. Ask an MSP owner why the automation they pay for is switched off and the answer is rarely about capability. It is about the first time it is wrong. A toggle marked “autonomous” is a promise nobody wants to be the one who trusted, and there is no middle setting that says “show me first”. Guardian Plus takes a different position: the assistant asks before it acts, and how much it asks is a setting you choose per conversation, not a personality trait of the product.
Approve every step. It stops and asks before anything that carries risk. This is the default, and it is where most people stay. You see the objective, each task, its risk level and the exact command before it runs.
Approve the plan once. Read the whole plan, approve it once, then let it work through the list. You still see every command; you just do not click for each one.
Unattended. For work you scheduled and already trust: the nightly cleanup, the certificate renewal, the thing that has run two hundred times. The floor still applies.
It is the line unattended mode cannot cross. Destructive commands stop for a human even when you have told the assistant to run without you. You can wave one through for a single job by saying so, explicitly, but never by accident and never by default. That single rule is what turns automation from something you own into something you switch on, because the worst case is no longer “it did the wrong thing at 3 am”. The worst case is “it stopped and asked, and nobody was awake to answer”. Those are very different mornings.
Here is the one from our favourite example, a web server that has run out of disk. Two steps are read-only and carry no risk. One changes things. The last verifies.
Notice what you are approving. Not “fix the disk”. A specific command, with its risk beside it, in a list you can read top to bottom in fifteen seconds. On approve-every-step you click once, at the vacuum. On approve-the-plan-once you click once, at the top. On unattended you do not click at all, and the vacuum still runs because it is low risk rather than destructive. Change that line to a command that deletes data and it stops in all three modes. The whole incident, minute by minute.
Yes. A plan is not a script you either accept or reject. Skip a task, reorder the list, redirect the objective or stop it, without starting over. When a task fails, corrective steps are proposed under it for your approval rather than the run silently dying. The intent is that you stay in the loop at whatever distance you have chosen, not that you are handed a finished result and asked to trust it.
It cannot see what you cannot. Every tool it calls re-derives the permissions of whoever asked. It runs under your permissions, not a service account, so it cannot surface a record you would not be allowed to open yourself.
It cannot write on its own. Actions that change things are hidden from the assistant entirely and need a person to confirm. Your most sensitive documents are never fed to a model at all.
It does not phone a vendor. Recognised requests are answered by capability matching with no model call at all; the rest plan with open-weight models on infrastructure we operate or you do. Which AI vendor is your current RMM using?
Every page a person answers by hand for a problem that fixes itself the same way each time. A disk that fills, a journal that grows, a certificate that needs renewing: each is a 3 am call and a plan a technician runs from memory. You are paying for the automation and for the on-call hours it was meant to replace. Graduated approval is how you stop paying twice, one plan at a time, starting on approve-every-step and moving a job to unattended only after you have read its plan enough times to be bored by it.
The credentials these sessions use are injected server-side from Guardian Vault, and that requires shared credentials to be decryptable server-side. Our encryption is not zero-knowledge. An operator with the master key and database access can decrypt shared items; private items are protected by policy and audit rather than by cryptography. We think that is the honest design for a platform that has to inject a password into a session without showing it to anyone, and we say so on the security page rather than in the small print. Why we built it that way.
Install the agent on a single server, ask it something, and read the plan before you approve it. Fourteen days, every module, no card.