Why This Matters Now
Every leading DEX platform now sells some form of agentic or autonomous IT. Nexthink Workspace can run remote actions and workflows directly from an Assist conversation, presenting an impact assessment and requiring approval before anything executes. Tanium Atlas runs multi-step workflows that pause for explicit approval before any consequential action. Riverbed, Lakeside, and ControlUp all position agentic AI as the center of their 2026 roadmaps.
The vendors are describing what their agents can do. Very few buyers have written down what their agents are allowed to do. That is a governance question, and it belongs to the organization, not the vendor. An agent that restarts a service on one laptop is a convenience. An agent that pushes a configuration change to forty thousand laptops at 9 a.m. on a Monday is a change management event, whether or not anyone filed a change request.
The core principle. Automation does not remove accountability. It moves it. Someone still owns every action an agent takes; governance makes that ownership explicit before the first action runs, not after the first incident.
The Question to Answer
The useful question is not "should we let AI fix things?" It is four narrower questions, answered in writing:
- What is an agent allowed to do, on which kinds of devices and users?
- Who approves each class of action, and at what scale does approval change?
- How do we stop it, roll it back, and contain the damage when it is wrong?
- How do we know it is working: what evidence exists for every action, and who reviews it?
Five Controls for Autonomous Remediation
1. Classify every action by risk tier
Start with an inventory of every remediation, script, and workflow your platform can run, whether a person or an agent triggers it. Assign each one a tier based on reversibility and potential impact. The tier, not the tool, decides the approval model.
| Tier | Description | Examples | Suggested approval model |
|---|---|---|---|
| Tier 0 Observe | Read-only diagnostics. Changes nothing on the device. | Collect logs, check disk space, test connectivity, read configuration | Fully autonomous. Logged. |
| Tier 1 Low impact, reversible | Restores a known-good state with no lasting change. | Clear a cache, restart a service, reset a network adapter, free temporary storage | Autonomous within a defined scope. Pre-approved as a standard change. |
| Tier 2 Configuration change | Changes settings or software state; reversible with effort. | Registry or policy changes, driver updates, reinstalling an application | Human approval per run above a device-count threshold. Staged rollout required. |
| Tier 3 High impact or irreversible | Could cause data loss, security exposure, or broad disruption. | Uninstalling security agents, reimaging, deleting user data, changes to authentication | Never autonomous. Named approver plus normal change control. |
2. Set approval thresholds by blast radius
The same action carries different risk on ten devices than on ten thousand. Define a blast-radius threshold for each tier: the number of devices or users above which an autonomous action must stop and wait for a person. A Tier 1 cache clear might run unattended on up to 500 devices per hour. A Tier 2 driver update might need approval for anything over 50. Write the numbers down, and make sure the platform can enforce them rather than relying on habit.
3. Stage every rollout
Autonomous does not mean all at once. Any Tier 2 action should move through rings: a pilot group that represents your hardware and OS diversity, then a small percentage of production, then the rest. Define what success looks like at each ring (completion rate, no increase in crashes or tickets, no drop in sentiment) and stop automatically when a ring misses it. This is the same discipline good teams already apply to patching; the difference is that an agent can move through the rings much faster than a person, which is exactly why the gates must be automatic.
4. Keep an evidence trail for every action
For each action an agent takes, you should be able to answer, months later: what triggered it, what data the agent saw, what reasoning or rule it followed, who approved it (or which pre-approval covered it), what changed on the device, and what the outcome was. If your platform cannot produce that record, the action should not be autonomous. Auditors, security teams, and your own post-incident reviews will all ask for it.
5. Build the stop button first
Before turning on any autonomous action, confirm three capabilities: a global kill switch that halts all agent-initiated actions at once, a per-action disable that does not require a release cycle, and a documented rollback for every Tier 1 and Tier 2 action. Test them. A kill switch nobody has tried is a hope, not a control.
Fitting It Into Change Management
Most enterprises already have the right vocabulary. ITIL-style change management distinguishes standard changes (pre-approved, low risk, repeatable), normal changes (assessed and approved individually), and emergency changes. Autonomous remediation maps onto that structure cleanly:
- Tier 0 and Tier 1 actions become a catalog of pre-approved standard changes, reviewed and re-approved on a fixed schedule, for example quarterly.
- Tier 2 actions follow normal change approval when they exceed their blast-radius threshold, with the agent preparing the impact assessment.
- Tier 3 actions stay outside autonomous scope entirely.
Bring the change advisory board into the design early. Teams that present autonomous remediation as "the agent will just fix things" tend to meet resistance. Teams that present a tiered catalog with thresholds, evidence, and a kill switch tend to get approval, because they are answering the board's questions before the board asks them.
Measuring Whether It Works
Governance includes proof. Track a small set of measures for autonomous actions and review them in the regular DEXOps cadence:
- Success rate: actions that completed and resolved the condition they targeted.
- False positive rate: actions that ran on devices that did not need them. Every workflow should be harmless when it runs unnecessarily.
- Recurrence: issues that return within 7 or 30 days of an automated fix, which signals a symptom being treated instead of a cause.
- Employee experience after the fact: sentiment or ticket volume for affected employees, confirming the fix felt like a fix.
- Approval latency: how long Tier 2 actions wait for a human. If it is days, the thresholds or the approver model need adjusting.
Questions to Ask Your Vendor
- Can we restrict which actions an agent may run, by action, device group, and user population?
- Can we set device-count thresholds that force human approval, and does the platform enforce them?
- Does the agent present an impact assessment before acting, and is it saved with the action record?
- Is there a global kill switch for agent-initiated actions, and who can use it?
- What is recorded for each action: trigger, data, reasoning, approver, change made, result?
- Do agent actions respect the same role-based permissions as human-triggered actions?
- How are staged rollouts and automatic stop conditions configured?
- Can action records be exported to our ITSM or SIEM for audit?
Where This Sits in a DEXOps Program
Autonomous remediation is a capability of the Preventative stage of the Dexterity Digital DEX Maturity Model, and it only holds up when the governance around it is in place. In practice: the weekly DEXOps review looks at the autonomous action log and anything that hit a stop condition; the monthly program review approves additions to the action catalog; the quarterly executive review reports outcomes and confirms the risk posture. The governance model on our Governance page already has the right cadence. Autonomous actions become a standing item in it.