Explainer

What is a permission surface?

The permission surface is the set of authority grants in force, each with an evidence basis, a scope, a state, and an expiry.

The permission surface is the set of authority grants in force for a system at a given moment. Each grant carries the evidence that justifies it, the scope it covers, its current state (allowed, review required, suspended, or revoked), and the date it expires.

Describing the surface by authority, not by access points, changes what it can be used for. A grant nobody uses is still on the surface. A capability the system can reach with no grant behind it is not. Comparing the surface with the catalog of what the system can do shows whether capability has outrun permission.

A hypothetical case. An operations agent's surface holds three grants. It may read customer records until the quarterly access review, issue refunds up to 200 currency units with a person confirming each one, and restart a queue worker on its own. Each grant names its evidence. The refund grant moves to review required when the fraud-rate policy record lapses.

In the glossary: Permission surface.

Mechanism, drawn

Permission surface and capability overhang

Law I: Capability does not imply authority. The set of reachable actions must be strictly reconciled against the bounded set of active, evidenced authority grants.

Outer envelope: technical capability surface All reachable API endpoints, raw tokens, network routes, database permissions Capability overhang (hazardous delta) Reachable by code, but lacks evidenced authority · Blindspot of OAuth scopes Governed permission surface (STD-07 grants) Strict subset of actions justified by active, unexpired evidence records Grant #A-104 Expires: 42d Scope: Refund < $200 Mode: Confirm Grant #A-105 Expires: 14d Scope: Read PII Mode: Audited Grant #A-106 Expires: 90d Scope: Worker reset Mode: Autonomous Law I invariant Capability ≠ authority Reachability does not license use. Execution in the overhang is a breach. STD-07 grant invariants 1. Evidence basis (calibrated packet) 2. Scope ceiling (finite impact cap) 3. Current state (active / suspended) 4. Hard expiry (ticking lease date) Reconciliation audit Overhang ratio = (Reachable - authorized) / reachable Goal: overhang → 0

Five fields on every grant

Every grant names a holder, a ceiling, its evidence, its state, and its expiry. A grant with no conditions for revoking it is a transfer under another name.

Scopes and roles listed as the surface

Teams list OAuth scopes and admin roles and call it the surface. Nothing on that list has an expiry or an evidence basis, so nothing on it can lapse.

Actions no grant covers

Publish the number of live grants, the share that have an expiry date, and a report of the action classes seen in production that no live grant covers.

Where the standards use it:

How is this different from an access inventory?

An access inventory lists what is reachable. The permission surface lists what is authorized, with the evidence for it and the date it expires, so each grant can be narrowed or withdrawn.

How does the surface relate to consent?

Consent is part of the evidence for a grant that acts on a person's behalf. When the person withdraws consent, that evidence lapses, and the grant has to be reconsidered.