Public Review

Help pressure-test the recoverability checkpoint

SMERC is looking for practical critique from CISOs, security architects, platform engineers, AI governance teams, Microsoft ecosystem builders, agent-framework developers, and researchers.

ALLOW THROTTLE FREEZE DENY ESCALATE
CISO review Submission kit Status GitHub Actions pilot Pilot options Visibility Live demo

Core Question

Allowed is not the same as recoverable

Most authorization systems ask whether an actor or workflow is permitted. SMERC asks a second question before execution: if this action is wrong, unstable, or poorly evidenced, can the organization recover without unacceptable damage?

The project is pilot-grade and intentionally open to challenge. The current goal is not broad adoption. The goal is better evidence from security and platform teams who understand real execution boundaries.

Leave public review feedback Open GitHub repo Review guide Submission kit Developer quickstart Engine trace guide

Useful Feedback

Questions reviewers can answer

  • Is recoverability scoring a real gap in current AI-agent governance?
  • Where would this fit or fail in existing approval workflows?
  • Which actions should be constrained instead of fully blocked?
  • Which signals are missing from reversibility, containment, rollback latency, evidence, anomaly pressure, and impact scope?
  • What evidence would make a shadow-mode pilot credible?

Post Anywhere

Short community post

I am looking for technical feedback on SMERC, a recoverability checkpoint before AI-agent, security, cloud, and automation actions execute. SMERC sits after detection, identity, and policy but before execution, then returns ALLOW, THROTTLE, FREEZE, DENY, or ESCALATE based on recoverability signals. The question is not only whether the actor is allowed. The question is whether the proposed action is recoverable enough to execute now.

Useful critique: where this fits, where it fails, what evidence is missing, and whether a GitHub Actions shadow-mode pilot is credible.