Access Revocation Pass¶
Procedure — instantiates Graph Pruning
Sweeps the access graph on a schedule or trigger, revoking stale, orphaned, and unjustified permission edges while preserving legitimate and emergency reachability.
An Access Revocation Pass takes the whole standing set of permission edges at once and asks, of each grant, whether anything still justifies its existence — then revokes the ones that don't. Its defining move is that it reasons from the edges outward: it hunts for grants that have outlived their reason (a departed employee's account, an orphaned service principal, an "temporary" elevation from a year ago, a login that hasn't fired in months) rather than starting from a job description and asking what that role ought to have. It is a broad, repeated sweep of the existing grant graph, run on a cadence or fired by an event, whose product is a batch of revocations plus a fast way to undo any that turn out to matter.
Example¶
A payments company runs quarterly Access Revocation Passes across its cloud environment after a reorganization and a round of departures. The identity platform holds roughly four thousand principals — human users, roles, and service accounts — accreted over years. The pass pulls the authoritative grant inventory and joins it against two signals: usage telemetry (has this principal made an API call or logged in during the last 90 days?) and the HR roster (does this human still work here?). Out fall the candidates: two dozen accounts for people who left, a cluster of service accounts nobody can name, and a set of admin roles granted "just for the migration" long ago.
Before cutting, the pass honors a protected list: a documented break-glass admin role and the on-call escalation paths stay, even though they look idle by design. It revokes the rest. Two revocations promptly break a nightly batch job whose service account looked dormant — the rollback path re-grants within the hour, and that edge is tagged so the next pass won't flag it again. The outcome is a materially smaller standing-privilege footprint and a shrunken attack surface, bought without a per-person entitlement audit.
How it works¶
The pass is a bulk operation, not a case-by-case judgment:
- Pull the authoritative grant ledger from the identity provider or platform, so the sweep sees every edge that actually exists, not a stale spreadsheet.
- Join against liveness signals — usage telemetry plus a source of truth for who/what is still legitimate (roster, service catalog). The intersection of "granted" and "no longer justified" is the candidate set.
- Revoke by default, protect by exception. Everything on the candidate list is cut unless it sits behind the protected-reachability list.
- Keep rollback armed and cheap, because liveness signals lie about rarely-used-but-critical edges; a re-grant must be minutes, not a change ticket.
Tuning parameters¶
- Staleness window — how long an edge must be idle to qualify (30 vs 180 days). Shorter catches more but revokes more false positives; longer is safer but leaves privilege standing.
- Trigger — scheduled cadence vs event-driven (offboarding, role change, security incident). Event triggers react faster; scheduled passes guarantee eventual coverage.
- Revocation mode — disable-then-delete vs immediate delete. Disabling first makes rollback trivial at the cost of leaving a dormant husk to clean up later.
- Protected-list breadth — how much is fenced off from the sweep. Too narrow risks cutting break-glass; too broad lets privilege hide inside the exception.
- Blast-radius batching — how many edges are cut per wave. Small batches localize damage from a bad revocation.
When it helps, and when it misleads¶
Its strength is that it directly attacks privilege creep[n1]: the quiet accumulation of access that no single decision ever authorized. A recurring sweep keeps standing privilege proportional to reality and finds the orphaned accounts that per-role reviews never look at, because no owner remains to review them.
Its central failure mode is that idle is not the same as unneeded. The edges most dangerous to cut are exactly the ones that look most cuttable: the disaster-recovery account used once a year, the break-glass role that is idle by design, the integration a quarterly job depends on. Ranking purely on login recency will happily revoke the account you most need in an emergency, and an over-eager sweep can lock people out faster than the help desk can react. The discipline that keeps it honest is the protected-reachability list plus a rollback path fast enough that a wrong cut is an inconvenience, not an outage — and running the first waves in disable mode so nothing is truly gone until it has survived a full business cycle.
How it implements the components¶
edge_inventory— the authoritative ledger of every permission edge, pulled fresh each pass so the sweep acts on what exists now.edge_criteria— the staleness-and-orphaning test (no recent use, no matching identity, expired justification) that separates cuttable grants from live ones.pruning_rule— revoke-by-default for candidates, subject to the protected list; the rule that actually executes the removal in bulk.protected_connectivity_invariant— the fenced set (break-glass, emergency escalation, legitimate rare-use accounts) that must survive every sweep.rollback_path— the fast re-grant that lets the pass act decisively despite imperfect liveness signals.
It does not implement impact_analysis, accountable_pruning_owner, or appeal_or_reinstatement_path — the per-actor need analysis, owner attestation, and reinstatement channel belong to Least-Privilege Review, which decides which grants are surplus while this pass executes the removal of stale ones.
Related¶
- Instantiates: Graph Pruning — the access-graph sweep is one domain instantiation of principled edge removal under protected invariants.
- Consumes: Least-Privilege Review — surplus grants that a review flags are one input this pass can execute against.
- Sibling mechanisms: Least-Privilege Review · Channel Consolidation · Unsubscribe / Filtering · Dependency Pruning Workflow · Integration Decommissioning Runbook · Link Decommissioning Plan · Relationship Cleanup Review · Stale Edge Expiration · Graph Sparsification Pass
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: The mechanism performs a bulk pruning operation on the live access graph, removing stale, orphaned, and unjustified permission edges while protecting essential reachability, so its operative form is a direct target-changing intervention.
Nearest alternative: Protocol, Workflow & Routine — Ledger collection, liveness joins, and rollback form a supporting sequence; the defining result is the actual removal of unjustified access edges from the target configuration.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Identity-provider grant graphs, service principals, usage telemetry, bulk revocation, protected break-glass paths, and rapid re-grant are information-security and software-operations mechanisms.
Related originating lineages:
- Accounting & Auditing — Periodic entitlement cleanup and evidence that privileges remain justified derive from internal-control and access-review practice.
- Security Studies & Intelligence Analysis — Shrinking standing privilege and attack surface in response to stale or orphaned identities is a security-risk objective.
Review resolution: The identity-and-access-management operation is a direct computing practice, with auditing and security as convergent control lineages; the page generalizes that established operation without constructing a new cross-disciplinary procedure.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Privilege creep — the gradual accumulation of access rights beyond current need as people change roles, take on temporary tasks, and inherit permissions that are never revoked. It is the standing-privilege problem an access sweep exists to reverse. ↩