Permission Scope or Capability Token¶
Software or tool — instantiates Declared Effect Boundary Enforcement
Grants an action narrowly scoped authority to touch only declared resources.
Permission Scope or Capability Token binds an action's authority to specific state surfaces, so that even if its code tries to touch something outside its grant, the attempt is refused at the boundary. Its defining trait is that it governs who or what may touch which surface, not whether the touch is well-formed, consistent, or recorded. A capability token is a credential that carries exactly the authority it names and nothing more; the write path checks it and denies everything not granted. This turns the effect boundary from a promise into an enforced fact for the authorization dimension: an unscoped surface is unreachable, by default, regardless of what the action intends.
Example¶
A cloud-automation agent is asked to update a deployment configuration. It runs under a capability token scoped to a single authority: write — deployment-configs in project X. Nothing else. Mid-task, a buggy code path attempts to also delete a storage bucket in the same project. The call reaches the control plane, the token is checked, and the delete is rejected — the authority to touch storage was never in the grant, so the blast radius of the bug is bounded to configs it was actually trusted with.
Later, a genuine one-off need arises: an operator must let the agent touch a second surface for a migration. Rather than widening the standing token, the operator issues a time-boxed elevated token that grants the extra authority, is recorded, and expires automatically in an hour. The exception is explicit, scoped, and self-revoking, instead of a permanent widening that everyone forgets to walk back.
How it works¶
- Authority bound to surfaces. A scope names specific resources, not broad roles like "admin," so the grant maps to meaningful state surfaces rather than a job title.
- Checked at the write path. The mutation channel verifies the presented token before any change, and refuses anything the token does not explicitly authorize.
- Deny by default. Absence of a grant is a refusal, not a gap, so a surface no one scoped stays untouchable.
- Exceptions as scoped grants. Legitimate deviations are handled by issuing narrow, time-boxed, revocable tokens — an explicit, expiring authority rather than a standing widening.
Tuning parameters¶
- Scope granularity — authority per specific resource versus per broad role. Fine scopes shrink blast radius but multiply tokens to manage.
- Token lifetime — long-lived credentials versus short-lived, frequently rotated ones. Short lifetimes limit damage from a leaked token but demand renewal machinery.
- Default strictness — how hard the deny-by-default line is held before convenience grants creep in.
- Exception TTL — how long an elevated token lives before it self-revokes; shorter is safer but interrupts long legitimate tasks.
When it helps, and when it misleads¶
Its strength is a hard, enforced cap on blast radius: an unauthorized surface stays untouched even when the acting code is buggy, compromised, or an over-eager automated agent.[1]
Its failure mode is scope sprawl — the operational burden of fine grants pushes people toward broad "admin" tokens that technically satisfy the check while erasing the boundary it was meant to draw, and stale scopes accumulate authority no one still needs. The guarding discipline is to map scopes to meaningful state surfaces rather than convenient roles, and to review grants for staleness so authority does not quietly widen back to ambient.
How it implements the components¶
mutation_gateway— it furnishes the authorization check the write path applies, making the gateway refuse any change the presented scope does not cover.exception_authorization_rule— deviations from the ordinary boundary are handled as explicit, time-boxed, revocable elevated tokens rather than permanent widenings.
It does NOT implement protected_invariant_set or effect_observability_record — a token bounds who may touch a surface, not whether the resulting change keeps invariants or gets recorded; those are Transaction Boundary and Audit Log and Trace.
Related¶
- Instantiates: Declared Effect Boundary Enforcement — enforces the authorization dimension of the boundary, so unscoped surfaces are unreachable.
- Consumes: Effect Contract Annotation supplies the declared surfaces that scopes are cut to match.
- Sibling mechanisms: Audit Log and Trace · Command–Query Separation · Compensating Action Protocol · Effect Contract Annotation · Effect Review Checklist · Immutable Data or Copy-on-Write · Sandbox or Staging Execution · State Diff Test · Transaction Boundary
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: The mechanism installs a capability-based authority boundary that binds a token to declared resources and denies all unscopeable surfaces by default.
Nearest alternative: Control, Automation & Runtime — Write-path checks enforce grants during operation, but they implement the enduring scoped-authority architecture.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Permission Scope or Capability Token is rooted in computer science and software engineering: Capability-security systems embody least privilege in unforgeable, resource-scoped authority tokens.
Review outcome: Independent reviewer agreement; high confidence.
References¶
[1] The principle of least privilege (Jerome Saltzer and Michael Schroeder, 1975) holds that every action should operate with the minimum authority its task requires. A capability token is the concrete instrument of that principle: authority is exactly what the token names, and nothing else is reachable. withdrawn registry ↩