Remediation Flight Recorder

The problem

Can this fix prove what it changed, and undo itself when verification fails?

After a bad change, nobody can reconstruct what it looked like before from memory — and blast radius was estimated in a meeting rather than computed.

What it does

It runs remediation as one auditable transaction: freezes the pre-change exposure snapshot, computes direct and transitive blast radius, gates on policy and explicit named approval, binds external execution receipts, verifies the post-change state, and enters rollback when verification fails — all sealed in a SHA-256 evidence chain.

How it works

The state machine refuses out-of-order transitions: a transaction denied by policy can never be approved or executed, and approval records an explicit named approver rather than being implied. Execution stays external — the server binds the receipts your executor returns instead of touching devices. Every lifecycle event is chained with SHA-256 over canonical data, so later tampering is detectable.

Tool surface

MCP over stdio. Compatible with Claude Code, Claude Desktop and Cursor, or usable directly as a TypeScript library. No API key, account or Tenable product is required.

• remediation_preflight

  Seal the snapshot, compute blast radius, evaluate policy and build the rollback plan.

• remediation_approve

  Record an explicit named approver; approval is never implied.

• remediation_record_execution

  Bind external executor receipts to an approved transaction.

• remediation_verify

  Compare the declared post-state expectation against the supplied post-state.

• remediation_record_rollback

  Record a receipted rollback after failed verification.

• remediation_verify_ledger

  Verify the sealed evidence chain for the transaction.

What it deliberately does not do

• ·It never SSHes, calls an API or changes a device — execution is external and receipted.
• ·Denied means denied: the state machine cannot be talked past.
• ·Rollback requires a rollback plan built at preflight.