Skip to main content

Revocation Rehearsal

Shipped in: sv0-platform PR #1533 (2026-06, merge b2576c2c)

What It Does​

Every access review ends at the same question: approve or revoke? Reviewers approve almost everything because nobody can answer "what breaks if you revoke this access?"

Revocation Rehearsal answers that question before anyone acts. It runs a deterministic dry-run against the already-scanned graph: it masks the role grant you are considering revoking (the identity's HAS_ROLE edge), recomputes every access path with the grant removed, and diffs the result against the baseline. Same inputs produce a byte-identical verdict. The rehearsal is read-only end to end — zero writes to the customer's systems and zero writes to the platform's own database.

What the Verdict Contains​

Verdict sectionWhat it tells you
breakage_coneThe access paths that would be lost — for each: the workload or identity affected, the resource it reaches, the roles and actions involved, and the source systems the path traverses (including cross-system chains)
Classification per lost pathWOULD_BREAK — an execution path with observed execution evidence in the window would be lost, backed by the actual evidence rows (action, target resource, timestamp, execution count). The alternative classification is No observed use (90d window) — no execution was observed for that path in the evidence window; absence of observed use is not proof that nothing depends on it
redundancyParallel-path detection — surviving paths that still reach the same resource after the revocation. A revocation that closes nothing gets caught before it happens, not after
findings_underminedWhich open findings this revocation would affect (the rehearsal itself closes nothing — it shows what would change)
coverage_statementExplicit honesty caveats included in every verdict: scope limits, evidence blind spots, key-based-access caveats
totalsHeadline numbers: baseline paths, masked paths, lost paths, surviving parallel paths, entities recomputed

Every verdict is anchored on a frozen as_of clock (the data snapshot time, never "now") with a 90-day evidence lookback window by default.

Where You Use It​

  • UI — the Rehearse revocation panel on finding detail pages, for identities that hold role assignments. Pick the role; the verdict renders inline.
  • API — GET /api/v1/rehearsal/revocation?identity_id=&role_id= returns the full verdict as JSON, or a downloadable Markdown report with format=md. See API Layer — Revocation Rehearsal.
  • CLI — scripts/rehearse-revocation.ts (sv0-platform) runs the same engine against a tenant snapshot and writes verdict.json + report.md. The CLI and the API format=md share the same renderer, so the Markdown report is byte-identical for the same verdict.

How It's Enabled​

Revocation Rehearsal is gated by a per-tenant feature flag (feature_flags.rehearsal_enabled on the tenant config) and is off by default for every tenant, including new ones. A super-admin opts a specific tenant in via the admin API. The flag is enforced server-side — the API returns 403 FEATURE_DISABLED until the flag is set, and the UI hides the panel entirely. Enable/disable steps are in the platform runbook linked below.

Honest Limits​

  • Scope: role-grant paths only — the rehearsal masks HAS_ROLE edges. Credential/key-based and unmodeled access are not assessed; revoking a role does not remove API-key access, and the verdict carries a per-resource caveat where that applies.
  • No observed use is not proof of absence of use — the evidence window covers observed execution. A disaster-recovery role or an annual job can escape a 90-day window. The coverage_statement in every verdict says exactly this.
  • The rehearsal predicts, it does not act — nothing is revoked, and no finding changes state.