The Rollback Question: What Happens When an Autonomous IT Engineer Gets It Wrong

Every CIO evaluating agentic IT eventually asks the fear question out loud: what happens when it does the wrong thing? It is the right instinct. Handing execution to an autonomous IT engineer means handing it the ability to make a change you did not personally approve, and no serious IT leader signs off on that without knowing where a mistake gets caught, how far it can spread, and how it gets undone. This post answers that directly. Autonomous IT engineer safety is not a promise that the system never errs. It is the failure-and-recovery path: the policy gate that stops most wrong actions before they run, the permission model that contains the ones that slip through, and the audit trail that makes reversing an action a bounded operation instead of a forensic exercise.

The honest version of the fear

The fear is usually phrased as "what if the AI goes rogue," but that framing hides the real risk. The real risk with any actor that has admin rights, human or autonomous, is a legitimate-looking action taken in the wrong context: a group membership changed for the wrong user, a license revoked from someone who needed it, a mailbox permission granted too broadly. Human engineers make these mistakes every day. The reason organizations tolerate that risk is not that humans are infallible. It is that there is a permission model bounding what they can touch and a log recording what they touched.

An autonomous IT engineer is held to exactly the same standard, and it should be. The mistake is assuming autonomy raises the bar beyond what is achievable. It does not. It makes the existing bar impossible to skip. Dex, the autonomous IT engineer for Microsoft 365, resolves work across L1 through L3, from password resets and access changes up to deeper Tier 2 and Tier 3 troubleshooting and configuration. The more capable the engineer, human or autonomous, the more the safety question shifts away from "how do we stop it from acting" toward "how do we govern what it is allowed to act on, and prove what it did." That is the question worth engineering around.

Where a wrong action gets caught: the policy gate

Dex works in three moves: it investigates the M365 environment, plans the sequence of actions, and executes them. The single most important safety property is where the check sits. The policy gate sits between plan and execute, so an action is evaluated before it ever touches the environment, not observed and remediated after.

Every planned action must match an explicit, structured policy before it runs. No matching policy means no action. This is a hard block at the code level, not a prompt instruction, which matters more than it sounds: prompt-level rules can be argued around by a malformed request or a prompt-injection attempt, but a check enforced in the execution layer cannot be talked past. The policy set itself is a six-layer model, running from global rules down through tenant, target rules, department, action, and runtime, so the same requested change can be allowed in one context and refused in another based on who, what, and where.

On the Dex Pro admin side there is a second catch: a human-in-the-loop review that shows every action before it executes, with an Approve Always option for the bulk operations an admin already trusts. So a wrong call has two places to be stopped before it reaches production: the policy gate refuses anything out of policy outright, and the review step gives a human the last word on the actions that are in policy but still deserve a glance. We walk this trust-versus-control tension in more depth in Can You Trust an AI to Run IT? Inside Agentic IT's Guardrails.

How the blast radius stays small

Some wrong actions will pass policy. A perfectly valid, in-policy change can still be the wrong change if the plan was built on a wrong read of the situation. This is exactly why containment is a separate design layer from the gate. The goal is that when a wrong-but-valid action does execute, it can only reach a small, predictable surface.

Three properties do the containing. First, delegated permissions: Dex acts through the requesting user's or admin's own scoped OAuth access, not a broad application-level API key. It can only reach what that identity could already reach, so a mistake is bounded by an existing permission set rather than by a shared super-key. Second, per-user scope on the employee side: Dex Go can only act on the account of the person who asked, never someone else's, which structurally rules out an entire class of cross-user damage. Third, per-org isolated databases and encryption keys, so one tenant's actions and data never bleed into another's, a property that matters enormously for MSPs running many client environments at once.

On top of those, two guardrails are hard-coded at the execution layer and cannot be reached by any request: Dex never grants admin roles, and Dex never bypasses MFA. Those are the two escalation paths that would turn a small mistake into a large one, and they are simply not available to the system. The blast radius of any single wrong action is therefore capped by design, not by hoping the plan was good.

How a wrong action gets reversed

Reversibility is where governed autonomy either earns its name or does not. The key idea is that the record needed to reverse an action is created at the moment the action runs, by the same execution layer that performs it, so there is no path where the change happens and the record does not.

Every executed action is written to two places: Dex's own Activity Log and the native Microsoft 365 logs, including Entra ID sign-in and audit logs, Exchange, and SharePoint activity. Each entry captures who requested the change, which policy authorized it, what was executed against the backend, and the result. Because the log is written by the execution layer rather than narrated by the model after the fact, it reflects what actually happened, not what the system claims happened.

That record is what makes reversal a bounded operation. Since Dex executes through delegated permissions against real M365 controls, undoing an action is the same operation a human admin would perform to undo it, done against a precise before-and-after record instead of a reconstruction from memory. You are not asking "what did it probably do." You are reading exactly which membership was changed, which license was moved, which permission was granted, and reversing that specific change. The rollback loop in the diagram is that path: from a change in the environment, back through the audit record, to a clean reversal. This is the same argument we make in The Audit Trail Is the Product: the log is not paperwork, it is the mechanism that turns autonomy into something you can defend and, when needed, walk back.

Why this is a system property, not a model property

It is tempting to believe the answer to the rollback question is a smarter model that never errs. A better model helps, because it plans the wrong action less often, and Dex uses a multi-provider engine with extended reasoning and up to forty reasoning steps per task so it rarely gives up or guesses on the first error. But planning fewer wrong actions is not the same as making wrong actions safe. Safety lives in the deterministic layers that surround the model: the policy gate that decides whether a planned action may execute, the permission and isolation model that decides how far it can reach, and the audit log that decides whether it can be reversed.

This is the practical meaning of governed autonomy. The model proposes; the code decides, contains, and records. None of the three safety layers depends on the model behaving well, which is precisely why they hold up in front of a risk committee. You are not asking a board to trust an AI. You are showing them a documented policy set, a complete per-action record reconcilable against native M365 logs, and code-level guardrails that fail closed.

The three questions to ask any autonomous IT vendor

If you are evaluating agentic IT, the rollback question is really three questions. Ask each one specifically, and be skeptical of a vendor who blurs them together.

1. Where is the check enforced? In the prompt, or in the execution layer. Only a code-level gate survives a malformed or adversarial request. If the answer is "we instruct the model not to," that is a suggestion, not a control.

2. What bounds the blast radius? A broad application API key means every mistake is potentially org-wide. Delegated, scoped permissions plus per-user and per-tenant isolation mean a mistake is bounded before it happens. Ask what identity the system acts as.

3. What does reversal actually look like? Ask to see the record a single action produces, and ask whether that record is written by the execution layer or narrated by the model. The first is reversible evidence. The second is a story.

A vendor who can answer all three cleanly is selling governed autonomy. One who cannot is selling autonomy on trust, and trust is exactly the thing a risk committee is not allowed to accept. For the security architecture behind these answers, delegated permissions, per-org isolation, and the hard-coded guardrails, see how Dex secures autonomous execution.

The rollback question deserves a real answer, not reassurance. The honest one is that a governed autonomous IT engineer will occasionally plan the wrong action, the same way a senior engineer occasionally does, and that the system is built so most of those are refused before they run, the rest are contained to a small surface, and every one is recorded precisely enough to reverse. That is not autonomy without risk. It is risk that is bounded, visible, and undoable, which is the only kind of autonomy an enterprise should ever put in production.