Permission Matrix¶
Template — instantiates Least-Privilege Access Design
Lays actors and roles against resources and actions in a single reviewable grid, so gaps, over-grants, and dangerous combinations become visible at a glance.
A Permission Matrix is a two-dimensional review artifact: rows are actors and roles, columns are resources and the actions on them, and each cell marks what is allowed. Its purpose is not enforcement and not the operative grant — it is visibility over the whole population at once. The one idea that makes it this mechanism: it takes access that is otherwise scattered across dozens of per-resource lists and pins it into a single grid a human can read across and down, so patterns no individual Access Control List can show — an over-broad role, a resource half the company can touch, a single actor holding two actions that must never combine — jump out. It is the design-and-audit lens, not the door.
Example¶
An accounts-payable team is redesigning who can do what in its procurement system. Someone builds a permission matrix: the rows are roles — Buyer, AP Clerk, AP Manager, Vendor-Master Admin, Controller — and the columns are the sensitive actions — create purchase order, approve purchase order, create vendor, change vendor bank details, release payment. Filling in the cells, one row lights up wrong: the AP Clerk role can both create vendor and release payment. On its own each grant looked reasonable, but read across the row it is a fraud pathway — the same person can invent a shell vendor and pay it. The grid makes the toxic pair obvious in a way no per-resource list did, because each list only ever saw one column. The fix is to split the two actions across roles so no single row holds both. The matrix's whole contribution was to make the combination visible.
How it works¶
The distinctive machinery is cross-tabulation for human reasoning. Build the axes from the resource inventory and the actor inventory; mark each cell allowed / denied / conditional; then read the grid three ways. Across a row shows one actor's total reach — the over-privileged jump out. Down a column shows everyone who can touch one sensitive resource — the exposure of a crown jewel. And a scan for forbidden cell-pairs within a single row is exactly the separation-of-duties test: which actors hold a combination the design forbids. It is static and produced at design time or on an audit cadence — a snapshot to reason over before granting, or to catch drift after. It shows what could be done; it never grants, enforces, or records what was done.
Tuning parameters¶
- Axis granularity — actors vs. roles for rows; resources vs. resource-and-action for columns. Finer axes reveal more but grow the grid past readability.
- Cell vocabulary — binary allow/deny vs. allow / conditional / deny. Richer cells capture context-gated access but complicate the scan.
- Segregation rule set — which column-pairs are declared toxic. This is the judgment that turns a passive grid into an active check; too few rules miss fraud paths, too many flag everything.
- Coverage scope — every resource vs. only the high-risk subset. Full coverage is comprehensive but often unreadable; a risk-scoped matrix stays legible.
- Refresh source — hand-maintained vs. generated from the live grants. Generated matrices can't silently diverge from reality; hand-kept ones always eventually do.
When it helps, and when it misleads¶
Its strength is turning scattered, per-object grants into one comprehensible picture — the canonical instrument for spotting over-broad roles and dangerous combinations, and the natural worksheet for a redesign or an audit. It is Lampson's access-control matrix[1] rendered for people rather than machines.
Its failure mode is that a matrix is a model of the system, not the system. Maintained by hand, it quietly diverges from the real ACLs and policies it claims to depict, so a cell reads "denied" while the live grant says otherwise — and a decision made on a stale matrix is worse than none. A large matrix also becomes unreadable, defeating its only purpose. The classic misuse is treating the grid as ground truth after the underlying grants have drifted. The discipline that guards against this is to generate the matrix from the live grants rather than curating a parallel copy, and to re-derive it on a cadence so what you read is what is actually true.
How it implements the components¶
resource_map— the columns enumerate the protected resources and the actions on them, giving the object inventory a legible shape.actor_role_map— the rows enumerate every actor and role that can reach those resources, so the population is laid out in one place.segregation_of_duties_check— scanning a single row for a forbidden cell-pair is the check for one actor holding a toxic combination of powers.
It displays which actions are allowed but is not the grant of record and does not enforce anything (permission_scope, access_boundary — that's Access Control List); and it shows what an actor could do, never what they actually did, so it does not review real use (access_audit — that's Access Log Review).
Related¶
- Instantiates: Least-Privilege Access Design — the matrix is the review lens that makes the design's grants inspectable as a whole.
- Consumes: Access Control List — the live per-resource grants are the truest source to generate the grid from.
- Sibling mechanisms: Access Control List · Need-to-Know Policy · Access Log Review · Access Recertification · Attribute-Based Access Policy · Role-Based Access Control · Approval Workflow
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: The mechanism is a review-facing actor-by-resource grid whose cell arrangement makes over-grants, gaps, and forbidden combinations visible.
Nearest alternative: Representation, Specification & Plan — The matrix stores permissions, but its operative form is the human inspection affordance.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Permission Matrix is rooted in computer science and software engineering: Lampson's access-control matrix models subject-object rights as the exact grid this mechanism exposes.
Review resolution: Both blind reviewers agree that computer science and software engineering is the primary origin. Reconciliation resolves domain_reach_disagreement. Formative alternate lineages are not added; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=single_lineage describes the relationship among origin lineages.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The access-control matrix — Butler Lampson, "Protection" (1971) — models protection state as a grid of subjects against objects with allowed rights in each cell; ACLs are its columns and capabilities its rows. A permission matrix is that formal object made human-readable for design and audit. withdrawn registry ↩