Permission-Scoped Default¶
Access-control configuration — instantiates Misuse-Resistant Affordance Design
Ships every capability disabled or narrowly scoped by role, so powerful actions are reachable only by the users whose work actually needs them.
A permission-scoped default shapes who can reach a dangerous capability, not what value a setting holds. It ships every powerful action off or narrowly bound to a role, so the capability is simply absent from the action space of anyone whose job does not require it — and present only for those it does. Its defining idea is least privilege as the starting posture: rather than granting broadly and clawing back after abuse, it grants the minimum and widens only on demonstrated need. Where a general "safe default" concerns the initial value an ordinary user lands on, a permission-scoped default concerns the initial reach each role is granted — a distinction between the state of a setting and the standing of an actor.
Example¶
A company runs its infrastructure in a cloud account, and the most dangerous action available is "delete a production database." Under a permissive posture, every engineer's login carries broad administrative rights "so nobody is ever blocked," and the delete button sits one misclick or one phished credential away for hundreds of people. A permission-scoped default inverts this. New engineers are provisioned into a role that can read production and deploy to staging, and nothing else. The delete-production capability lives in a separate role held by a handful of on-call operators; reaching it requires an explicit, logged elevation for a bounded window.
So when an attacker phishes an ordinary engineer's credentials, the stolen login cannot delete the database — that capability was never in its scope. The blast radius of any single compromised or careless account is bounded by what that role was scoped to touch, which for the vast majority of accounts is nowhere near the destructive action. The legitimate on-call operator still does the work; the capability simply isn't lying around under everyone else's cursor.
How it works¶
- Model roles from real work. Enumerate what each role legitimately needs to do, and grant exactly that — the scope is derived from the job, not from convenience.
- Default to the floor, elevate on demand. Every capability starts off or read-only; access to a powerful action is a deliberate, time-bounded, logged elevation rather than a standing grant.
- Reason from the compromised account. Assume any single credential may be stolen or turned, and scope so that its reach is survivably small — the blast radius, not the honest user, sets the boundary.
- Separate duties. Split capabilities that are dangerous in combination across distinct roles so no single account can complete a harmful sequence alone.
Tuning parameters¶
- Scope granularity — coarse role buckets versus fine per-action grants. Finer scoping shrinks blast radius but multiplies administrative overhead and can strand people mid-task.
- Elevation friction — how hard it is to step up to a powerful role (self-service, peer approval, break-glass). More friction resists abuse and compromise but slows legitimate urgent work.
- Grant duration — standing membership versus just-in-time, time-boxed elevation. Ephemeral grants shrink the standing attack surface but require reliable re-request.
- Separation-of-duties depth — how many dangerous capabilities are split across roles. Deeper separation blocks solo abuse but can make routine coordinated work cumbersome.
- Default deny vs. default read — whether an unscoped account gets nothing or safe read-only. The latter is friendlier; the former is stricter.
When it helps, and when it misleads¶
Its strength is that it bounds the damage of the failures you cannot prevent — the phished credential, the disgruntled insider, the honest fat-finger — by ensuring most actors never held the dangerous capability in the first place. This is the principle of least privilege[1], and it is the cheapest large reduction in blast radius available to most systems.
Its failure mode is privilege creep masquerading as smooth operation: when elevation is annoying and grants are permanent, roles slowly accrete permissions "just in case," and after a year everyone is an admin again — the scoped default having quietly decayed into the permissive one it replaced. The classic misuse is scoping on paper while operating on exceptions, so the audit shows tidy roles while daily work runs on standing elevated access nobody revokes. The guarding discipline is to expire grants by default and re-earn them, and to audit effective access — what accounts can actually do today — rather than the role definitions as designed.
How it implements the components¶
default_state_and_permission_posture— it sets the permission side of the posture: capabilities ship scoped-to-role and least-privilege by default, so reach is granted deliberately rather than assumed.adversary_or_opportunist_model— scoping is derived by reasoning from the compromised or turned account: the boundary is drawn so that any single stolen credential's reach stays survivably small.legitimate_use_model— each role's scope is built from an explicit account of what that job legitimately needs to do, so the floor is set by real work rather than by guesswork.
It does not set the safe initial *value of an ordinary setting or its asymmetric_affordance_map and legitimate_path_preservation_criterion — that is Safe Default Setting, its nearest twin; a permission-scoped default gates who may act, while a safe default setting gates what value a setting starts at.*
Related¶
- Instantiates: Misuse-Resistant Affordance Design — it removes dangerous capabilities from most actors' action space by scoping reach to role.
- Consumes: Exception Review Queue adjudicates the elevation requests that widen a role's scope.
- Sibling mechanisms: Safe Default Setting · Constrained Input Control · Exception Review Queue · Misuse Monitoring Dashboard · Physical Keying or Interlock · Point-of-Action Confirmation · Progressive Disclosure of Risky Options · Rate Limit or Cooling Hold
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Permission-Scoped Default operates as a configured physical, technical, or logical arrangement whose structure creates the effect because it ships every capability disabled or narrowly scoped by role, so powerful actions are reachable only by the users whose work actually needs them.
Independent corroboration: The frozen evidence defines Permission-Scoped Default as 'Ships every capability disabled or narrowly scoped by role, so powerful actions are reachable only by the users whose work actually needs them', so its operative form is Structure, Architecture & Configuration.
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: Permission-Scoped Default is rooted in computer science and software engineering: Secure-by-default design starts capabilities disabled or narrowly role-scoped under least privilege.
Related originating lineages:
- Human-Computer Interaction — Human-computer interaction materially shaped Permission-Scoped Default through affordances, usability, personas, and interaction design. Misuse-resistant interface design materially shaped how role-scoped capabilities are exposed and enabled.
Review resolution: Both blind reviewers agree that computer science and software engineering is the primary origin. Reconciliation resolves origin_mode_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement. Formative alternate lineages are retained as human_computer_interaction; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The principle of least privilege (Saltzer & Schroeder, 1975) holds that every actor should operate with the minimum access its legitimate function requires, and no more — so that the damage from error, compromise, or abuse is bounded by that minimum. withdrawn registry ↩