Recoverability becomes a first-class pre-execution control, not a post-incident lesson.
Why It Matters
Authorization alone does not answer recoverability.
A technically authorized action can still be dangerous if it has poor rollback, broad blast radius, weak evidence, irreversible external side effects, or no safe fallback path.
SMERC can throttle, freeze, or escalate instead of forcing a blunt allow/deny decision.
Each serious decision can preserve why the action was routed and what controls were required.
SMERC is meant to work with existing security, policy, gateway, and review systems.
Where To Use It
High-impact automated actions
- AI agents calling tools or APIs.
- MCP tool calls with meaningful side effects.
- GitHub Actions and AI-assisted deployment workflows.
- Cloud administration, IAM, Kubernetes, database, DNS, and infrastructure changes.
- Financial actions involving payment, refund, treasury, stablecoin, wallet-policy, or reserve-status workflows.
How To Review SMERC
Start with public proof, then customer-owned metadata
Reviewers should run the public proof path first, then replace the examples with 5 to 25 safe metadata-only actions from one real workflow. That is the clean test of whether recoverability changes judgment.