Remediation authority should be set by the action's blast radius, reversibility, confidence and evidence quality, and business impact. Low-impact, reversible, well-evidenced actions may be eligible for automated execution. Changes to production, regulated systems, or anything hard to reverse require approval or escalation.
Detection and remediation have different tolerance for being wrong. A detection rule that produces a false positive costs attention: an analyst reviews an alert and dismisses it. The cost is bounded and mostly reversible. A remediation action that is wrong costs more than attention. A configuration change that breaks a production service, blocks a legitimate user, or locks out a business system has real operational impact, and it can be very hard to reverse quickly.
This asymmetry is why the same organisation can reasonably automate detection-related decisions and still require approval for remediation. NIST's guidance on patch management makes the same point in operational terms: the April 2022 revision of NIST Special Publication 800-40 frames enterprise patching as "preventive maintenance" that must balance security benefit against the operational risk of the change itself; a change to a production system is never only a security action. The authority level should track the change's risk, not the convenience of automation.
The asymmetry shows up in metrics too. Detection quality is measured in detection and response times, where speed is almost always good. Remediation quality has to be measured in outcomes: did the change reduce risk without breaking the service, and can the record prove it? A fast remediation that breaks a business system is not a fast win; it is an incident with a security pretext. Designing authority levels around this difference; not around "how autonomous can we be"; is what separates governed remediation from automation theatre.
The central asset for any remediation-autonomy decision is a matrix that maps action characteristics to a recommended authority level. This is a score-free rubric: the goal is to force the right questions, not to manufacture a number.
| Action | Scope | Reversible? | Evidence confidence | Business impact | Recommended authority |
|---|---|---|---|---|---|
| Re-run validation on a test target | Single, isolated | Yes, fully | High | Negligible | Autonomous candidate |
| Rotate an exposed credential for a service account | Single account | Yes, with monitoring | High | Low–moderate | Autonomous candidate (with verification) |
| Restrict an internet-facing management interface | One system | Yes, within change window | High | Moderate (production) | Require approval |
| Apply a patch to a production application cluster | Cluster-wide | Requires tested rollback | Moderate–high | High | Require approval |
| Change network segmentation affecting traffic | Segment-wide | Hard to reverse | Partial | High | Escalate |
| Disable an account shared by multiple services | Cross-service | Uncertain | Partial | High | Escalate |
The matrix is a starting framework, not a universal policy. Your organisation calibrates each cell against its risk appetite and change-management rules. What matters is that the authority outcome is produced by named variables; and that the same variables are used consistently across decisions.
The following scenarios are illustrative examples of how the matrix works. They are not claims about any product's availability today.
Scenario 1; Autonomous candidate: credential rotation. A service account's credential appears in a breach corpus that is relevant to the organisation's threat context. The action affects one account, has strong evidence, and is reversible with monitoring. This is the profile of an action that could be automated: defined scope, high confidence, and a verification step (confirm the new credential works and the old one fails).
Scenario 2; Requires approval: production configuration change. A management interface on a production system is exposed and running software with an actively exploited vulnerability; a profile that matches CISA's Known Exploited Vulnerabilities catalog, launched November 3, 2021, which codifies the priority of vulnerabilities with confirmed in-the-wild exploitation. Restricting the interface is the right action, but it touches production availability and must happen in a change window. The correct authority is approval: the system owner decides the timing and the rollback plan.
Scenario 3; Escalate: segment-wide change. A proposed fix would change network segmentation affecting multiple services and business functions, and the evidence about downstream dependencies is incomplete. The action's blast radius is broad and its reversal is uncertain. The correct behaviour is escalation; to the network owner and the business stakeholders; not execution. Acting on partial evidence at this scale is how small changes become outages.
Remediation authority is only as good as the evidence that feeds it. Before any action, the system should be able to answer: What exactly is affected? Why is this action the right one? What confidence do we have, and what could change that confidence? After the action, the loop is not closed until there is verification: Did the change achieve the intended outcome, and did it break anything else?
This is where validation capability earns its role. In digiDations' model, ATLAS provides evidence used to validate defensive effectiveness or remediation outcomes; in plain terms, it helps answer "is the exposure actually closed, and do our controls now behave as intended?" Post-action validation is what converts a remediation from an assumption into a verified result, and it is what makes an automated action auditable rather than merely fast.
TARA AI coordinates governed next actions. Teams define objectives and operational guardrails; TARA AI assembles context, proposes the appropriate action, routes consequential decisions to approval, and records evidence for verification. It orchestrates workflows within ATLAS and coordinates specialised workers across HELIOS, ORION, APOLLO, and connected third-party tools. Review TARA AI, see ATLAS validation evidence, read the governed-autonomy guide, and learn how Autonomous CTEM works.
Start small and make the loop trustworthy before widening it:
Two rollout cautions. First, observation mode is not a waste of time; it is the cheapest way to discover that the evidence the system assembles is incomplete or that its proposals systematically miss business context. Second, stop conditions are not optional settings; define them before the first automated run, and treat "we never thought of that condition" as a review finding, not an excuse. The goal of the rollout is not to maximise automation; it is to know precisely which actions, under which evidence, are safe to delegate; and to be able to prove that to anyone who asks.
CTA: Assess one workflow for evidence quality, reversibility, and approval requirements.
Can AI remediation be audited? Only if the records exist to audit it. Every decision should carry the objective, the assembled evidence, the proposed action, the authority level, the approval, and the post-action verification. If a remediation loop cannot reconstruct why an action was taken and what it proved, it is not ready for production.
What happens when evidence is incomplete? Incomplete evidence raises the authority level. If confidence is insufficient for the action's blast radius, the correct behaviour is escalation; present the partial evidence and the open questions to a human. Acting on weak evidence is how small mistakes become large incidents.
How do you measure whether a remediation worked? Verification is the measurement. After the change, re-check the exposure, confirm the intended control state, and compare against the pre-action baseline. If the remediation changed something and nothing verified it, you have not remediated; you have hypothesised.