A gate that only logs what proceeded cannot be evaluated — you never learn whether the stops were right, so the threshold never improves and nobody can tell whether it is over-blocking. Asking for observe after a refusal closes that loop. Separating reversibility from severity is the other correct distinction: deleting a row you can restore and sending an email you cannot recall are different problems, and collapsing them into one score loses exactly the information a caller needs. Two tools, one job, and the honest cost is a few seconds of latency in front of every guarded action.
A guardrail for agent actions reduced to a before-and-after pair: call forecast ahead of anything irreversible, and observe afterwards including when the recommendation was to stop.
- forecast returns a numeric risk score, a reversibility class, a go, caution or stop recommendation, and named red flags rather than a single verdict.
- The reversibility class is the useful part: a high-risk reversible action and a low-risk permanent one need different handling, and one number cannot say that.
- observe is called after the action runs — and its description explicitly includes the case where the action was not run because the recommendation said stop, so the refusals are recorded too.
- The README names the categories it is aimed at: sending email, moving money, running SQL, deleting data, posting content.
BLACKWALL_API_KEY. Each forecast is an outbound call, so it adds latency in front of the action it guards.
One command plus a key — claude mcp add blackwall -e BLACKWALL_API_KEY=bw_live_your_key_here -- npx -y blackwall-mcp, then supply credentials