Codex 0 · Chapter 08 — Permissions

This chapter specifies the role and scope model, the security-definer enforcement pattern, elevation, delegation, consent-derived access, and review cadence that govern who may see or change what.

08.0 Purpose

Chapter 04 states, for every user type, what they see, own, and never see. This chapter states the mechanism that makes each "never sees" actually hold: deny-by-default, server-side, at the data layer, regardless of who is asking or how senior they are.

08.1 Scope and non-scope

08.1.1 This chapter governs the role and scope model, the has_role enforcement pattern, elevation with logged reason, service and agent identities, delegation, consent-derived access, and review and revocation cadence.

08.1.2 This chapter does not define user types (Chapter 04) or the shape of the Role entity (Chapter 07 §07.9); it defines how that entity is checked and enforced.

08.1.3 This chapter does not govern API contract versioning (Codex 5); it governs what a call, however versioned, is permitted to do.

08.2 Deny-by-default

08.2.1 Every table, function, and endpoint starts closed. A capability is granted explicitly; nothing is reachable by omission.

08.2.2 A new surface, table, or endpoint that ships without an explicit access decision is a defect, not a permissive default: the safe failure mode is "denied until specified," never "open until restricted."

08.2.3 Permissions are enforced server-side and at the data layer, in that order of redundancy: an authorization check in application code is necessary but not sufficient; row-level policy at the database enforces the same rule independently, so a bug in one layer does not become a breach.

08.2.4 A hidden UI element, a client-side route guard, or a greyed-out button is never a permission. It is, at most, a courtesy that must agree with what the server would independently refuse (Chapter 04 §04.2.2).

08.3 The scope model

08.3.1 A Role grant (Chapter 07 §07.9) is meaningless without a scope. Every grant states the boundary of what it authorises:

individual      one person's own record
cohort          one time-bound group moving through curriculum together
organization    one company, university, government body, or partner
division        one of the institution's operating divisions
institution     the whole institution, granted only where a role's function requires it

08.3.2 Scope is checked alongside role on every request: holding a role name without the matching scope reference grants nothing. "Faculty" scoped to Cohort A grants no visibility into Cohort B.

08.3.3 A grant at a broader scope is never inferred from grants at narrower scopes; an institution-wide grant is issued explicitly, never accumulated implicitly by holding many organization-scoped grants.

08.3.4 Scope references resolve to a concrete Organization, Cohort, or division identifier (Chapter 07 §07.9); "institution" scope carries no reference, because it is not bounded by one.

08.3.5 Seniority, employment, and administration are not scopes. An executive's title, an employee's tenure, and an administrator's console access grant nothing by themselves (Chapter 04 §04.4.16, §04.4.18). Every access an executive, employee, or administrator exercises traces to a named Role grant with a stated scope, exactly like any other person's.

08.4 The `has_role` pattern

08.4.1 Authorization is checked through a single, audited function pattern — has_role(person, role, scope) — rather than ad hoc conditionals scattered across application code and policy definitions. One pattern, consistently applied, is what makes a permission model reviewable at all.

08.4.2 The function is security definer: it runs with the privilege needed to read the Role table regardless of the calling context's own row-level restrictions, so that a caller cannot be granted access merely by virtue of being allowed to query the permissions table directly. Only the function's narrow, tested logic decides the answer.

08.4.3 Row-level security policies on every member-data table call this same function; a policy never re-implements its own bespoke role check. One definition of "may this person see this row," checked everywhere the same way.

08.4.4 has_role never trusts a client-supplied role or scope claim. It re-derives the answer from the Role table on every call; a token or session may carry a cached hint for UI purposes, but the enforcement path always re-checks.

08.4.5 A failed or inconclusive check (an unavailable dependency, an ambiguous scope resolution) returns denied, never granted (Chapter 05 §05.5.5's fail-closed rule applied at the permission layer).

08.5 Separation of duties

08.5.1 Where a single person holding two roles could create an unreviewed self-authorization (authoring a credential standard and being the sole issuer against it, granting themselves an elevation and being the sole approver of it), the roles are split so that a second, distinct role must act.

08.5.2 Chapter 04 names the standing instances of this rule (credential authorship versus issuance, §04.4.5; review versus assessment, §04.4.6). New workflows are checked against this rule before they are proposed (Codex 0 §01.4.3's Registry Test).

08.5.3 A service or agent identity is never the second party in a separation-of-duties pair; the second party is always a distinct, named human role.

08.6 Elevation

08.6.1 Elevated access — a steward, administrator, or engineer reading member content outside their standing scope — requires a stated reason, recorded before or at the moment of access, never retrospectively reconstructed.

08.6.2 Every elevation produces an AuditRecord (Chapter 07 §07.23), readable by the subject of the access under their own data rights (Chapter 04 §04.8.5). An elevation the subject cannot eventually see is not a permitted design.

08.6.3 Elevation is time-bounded. An elevated grant carries an expiry; there is no standing elevated access, only repeated, individually justified elevations.

08.6.4 Administering access is not authorisation to read what it grants (Chapter 04 §04.4.18): the administrator role that creates or revokes a Role grant does not thereby gain the visibility that grant confers. Reading member content still requires the administrator's own, separately justified elevation.

08.6.5 An elevation reason that is generic, boilerplate, or reused verbatim across unrelated accesses is treated as an unstated reason and is a defect flagged at review (§08.9).

08.7 Delegation

08.7.1 Delegation is a time-bounded transfer of a specific scoped grant from one person to another — covering absence, a temporary assignment, or a handover — never a permanent broadening of either party's standing access.

08.7.2 A delegated grant expires automatically at its stated end and is never renewed silently; renewal is a new, explicit delegation with its own record.

08.7.3 A delegated grant is visible, on request, to the delegator, the delegate, and the subject whose data the grant reaches, consistent with the transparency owed under §08.6.2.

08.7.4 Delegation never crosses a separation-of-duties boundary (§08.5): a delegate cannot receive both halves of a split pair through delegation from two different holders.

08.8 Consent-derived access

08.8.1 Some access exists only because a person consented to share their record with a specific other party for a specific purpose — a mentee sharing progress with a mentor, a scholar sharing a submission for review, a member consenting to enterprise reporting (Chapter 04 §04.7).

08.8.2 Consent-derived access is scoped exactly to what was consented to, expires or is revocable exactly as the consent is, and is never broadened by the receiving party's other roles. A mentor with an institution-wide reporting role does not gain a mentee's data through that role; they gain it only through the mentee's consent (Chapter 04 §04.4.4).

08.8.3 An Organization's agreement with the institution — an enterprise contract, a partner MOU — cannot itself constitute an individual's consent to disclosure of their individual record (Chapter 04 §04.7.5, §04.12.6). Aggregate reporting under such an agreement is bounded by the aggregation threshold in Chapter 16; individual-level access requires the individual's own, separate consent.

08.8.4 Revoking consent removes the derived access going forward and is honoured in any dataset built from it at that dataset's next generation (Chapter 04 §04.7.3, Chapter 07 §07.24.3); it does not retroactively un-happen access already taken while consent was active, which remains visible in the audit trail.

08.9 Service and agent identities

08.9.1 A service identity (a backend job, an integration, a webhook consumer) and an agent identity (Chapter 05, Chapter 13's AI agents) each hold their own declared, scoped grant. Neither inherits ambient privilege from the runtime environment it executes in.

08.9.2 An agent never sees more than the subject of its action could see themselves (Chapter 04 §04.4.19, Codex 3). This is checked through the identical has_role/scope mechanism as a human caller — an agent is not a privileged caller class.

08.9.3 A service or agent identity owns no data of its own (Chapter 04 §04.4.19); it acts on behalf of a declared purpose and a bounded scope, and its actions on consequential matters are logged exactly as a human's would be (§07.23, Chapter 13).

08.9.4 An agent's purpose-specific consent (Chapter 04 §04.7.4, training on member data) is distinct from, and does not expand, its operational access scope for taking actions.

08.10 Review and revocation cadence

08.10.1 Every Role grant, elevation, and delegation is subject to standing review: a person or system with access no longer justified by current responsibility is revoked, not left dormant on the theory that it is unused and therefore harmless.

08.10.2 Grants are reviewed on a fixed cadence set by the Stewardship Office, and additionally on every material change of responsibility (a role change, an engagement's close, a departure) — review is not solely calendar-driven.

08.10.3 An access-and-audit review surface (DASH-10, TOOL-11) answers, for any grant, who holds it, on what scope, granted by whom, when, why, and when it was last exercised. A grant that cannot answer these is treated as unreviewed and is a defect.

08.10.4 A revoked grant's history is retained (Chapter 07 §07.9's retention rule); revocation removes future access, it does not remove the historical record that the grant once existed and what was accessed under it.

08.10.5 An elevation, once its reason is found on review to be inadequate or its scope excessive, is revoked immediately and the review finding is itself recorded, not quietly resolved.

08.11 Matrix — user type to grant pattern

This matrix names the typical grant pattern for each user type in Chapter 04 §04.4. It is illustrative of standing scope; an individual's actual grants are always whatever Role rows exist for them, never inferred from type alone (§04.5).

08.12 Interfaces

API-01 Identity & Access (Codex 5) is the sole boundary through which Role grants are created, checked, and revoked · TOOL-11 Access & Audit Console · DASH-10 Administrator · API-11 Audit · every SURF- and DASH- entry authorises against this chapter per Chapter 04 §04.10 · Chapter 07 ENT-05 Role and ENT-19 AuditRecord are the entities this chapter governs access through.

08.13 Invariants

1. 1Deny-by-default: nothing is reachable without an explicit grant (§08.2.1).
2. 2Permissions are enforced server-side and independently at the data layer (§08.2.3).
3. 3Seniority, employment, and administration confer no access by themselves (§08.3.5).
4. 4Every elevation is time-bounded, reasoned, and produces an AuditRecord the subject can eventually see (§08.6).
5. 5An agent or service identity never sees more than the subject of its action could see themselves (§08.9.2).
6. 6Consent-derived access is exactly as broad, and exactly as revocable, as the consent that created it (§08.8).

08.14 Prohibitions

1. 1Granting access by role name without a matching, resolvable scope.
2. 2Inferring a broader scope from an accumulation of narrower ones.
3. 3A standing, non-expiring elevated grant.
4. 4An administrator role reading member content solely by virtue of administering access to it.
5. 5An enterprise or partner agreement substituting for an individual's own consent to disclosure of their record.
6. 6A client-side check standing in for, or diverging from, the server-side and data-layer decision.
7. 7A row-level security policy that re-implements its own role logic instead of calling the shared has_role function.

08.15 Open questions

1. 1Review cadence. The exact fixed interval for standing grant review (§08.10.2) is not yet set by the Stewardship Office.
2. 2Cross-division elevation. Whether an elevation granted for one division's investigation automatically expires at that division's boundary, or must be separately scoped per division touched, is undecided.
3. 3Agent consent granularity. Whether agent operational scope and agent training-consent scope (§08.9.4) should share one grant record or remain permanently distinct entities is open, pending Chapter 13's fuller treatment.
4. 4Delegation chains. Whether a delegate may further delegate a received grant, or whether delegation is single-hop only, is unresolved.

08.16 Governing Codices

Codex 4 (people, user types, permission model); Codex 5 (entities and API boundaries this chapter governs access to); Codex 1 Article VI (member rights, oversight, explainability); Codex 3 (agent identities); Chapter 04 (visibility contract per type); Chapter 07 (Role and AuditRecord entities); Chapter 09 (workflow stages this chapter's grants authorise).