Access Policy

Origin & evolution

The founding principle is older than the models that implement it. In The Protection of Information in Computer Systems (1975), Jerome Saltzer and Michael Schroeder set out eight design principles, among them least privilege: every user and every program should operate with the minimum set of permissions needed for the task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →. Every access policy since has been an attempt to express least privilege without making the system unusable.

The dominant model was formalised by David Ferraiolo and Rick Kuhn in a 1992 NIST paper on role-based access control. RBAC groups permissions into roles and assigns roles to users, so access tracks job function instead of being granted one user at a time. It was standardised as ANSI/INCITS 359 in 2004 and remains the default in most enterprise software. Its limit shows in scale: organisations accrete hundreds of near-duplicate roles, a drift known as role explosion.

Two responses followed. Attribute-based access control (ABAC) writes rules over attributes of the user, resource, and environment ("a manager in the EU region may approve expenses under 5,000 euro during business hours"), trading the simplicity of roles for fine-grained expressiveness. Relationship-based access control (ReBAC) decides access from the graph of relationships between users and resources, the model Google described in its 2019 Zanzibar paper and which powers Google Drive-style "shared with" permissions. Alongside the models, Open Policy Agent made policy-as-code mainstream: rules written in the Rego language, version-controlled and tested like any other code, evaluated by a decoupled engine the application queries for a yes or no.

How it works in practice

A collaboration tool starts with RBAC: owner, editor, viewer. It works until customers ask for document-level sharing, where a viewer of a workspace can be an editor of one specific file shared with them directly. Roles cannot express that without a role per document, so the team moves the per-document decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → to a ReBAC model: a user may edit a document if there is an editor relationship between them and that document, directly or inherited through a folder.

They keep the coarse workspace roles in RBAC and express the fine-grained sharing as relationships, evaluated by Open Policy Agent so the policy lives in a repository with tests and review. Least privilege holds because the default is no relationship and therefore no access, and every grant is an explicit edge someone created.

Access policy vs. its neighbours

• Security policy🔐Security PolicySecurityA security policyView reference → is the broad governing document covering acceptable use, data handling, incident🚨IncidentDevOps & PlatformA production incidentView reference → response, and more. An access policy is the specific subset that governs authorisation. The security policy says data must be need🫀NeedUserA user need, pain, desire, or constraintView reference →-to-know; the access policy is the machine-enforceable expression of that.
• Security control🎚️Security ControlSecurityA security control or mitigationView reference → is the enforcement mechanism. An access policy states the authorisation rules; the control (the policy engine, the ACL check at runtime) is what actually allows or denies the request. The policy is the rule; the control makes it bite.
• Authentication establishes identity; the access policy acts only after identity is known. Conflating them is a common and dangerous mistake: a system can authenticate a user perfectly and still authorise them to read everything.

In the graph

In the Unified Product Graph, an access policy sits in the security region as a governing rule rather than a runtime mechanism. A security_policy_defines_access_policySecurity PolicydefinesAccess Policyhierarchy edge ties it to the broader policy it derives from, keeping the authorisation rules anchored to organisational intent. A product_restricts_access_with_access_policyProductrestricts access withAccess Policyhierarchy edge grounds the rule in the system that enforces it, and an access_policy_governs_serviceAccess PolicygovernsServicecross-domain edge names the specific service it covers, so the scope of any rule is queryable. That structure keeps the principle and the implementation connected: a service governed by no access policy is an open question, and an access policy attached to no security policy is a rule no one can trace back to a decision.