Skip to main content

Access control

Most access-control administration fails the same way: you can see the grants you made, but not the access they produce. The grant is a row; the access is the result of that row plus group membership plus inheritance plus a role plus a policy, and nobody can hold all of that in their head.

So the administration surface is built around three lenses over one model, and the third one is the interesting one.

Three lenses​

LensThe question it answers
A securable's permissionsWho has access to this thing, and what grants and denies produce it?
What a principal holdsWhat can this person, agent or service account actually reach, across everything?
Simulate a decisionIf I made this change, what would the answer be? Before making it

The second lens is the one auditors ask for and most platforms cannot answer, because they store grants per-resource and have no index in the other direction.

The third is the one that prevents incidents. A permission change you can test before you commit it is the difference between administration and guesswork, and it matters most in exactly the case where the stakes are highest: a broad-looking change to a group or an inherited scope, where the blast radius is not obvious from the edit itself.

One resolver, and DENY always wins​

Every one of those lenses reads the same resolver, so the simulation cannot disagree with reality. Effective permission on a securable is resolved by combining seven sources:

  1. Direct grants and denies on the entity.
  2. Group grants and denies, with transitive group resolution, so nested groups are followed rather than checked one level deep.
  3. Inherited access from parent securables.
  4. Catalog role assignments.
  5. Directory role projections, so a directory-level role can grant a catalog-level capability.
  6. Declarative policies, the attribute-based layer.
  7. Workspace bindings.

Two rules hold across all seven:

DENY always takes precedence over GRANT, regardless of source.

Time-bound access expires. An entry past its expiry is excluded from the calculation rather than lingering as a grant nobody remembers making.

The deny-wins rule is what makes a deny meaningful. In a system where a sufficiently privileged grant can outrank a deny, a deny is advice. Here it is a decision, and it cannot be out-voted by adding another role.

Writes are governed too​

Editing a grant is itself a consequential action. Grant edges are written through a manager that is gated by the decision boundary and recorded on the tamper-evident audit, so changing who can reach what is not a quiet database write.

That closes the loop an administrator actually needs: the change is simulated before it is made, gated when it is made, and recorded after it is made.

Administrative authority is one plane​

A separate question from "what may this principal reach" is "what may this principal administer", and the platform answers it with a single scope model rather than a special case per resource.

Whether a principal may administer an organization, a node, a workspace or a clean room is the same (kind, id) question on every surface. One model, four container kinds.

Oversight sits above the governed unit​

The consequence worth understanding is what an organization administrator cannot do.

A platform or security operator reads across the estate by holding an authority that no organization-scoped grant satisfies. An organization administrator is therefore refused exactly the cross-cutting consoles, not by a filter applied to their results, but because the authority they hold is the wrong kind.

Every administrative listing that could return another party's rows is either narrowed to the caller's administered scope or raised to that oversight authority. The surfaces that stay open are classified deliberately: public protocol endpoints, operator consoles, and reads scoped to the caller's own rows. The classification is pinned by a ratchet that can only shrink, so the open set cannot quietly grow.

The boundary is exercised, not asserted​

This is the part worth repeating to a security reviewer, because it is the difference between a control and a claim about a control:

The boundary is exercised two-party through the real routes, with each control broken in both directions, so a passing check cannot be a hollow one.

Testing that an authorized caller succeeds proves nothing on its own; a route with no check at all also passes that test. Testing that an unauthorized caller is refused proves nothing if the route was broken. Doing both, through the real routes, with two real parties, is what makes the result mean something.