No Rollback Plan

Issue: Agent performs irreversible actions without recovery strategy.

Frequency: Rare but Catastrophic

Symptoms

• Deletion/send/deploy without revert path.
• Production deploy, config push, or database migration executes with no documented revert command or previous-state snapshot captured.
• Agent deletes cloud resources (S3 buckets, DB instances) with versioning/backup disabled and no prior export step.
• Post-incident review finds the “rollback plan” in the agent’s trace was a vague statement (“can be reverted if needed”) rather than an executable procedure.
• Compensating action referenced in the plan doesn’t actually exist for the target system (e.g., assumes a delete is soft when it’s hard).

Root Cause Reversibility is never classified when a tool is registered, so the execution layer has no basis for knowing that a given action needs a rollback plan at all — a delete call looks the same to the executor whether it’s trivially undoable or permanent. Cost-cutting and cleanup tasks carry an implicit urgency that discourages the extra step of staging or dry-running a deletion, and the evidence used to justify the action, like an access-log lookback window, is frequently shorter than the resource’s real usage cycle, producing a confident false negative for “unused.” Without a human-approval gate for irreversible actions below a certain blast radius, and with compensating mechanisms like versioning assumed to exist rather than verified against the specific resource’s actual configuration, the agent proceeds on an assumption of recoverability that was never actually confirmed.

Example

An SRE agent is asked to "clean up unused S3 buckets in the staging account to cut costs." It identifies a bucket that appears unused based on a 30-day access log query and issues a hard delete without first checking whether versioning was enabled, without exporting a manifest of the bucket's contents, and without staging the deletion behind a confirmation step. The bucket turns out to be the target of an infrequent but critical monthly batch job that hadn't run in the lookback window; the data is unrecoverable, and the monthly reporting pipeline breaks with no way to reconstruct the lost inputs.

Contributing Factors

• Action’s reversibility was never classified at the tool-registration level, so the executor has no basis to require a rollback plan.
• “Cleanup” and cost-reduction tasks carry an implicit urgency that discourages the extra step of staging or dry-running the deletion.
• Access-log lookback windows are shorter than the actual usage cycle of the resource, producing a false negative for “unused.”
• No human-approval gate exists for irreversible actions below a certain blast-radius threshold (e.g., single bucket vs. whole account).
• Compensating actions are assumed to exist (“S3 has versioning”) without verifying the specific resource’s actual configuration.

Eval Recipes

Test Cases

Metrics

Mitigation Strategies

Prevention

1. Reversibility Classification Registry: Every tool/action is tagged at registration time as reversible, compensable (recoverable via a defined compensating action), or irreversible. Actions tagged compensable or irreversible require an accompanying rollback/compensation plan before the executor allows the call.
2. Rollback Plan Requirement Gate: For any action classified as compensable or irreversible, the agent must produce a concrete rollback/compensation procedure (or route to human approval when no compensation exists) before execution; the executor validates the rollback plan references real, executable steps rather than accepting free-text assurance.
3. Two-Phase Commit / Staging for Destructive Operations: High-risk actions (deletes, sends, deploys) first execute a dry-run or staged version showing the diff/impact, requiring explicit confirmation before the irreversible step is committed.

Detection & Response

1. Irreversible Action Without Rollback Detector: Middleware checks, at call time, whether an action tagged compensable/irreversible has an attached, validated rollback plan; missing plans block the call and raise a violation event.
2. Post-Action Compensation Readiness Audit: For executed compensable actions, verify the compensating action is actually available and functional (e.g., the “undo delete” API still exists) rather than assuming the rollback plan is valid at write time.
3. Incident Correlation: Track incidents (data loss, customer impact, financial loss) back to whether the triggering action had a rollback plan, to prioritize which action classes need stricter gating.

Architecture Patterns

1. Action Reversibility Registry: A tool metadata catalog storing reversibility class, known compensation action (if any), and approval requirements, consulted by the executor on every call.
2. Compensating Transaction Framework (Saga Pattern): For multi-step irreversible workflows, each step registers a compensating action executed in reverse order if a later step fails, rather than leaving partial irreversible state.
3. Human-in-the-Loop Approval Gate: High-risk irreversible action classes (mass deletion, production deploy, fund transfer) require explicit human sign-off on both the action and its rollback plan before execution proceeds.

Metrics

1. irreversible_actions_without_rollback_count: Target: 0; Alert threshold: > 0
2. rollback_plan_coverage_percent: Target: 100% of compensable/irreversible actions; Alert threshold: < 100%
3. compensation_execution_success_rate_percent: Target: > 99%; Alert threshold: < 95%
4. mean_time_to_compensate_minutes: Target: < 15 min; Alert threshold: > 60 min

Alerts

1. Irreversible Action Executed Without Rollback Plan (P1 - Critical): Condition - an action tagged irreversible/compensable executed with no validated rollback plan attached. Action: Immediate incident declaration, freeze affected system, manual recovery review.
2. Rollback Execution Failure (P1 - Critical): Condition - an invoked compensating action fails or times out. Action: Escalate to on-call, engage manual recovery procedure, notify affected stakeholders.
3. Approval Gate Bypass (P2 - Warning): Condition - a high-risk irreversible action executed without required human approval record. Action: Audit the gating logic, suspend the agent’s autonomous authorization for that action class.

Production Signals

Key Metrics

Alerts

References

• CSA-Agentic-Profile
• Note: Agentic AI governance profile built around NIST RMF.