The closed-loop pipeline runs the easy part well. Detect fires, decide picks a remediation, act executes, and verify confirms. The hard part is the line between "auto-execute" and "page a human." Most teams draw it by gut. Some rules go to action, the rest go to a ticket queue or Slack. The split is rarely written down, and when it is, it's a static rule list maintained by whoever owned the loop last quarter.

That gut-feel split is where autonomous remediation goes wrong. Pull the line one way and the loop becomes a cron job that touches production without the on-call understanding why. Pull it the other way and the loop becomes a glorified alert generator: every signal lands in a queue, the queue stays full, action rate decays back to the same 5% a static report would have produced. Both failure modes kill trust faster than any single bad auto-action.

The fix is to stop drawing the line by gut and start computing it. Three scores per remediation candidate: how much damage can this do (blast radius), how fast can we undo it (reversibility), and how sure are we the signal is real (confidence). Multiply them together. One threshold decides auto-vs-page. The threshold is a knob the team tunes monthly from incident postmortems, not a per-rule policy debate.

This pattern composes with the existing closed-loop FinOps detect-decide-act-verify framework and the closed-loop IAM remediation work. It's the missing piece between "we built the loop" and "we trust it on production."

The trust line is the closed-loop's hardest design choice

Every team running closed-loop remediation hits the same fork at week three. The first wave of policies were obvious — terminate idle non-prod EC2, delete unattached EBS volumes, downgrade unused log-group retention. Nobody pushed back. Action rate hit 70-85% within a sprint.

The second wave of policies is where it gets contested. Right-size production RDS instances. Drop unused IAM permissions. Migrate cold S3 objects to Glacier. Each one is technically reversible, statistically safe, financially significant. And each one gets stuck in a 90-minute meeting where someone says "but what if it's wrong on the one prod instance that matters."

The teams that get past this fork are the ones that stop debating per-policy and start computing the trust line. Three scores per candidate signal. One threshold. Postmortem-driven tuning. The result: 70-85% of detected events run without a human, the rest get a pre-filled ticket with the per-axis breakdown so the human spends 30 seconds deciding instead of 30 minutes.

Score 1: blast radius (per resource, not per rule)

Blast radius is how much customer impact a remediation creates if it goes wrong. The naive version is a constant per rule: "right-size production database = high blast radius, terminate non-prod VM = low." This loses immediately because blast radius isn't a property of the rule. It's a property of the resource the rule touches in this specific run.

Compute blast radius at policy-evaluation time from three inputs that already exist in the cloud accounts.

Tags catch the obvious cases: env=prod raises the floor, env=non-prod lowers it. But tags get gamed. A correctly-tagged-as-non-prod database serving 30% of customer traffic is not low blast radius, no matter what the tag says. The traffic signal (request count or connection count over the last 7 days, sampled from ALB target groups or APM) is the corrective.

Customer attribution is the third input. A resource that maps to one specific customer (multi-tenant routing, dedicated subnet) is high blast radius even if the traffic is low — losing that customer is worse than losing 2% of generic traffic. Pull this from the routing layer or the customer-id tags propagated through the data plane.

The blast-radius score is min(tag_score + traffic_score + customer_score, 1.0). Production-tagged + customer-facing + multi-tenant scores 0.9. Non-prod, single-tenant, sub-10-req/min scores 0.1. The 0.1 to 0.9 spread is what makes the trust score selective enough to be useful — most resources land in the 0.2-0.6 range.

Score 2: reversibility (per action, includes time-to-reverse)

Reversibility is per action, not per resource. Stopping an idle EC2 instance is reversible — start it back up in 90 seconds, the data is intact, no client connections to restore. Deleting a snapshot is not — the bytes are gone. The same resource can be touched by multiple actions with different reversibility scores.

Maintain reversibility as a lookup table. Most cloud teams need 50 to 150 entries to cover their action catalog. The table is the highest-leverage piece of work in the system: a wrong entry causes incidents, a right entry unlocks auto-action across hundreds of resources of that type.

Time-to-reverse matters because reversibility is implicit, not stated. An action that's "reversible" but takes 2 hours fails the trust test if the user impact lands in the first 5 minutes. The reversibility score has to bake in a time-to-reverse multiplier: anything taking longer than the user-perceptible-impact window gets discounted.

Practical heuristic: reversibility = base_score × min(1, 5_minutes / time_to_reverse_minutes). Stop EC2 stays at 1.0. S3-to-Glacier drops from 0.4 to 0.4 × (5 / 240) = 0.008 — effectively non-reversible. The math forces the table to be honest about which actions are actually safe to auto-run.

Score 3: confidence (per detection, signal stability)

Confidence is how sure the detector is that the signal is real. It comes from the detector's signal stability, not the action class. A CloudWatch alarm that's been firing consistently for 14 days at sub-5% CPU has confidence 0.95: the data is not noisy, the threshold is well-clear, the duration is long. A one-off cost-anomaly spike from a forecast model has confidence 0.55: the signal might be a real change or might be a forecast wobble.

Each detection source has a typical confidence range:

The pattern that buys the most trust per unit of work: track which detector flagged a signal and how long it has been flagging. Both pieces of metadata already exist in the detector. Surface them as an explicit confidence field on the signal payload, not a hidden property. The downstream trust math reads the field and makes a decision; if the detector improves later, only the producer changes.

Multi-detector agreement is the cheap upgrade. Two detectors flagging the same resource pushes confidence past 0.95 even if each individually is at 0.7. Cost anomaly + drift detection + CloudWatch alarm all firing on the same RDS instance is a stronger signal than any one of them alone.

The auto-action threshold (one knob, tuned monthly)

The trust score combines the three inputs:

trust = (1 - blast_radius) × reversibility × confidence

(1 - blast_radius) because blast radius is a penalty: high blast radius reduces trust. The other two are bonuses. Worked examples on both sides of a 0.55 threshold:

Signal A: stop a non-prod EC2 instance flagged by a 14-day CloudWatch alarm. Blast radius 0.3 (non-prod, single-tenant, low traffic), reversibility 1.0 (stop is recoverable in 90 seconds), confidence 0.95 (stable signal). Trust = 0.7 × 1.0 × 0.95 = 0.665. Above 0.55. Auto-run.

Signal B: right-size a customer-facing RDS instance flagged by a single-day cost anomaly. Blast radius 0.5 (customer-facing but multi-tenant), reversibility 0.6 (reversible but with connection pool warmup), confidence 0.7 (single-day signal). Trust = 0.5 × 0.6 × 0.7 = 0.21. Below 0.55. Page a human with the pre-filled ticket.

Why this is one knob, not three: the team tunes the threshold based on incident outcomes. If two auto-actions in a month cause customer-facing degradation, lower the threshold from 0.55 to 0.65. If the page rate is too high and engineers are rubber-stamping every approval, raise it to 0.50. The per-axis weights stay constant; the human-vs-machine line moves.

The first-month ritual is what makes this work. Every auto-action gets a postmortem, regardless of outcome. The team meets weekly to look at the false-negatives (auto-action that turned out to be wrong) and false-positives (paged for nothing). The threshold drops 2-3 times in week one, then stabilizes.

How trust scores compose with closed-loop FinOps

The trust score is not a separate system. It plugs into the four-stage detect-decide-act-verify loop already running:

Detect produces the confidence input as an explicit field on the signal. Decide computes blast radius and reversibility, multiplies them with confidence, compares to the threshold. Act executes only if trust passes. Verify samples metrics over a window matched to the action's time-to-reverse (a 90-second-to-reverse action gets verified over 2 minutes; a 4-hour-to-reverse action gets verified over 5).

The verify-window matching the reversibility window is the under-discussed piece. Verify too early and you miss the slow-failing case; verify too late and the cost data lags. Match the window to time-to-reverse and the loop's outcome data is honest.

What changes after 6 weeks of production data

Three numbers move predictably as the team gets data on the loop's behavior.

The threshold drops from its initial conservative setting (often 0.7) to a stable middle ground (0.50 to 0.60) over 4-6 weeks. The first drop usually happens in week one when the team realizes 60% of detected signals are landing in the page queue and engineers are approving them all without changes. The second drop happens around week three when one false-negative postmortem reveals that the threshold was too tight on a class of safe actions. After week six, threshold changes are quarterly, not weekly.

The auto-action rate stabilizes around 70 to 85% of detected events. Below 70%, the threshold is too high; the loop is doing report work, not action work. Above 85%, the threshold is too low and incidents start. The 70-85 band is the operating range; teams that go outside it almost always retune within two weeks.

MTTR drops 3 to 5x for the auto-action class. Manual remediation MTTR for cost issues is typically 18 to 45 minutes (detect → triage → ticket → assigned → actioned). Auto-action MTTR is 2 to 4 minutes (detect → score → execute → verify). The drop multiplies across hundreds of monthly events, which is where the financial case for the closed loop actually lands. Pager-page reduction is the secondary metric: teams report 40 to 60% fewer cost-related pages after month three.

The trust score is not a fancy ML model. It's three deterministic inputs, one product, one tuned threshold. The leverage is in writing the inputs down explicitly instead of carrying them in the heads of whoever is on-call this month. Once they're written down, the loop's behavior is auditable, the threshold is tunable, and the team's confidence in the system grows from "we trust this rule" to "we trust this score." That second posture is what makes autonomous remediation actually autonomous.