Policy as code represents authorization rules as machine-readable text that a general-purpose policy engine evaluates at runtime. Rather than scattering checks through application code, it externalizes reusable access logic so decisions can respond to the request context. section 1.4 section 1.6
Treating policies as software makes them reviewable, versioned, testable, deployable, and reversible. A policy repository is the human-facing source for authoring and history; a policy store is the operational location queried for authorization decisions. Keeping them distinct supports clear ownership and controlled deployment. section 1.4.1 section 10.2
A practical policy-as-code flow is:
- Author clear, least-privilege rules in a policy language and keep the policy, schema, and tests in a repository. section 10.4 section 10.2
- Validate, test, and review changes in continuous integration before publishing them. section 1.4.1 section 10.5
- Build a signed bundle, promote it to the matching policy store, observe decisions, and roll back when needed. section 10.2
- Use static analysis alongside tests to find conflicts, redundancies, and gaps before production. section 10.5
Managed devices for critical resources
A forbid rule can deny every action on resources categorized as critical unless the request reports a Secure device with an overall security assessment of at least 80. The rule expresses a broad zero-trust guardrail while relying on current device-posture context. section 1.4.1 section 1.4
Figure 1.2 Dynamic authorization can represent policy in two complementary ways. On the left, Policy as Code stores machine-readable policies in a repository that the access logic evaluates at runtime. On the right, Policy as Data stores relationships and attributes in a structured data store that the same access logic uses to determine decisions. Both approaches externalize policy from the application, while supporting different kinds of flexibility.
Compare code-based rules stored in a repository with data-based relationships and attributes stored in a structured data store. Both are evaluated by access logic at runtime, but they solve complementary problems. section 1.4
Policy as code is strongest for broad, complex rules applied across many users, such as device, department, training, or risk requirements. Policy as data can supply changing attributes, relationships, roles, and permissions; combining both lets stable executable rules use current organizational and resource data. section 1.4.3 section 6.3.2
This approach is not merely putting policy files in version control. Effective use joins policy design, management, and assurance: precise rules, repeatable deployment, decision visibility, and testing for expected behavior and regressions. Governance adds approval, change control, and production safeguards. section 10.4 section 14.2.3
The policy engine remains the authority for enforcement and authoritative explanations. AI may help people understand policies or decisions, but it must not infer access decisions or replace deterministic evaluation against defined inputs and current system state. section 17.1
