Human in the Loop Remediation: Automation with Approval

Human in the loop remediation is not a person clicking approve. It is a control that binds one accountable reviewer to one exact change, one target set, one recovery plan, and one proof standard.

The problem is not whether automation can run a fix. It can. The problem is whether the reviewer sees enough current evidence to judge the consequence before the fix runs. A vague approval prompt turns a human into a delay with a name attached.

Good human review removes uncertainty that software cannot settle. It does not repeat machine work. The system gathers evidence, resolves targets, drafts the smallest repair, predicts interruption, and prepares tests. The person decides whether the business can accept that exact action now.

What is human in the loop remediation?

Human in the loop remediation is an operating model where software prepares or executes part of a security repair, while a named person retains authority at defined decision points. The gate may sit before execution, before expansion beyond a canary, before a destructive recovery action, or before closure.

That definition matters because the phrase is often reduced to one button. A useful gate has six parts: current evidence, a versioned plan, resolved targets, a failure limit, recovery instructions, and a closure test. The approval expires if a material input changes.

Start with the broader automated remediation operating model. Human review is one control inside that system. It cannot compensate for weak asset identity, an untested command, missing recovery, or a closure test that merely trusts the execution tool.

Why does the approval boundary matter now?

Attack speed and repair speed are pulling in opposite directions. The Mandiant M-Trends 2026 report is based on more than 500,000 hours of investigations conducted in 2025. It reports a global median dwell time of 14 days, up from 11 days, while the median handoff from an initial access partner to a second threat group fell to 22 seconds. An approval queue that waits seven days is not a safety mechanism when an attacker can transfer access before the ticket renders.

The 2026 Verizon Data Breach Investigations Report was published on May 19, 2026. It found that vulnerability exploitation caused 31 percent of breach entry, while the median full resolution time for a critical vulnerability reached 43 days. Those figures make the goal clear: automate the preparation and evidence work, then reserve scarce human time for decisions with real consequence.

What should a person actually approve?

Approve an immutable packet, not a sentence that says apply the patch. The packet should identify the finding, evidence timestamp, target asset IDs, current state, desired state, plan version, command or deployment reference, required privileges, expected interruption, canary group, maximum failure count, recovery action, security test, service test, and expiration time.

Bind approval to a digest or version identifier. If the target list grows from 12 servers to 120, the command changes, the evidence ages past policy, or the recovery artifact disappears, invalidate approval. Asking again is not bureaucracy. It is proof that the authorized action is still the action about to run.

The approval record also needs identity and reason. Capture who decided, under which role, at what time, with which comment, and against which policy. Do not let the same identity author the repair, approve it, run it with broad privileges, and close the finding on a sensitive system.

Which remediations need a human gate?

Gate based on consequence, novelty, reversibility, and evidence quality. Severity alone is a poor switch. A critical package update on a disposable test worker may fit standing policy. A medium identity change on a shared production tenant may need two owners.

Review the approval boundary for AI security decisions when analysis itself uses a model. The person should see sourced evidence, missing information, and the reason for the proposed action. Confidence text without provenance does not improve a decision.

How do you implement a real approval pause?

Put the gate inside the execution system. Email or chat can notify a reviewer, but a reply should not become an unverified command. The executor must remain paused until an authenticated principal records a decision against the current plan version.

AWS Systems Manager provides a concrete example. Its official aws:approve action documentation says the action can appear in the mainSteps section of a schema 0.3 runbook. The current documentation sets a default timeout of seven days, a maximum of 30 days, and a maximum of ten approvers. This reduced example follows the documented syntax:

schemaVersion: '0.3'
mainSteps:
  - name: approveRepair
    action: aws:approve
    timeoutSeconds: 3600
    onFailure: Abort
    inputs:
      Message: "Approve plan repair-2026-08-16-v3 for the listed canary"
      MinRequiredApprovals: 1
      Approvers:
        - arn:aws:iam::123456789012:role/ProductionChangeApprover

The syntax creates a pause. Your workflow must still attach the plan, evidence, target list, and tests to the request. Keep the executor role separate from the approver role, abort on timeout, and require a new request after any material edit.

What does human review look like in a real repair?

A current observation finds an unsafe SSH setting on 84 Linux servers. Seventy hosts inherit the same managed configuration. Nine are application exceptions, and five have stale ownership data. The system drafts a source change for the managed 70, prepares one canary, defines a service test, and leaves the other 14 outside execution.

The platform owner sees the exact configuration difference, affected service, canary, maximum of one failed health check, restore commit, and verification query. The owner approves version 4 for the 70 resolved targets. Before execution, inventory refresh adds two hosts. The gate rejects the changed set because approval covered 70, not 72.

Version 5 returns with the two additions named. The owner approves. The canary passes, ten hosts run next, then the remaining batch. One host fails the service test and restores. Fresh evidence closes 71 targets and reopens one with captured output. The 14 excluded assets keep separate work. Nothing disappears inside a green parent ticket.

How much human review can your team support?

Approval is a queue. Treat it like one. If 40 requests arrive each day and each takes four minutes to read, decide, and document, that is 160 minutes of focused review. One reviewer spends two hours and 40 minutes before handling any exception. If arrival grows to 80, the same gate consumes more than half a workday.

Reduce volume through policy, not rushed clicks. Let proven repairs on low consequence systems earn standing approval. Group identical targets under one bounded plan. Reject incomplete packets before a person sees them. Route only new, destructive, uncertain, or business sensitive work to people.

Measure approval age, rejection reason, changed packet rate, emergency bypasses, failures after approval, and reviewer load. A low rejection rate can mean excellent preparation. It can also mean nobody reads the packet. Sample approved work and compare the decision with later results.

What makes human approval fail?

• Vague scope. The reviewer approves patch production without seeing target IDs or the release version.
• Stale facts. Evidence changes after approval, but the decision remains valid forever.
• Wrong authority. Security approves an outage consequence that belongs to the service owner.
• No recovery. The prompt asks whether to run but does not show how failure will be contained.
• Approval fatigue. Routine safe work floods the queue until review becomes ceremonial.
• Self attested closure. The same tool that changed state declares the vulnerability gone.

A strong remediation workflow gives each failure a branch. Rejected plans return to a named author. Expired evidence returns to collection. Failed execution invokes recovery. Failed proof reopens the finding.

What changed for approval tooling during the last year?

AWS states that Systems Manager Change Manager stopped accepting new customers on November 7, 2025, while existing customers can continue using it. That current Change Manager availability notice is a practical warning. Approval policy should survive a product change. Keep the decision contract portable even when one service implements the pause.

Store the packet version, identities, decision, and evidence in your own durable remediation record. A vendor approval screen is an interface. It should not be the only place where the organization can reconstruct authority.

What should happen during an emergency bypass?

Emergency authority should shorten the decision path, not erase it. Define who can invoke the bypass, which incident conditions permit it, the maximum target scope, the actions that remain prohibited, and when the authority expires. Record the exact reason before execution when time allows, or immediately after containment when it does not.

Keep recovery and verification mandatory. Urgency is the reason to prepare those steps earlier, not permission to improvise them later. A responder isolating an actively compromised host may not wait for a normal change meeting. The workflow can still capture the target, command, identity, output, service consequence, and fresh test.

Review every bypass by the end of the next business day. Ask whether the trigger met policy, whether scope expanded, whether any safeguard was skipped, and whether the normal approval path created harmful delay. Repeated bypasses for the same repair show that standing policy or the standard route needs work. Do not normalize emergency access through habit.

Where should AI fit in human in the loop remediation?

AI can summarize endpoint evidence, explain why a finding appears relevant, draft exact remediation guidance, compare a proposed state with policy, and call out missing facts. It should not quietly widen targets, invent a command, or decide that a failed test is close enough.

Artemes applies deep endpoint context with AI driven analysis to help prepare a reviewable decision. The useful product boundary is simple: analysis proposes, policy routes, a person owns consequence where needed, and fresh evidence proves the result.

Turn repeated approved repairs into reviewed remediation as code. Version control and tests reduce what a person must rediscover. They do not remove ownership.

Frequently asked questions

Does every remediation need human approval?

No. Proven, reversible repairs with current evidence, fixed targets, low consequence, tested recovery, and independent proof can run under standing policy. Human review belongs where judgment changes the outcome.

Who should approve a security remediation?

The person who owns the consequence. Security owns the risk condition and closure standard. A system or business owner usually owns interruption, recovery, and timing. Sensitive changes may need both.

How long should a remediation approval remain valid?

Only as long as its evidence, targets, plan, and recovery assumptions remain valid. Set an explicit expiration based on change rate and consequence. Any material difference should force a new decision.

Is a pull request review enough approval?

A pull request review is enough only when it contains the full change, protected target mapping, recovery path, tests, and required owners. A code review that cannot identify production consequence is incomplete.

Executive takeaway

Pull ten recent approval records. Ask what exact action each person authorized, which evidence they saw, when that evidence expired, who owned service impact, what recovery was ready, and which fresh test proved closure. If the record cannot answer those questions, redesign the gate before adding more automation.