Least-Privilege Review¶
Governance review — instantiates Graph Pruning
Compares each actor's held permissions against what their current role actually needs, and flags the surplus so access matches necessity.
A Least-Privilege Review reasons from role necessity downward: for each actor it asks "what does this job actually require?", compares that baseline to what the actor holds, and treats the gap — everything held beyond need — as the pruning candidate. Its defining idea is the entitlement-versus-need comparison, attested by someone accountable for that role. It is a governance review, not an execution engine: it produces a justified recommendation of what to strip, backed by an owner's sign-off and an appeal channel for the person affected, rather than reaching into the system and cutting. Where a staleness sweep asks "has this been used?", this review asks the sharper and more political question "should this ever have been granted for this role?"
Example¶
A hospital runs a Least-Privilege Review of clinical access in its electronic health record system, one role at a time. A nurse who transferred from the ICU to an outpatient clinic six months ago still carries ICU order-entry rights and a pharmacy override — legitimate in her old post, unnecessary in her new one. The review lists each clinician's active entitlements beside a role-need baseline defined with the department heads, who act as accountable owners for what their roles should hold. For each surplus entitlement it runs a lightweight impact check: would removing ICU access break any legitimate duty? For a float-pool nurse who genuinely cross-covers, yes — so that access stays. For the transferred nurse, no.
The review flags the surplus for removal and records the owner's attestation. Because "need" is sometimes contested, an affected clinician can appeal — if her actual duties require a retained right, she requests reinstatement through a defined path rather than quietly reacquiring it through a workaround. The output is a set of entitlement recommendations aligned to current roles, ready for execution.
How it works¶
- Define the role-need baseline. For each role or task, state the minimum entitlement set it requires — the reference against which holdings are judged.
- Enumerate held versus needed. List what each actor actually has and subtract the baseline; the remainder is the surplus.
- Impact-check each cut. For surplus that might be load-bearing (cross-cover, dual roles), verify removal breaks nothing legitimate before flagging it.
- Attest and open appeal. The accountable owner signs off on the baseline and the cuts; affected actors can contest a removal through the reinstatement path.
The review stops at a justified recommendation; a separate mechanism performs the revocation.
Tuning parameters¶
- Baseline granularity — per-role, per-task, or per-attribute. Finer baselines enforce tighter least privilege but multiply the modeling effort.
- Need-definition source — manager attestation, policy, or observed activity. Attestation captures intent; activity captures reality; the two disagree often.
- Review cadence — joiner/mover/leaver events vs periodic recertification. Event-driven catches role changes at the moment; periodic catches drift.
- Appeal strictness — how much evidence an actor must supply to reinstate a right. Loose appeal restores access fast but reopens over-provisioning.
When it helps, and when it misleads¶
Its strength is that it enforces the principle of least privilege[1] proactively: it shrinks the blast radius of any compromised or misused account by ensuring no actor carries more reach than their role warrants, and it catches over-grants that a usage-based sweep misses because the surplus access is being used — just beyond what the role should allow.
Its failure modes are baseline error and attestation theater. Role baselines drift, are drawn too tight, or encode politics rather than need; a baseline set too lean blocks legitimate cross-cover and pushes people toward shared logins and workarounds that are worse than the surplus removed. And the review collapses into rubber-stamping when owners approve everything to avoid friction. The discipline that keeps it honest is independent verification of a sample of baselines and attestations, plus a real appeal path so that a wrongly-stripped right is restored openly rather than routed around.
How it implements the components¶
edge_criteria— the role-need test: an entitlement survives only if the current role requires it, which is a different discriminator than staleness.impact_analysis— the per-actor check that removing a surplus right breaks no legitimate duty before it is flagged.accountable_pruning_owner— the role or department owner who defines the baseline and attests to each cut, giving the review authority and traceability.appeal_or_reinstatement_path— the defined channel by which an affected actor contests a removal or requests a right back.
It does not implement pruning_rule or rollback_path — the actual bulk revocation and fast re-grant belong to Access Revocation Pass; this review recommends which grants are surplus, and the pass executes the removal.
Related¶
- Instantiates: Graph Pruning — least-privilege is edge criteria applied to the access graph, framed around role necessity.
- Sibling mechanisms: Access Revocation Pass · 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: Assessment, Review & Assurance
Rationale: Least-Privilege Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it compares each actor's held permissions against what their current role actually needs, and flags the surplus so access matches necessity
Independent corroboration: The frozen evidence defines Least-Privilege Review as 'Compares each actor's held permissions against what their current role actually needs, and flags the surplus so access matches necessity', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Need-to-know security is a formative parallel, but least privilege was canonically formulated as a computer-system protection design principle; entitlement review operationalizes it.
Related originating lineages:
- Law & Governance — Administrative due-process practice contributed authorization, accountability, and documented exception review.
- Organizational & Management Science — Identity governance and role design materially shape what duties require and who certifies surplus access.
- Security Studies & Intelligence Analysis — Need-to-know and compartmentation traditions materially shaped privilege minimization.
Review resolution: Need-to-know security is a formative parallel, but least privilege was canonically formulated as a computer-system protection design principle; entitlement review operationalizes it. The source supports the selected provenance; the retained alternates record documented formative or independently established lineages, not downstream applicability alone. origin_mode=cross_disciplinary_synthesis because the mechanism joins contributions across those traditions. domain_reach=multi_domain records application breadth separately from origin.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://web.cs.wpi.edu/~cs557/f14/papers/saltzer1975_alt.html — Saltzer and Schroeder's foundational computer-security paper stating the principle of least privilege and its audit rationale.
References¶
[1] The principle of least privilege — Saltzer and Schroeder, "The Protection of Information in Computer Systems" (1975): every user and program should operate with the smallest set of privileges needed to complete its task, so that error or compromise reaches as little as possible. registry ↩