# Chokepoint Remediation Playbook

> An eight-stage remediation chain from thousands of findings to a handful of proven fixes, with a human checkpoint before every external mutation and a runner that enforces the contract offline.

- Type: Playbook
- Author: tarhou
- License: MIT
- Trust tier: contributed (passed automated validation and a baseline maintainer review)
- Last reviewed: 2026-08-05
- Source repository: https://github.com/tarhou/chokepoint-finder-playbook
- Repo state: not archived
- Last push: 2026-08-10T21:45:01Z
- Stars: 1 (a popularity signal, not a safety signal)
- Forks: 0 (a popularity signal, not a safety signal)
- Open issues: 0
- Language: Python
- Health checked at: 2026-11-05T20:35:15.821Z
- Integrations: AWS, Tenable
- Domains: vulnerability-management
- Tags: vuln-management, exposure-management, remediation, change-management, human-in-the-loop, verification, claude-code
- Date added: 2026-08-05
- Playbook type: standard
- Agent chain:
  1. Chokepoint Finder (exchange: agents/chokepoint-finder), Carries the loop end to end: collapses findings into shared fixes, ranks them, gates unsafe targets, and holds no external write tools.
  2. Chokepoint Finder MCP Server (exchange: mcp-servers/chokepoint-finder-mcp), Provides the typed tools the chain binds to: ingest, rank, pre-flight, plan hashing, execution accounting and verification.
  3. Chokepoint Finder Skill (exchange: skills/chokepoint-finder-skill), The portable, dependency-free form of the same ranking method, for operators who run the chain without the MCP server.
  4. Community MCP Server for Tenable (exchange: mcp-servers/tenable-mcp-server), Read-only collection of findings and asset context, and the authoritative re-scan the verification stage diffs against.
  5. AWS MCP Server (Agent Toolkit for AWS) (info: https://docs.aws.amazon.com/agent-toolkit/latest/userguide/mcp-server.html), Read-only cloud posture collection, and the execution path for approved cloud changes under the operator's own credentials.
- Listing page: https://exchange.tenable.com/playbooks/chokepoint-remediation-playbook
- Source file: https://github.com/tenable/cyberagents-exchange/blob/main/playbooks/chokepoint-remediation-playbook.md

The operating chain that turns the Chokepoint Finder method into something a team can
actually run on a Monday: eight stages with explicit owners, explicit handoffs, and a
human checkpoint in the middle that cannot be skipped.

## What it does

Gather read-only, collapse findings into the fixes they share, rank by marginal risk,
gate on evidence, **stop for a human**, execute through the operator's own tools in
per-site waves, hand intel to SOC and threat hunt, then prove the risk moved with a
re-scan before the change record closes — and repeat on a schedule.

Every external mutation along the way takes its own explicit approval. Not just the
infrastructure change: opening the change ticket, notifying a SOC or opening a hunt
ticket, and launching the verification scan each count as mutations and each require
their own yes. The playbook holds no credentials, no collectors, and no write path of
its own.

## How it works

The chain is defined once, machine-readably, in `stages.yaml`: each stage's capability,
who provides it, whether that provider is read-only or write, and where approvals bind.
The prose playbook and the runnable slash command are both **validated against that
file** rather than trusted to stay in sync — the validator asserts that both documents
contain exactly the stages of `stages.yaml` in order under the same titles, that every
named provider exists in the component registry and is classified read-only or write,
that every referenced MCP tool is one the server actually ships, and that every mutating
stage declares human approval with matching approval language in the text. The test
suite proves those checks have teeth by injecting drift — a dropped stage, a renamed
tool, a stripped approval — and asserting validation fails.

A bundled offline state-machine runner enforces the receipt contract without calling any
live system. It refuses skipped stages, pre-gate or altered manifests, widened target
sets, replayed or stale or mismatched approvals, later waves before proof, mismatched
source scopes, rescan-digest drift, and simulated evidence offered as closure. Refused
transitions are transactional: they consume no receipt and leave no partial state.

Stage owners are deliberately swappable — a different scanner, ticketing system or patch
platform slots in — because the interfaces are expressed as capabilities rather than
products. The repository is explicit about the boundary of what the runner can prove: it
validates receipt structure and consistency, but it does not authenticate the claimed
human identity and cannot attest that a dishonest connected tool behaved as its receipt
says. Approval identity is therefore only as strong as the system that issues and
transports the operator receipt.

This is the Markdown version of one of 140 listings on CyberAgents Exchange. The same listing as JSON: https://exchange.tenable.com/api/playbooks/chokepoint-remediation-playbook.json. The full index and how to read it: https://exchange.tenable.com/llms.txt