Policy as data represents the attributes, permissions, and relationships used for authorization as structured, runtime-queryable information. A general-purpose authorization engine evaluates that information when a request arrives, rather than relying on static permissions or application-specific access code. The data commonly lives in a database and can be changed through a user interface or API. section 1.4 section 1.4.2
This approach separates stable decision logic from changing access state. Reusable rules can ask whether someone owns a resource, edits it, supports its customer, or manages its owner; changing the relationship graph changes future decisions without rewriting or deploying those rules. People or systems permitted to update the graph can therefore shape access directly. section 6.3.1 section 6.1.1
Figure 1.3 A relationship graph representing access to a Google document. Rather than using static ACLs, this model captures roles (e.g., Owner, Editor, and Viewer) as first-class relationships between users and resources. The graph also models hierarchical relationships, such as parent folders, enabling more flexible, general-purpose authorization logic that can be queried and evaluated dynamically.
A relationship graph makes roles and hierarchy first-class data: users connect to a document as owner, editor, or viewer, while parent folders can contribute further context to a runtime decision. section 1.4.2
Document sharing
A document can record a different owner, set of editors, contributors, and organizational relationship for each resource. Instead of enumerating these cases in a small set of policies, an authorization engine queries the stored relationships at runtime. The same pattern supports transitive access: a manager may access a deployment plan because an employee owns it; removing that ownership removes the manager's access as well. section 1.4.2 section 6.1.1
Policy as data and policy as code are complementary. Code is suited to broad, complex rules, while data holds many fine-grained, evolving relationships, roles, and permissions. A policy can retrieve a principal's department from an identity or HR system and compare it with resource metadata, so an employee's access changes when their assignment changes. Both policy models and their decision records can support auditing. section 1.4.3 section 1.7
Structured policy data also represents bounded delegation. A delegation record can carry the delegator, delegate, permitted actions, resource scope, and expiration; the enforcement point includes those attributes in the authorization request. Delegation remains an input to policy evaluation rather than bypassing policy. section 18.6.1
