A policy store is the runtime location from which an authorizer retrieves authorization policies to evaluate access requests. It separates executable enforcement from application code and from the policy repository used for authoring, review, and history. This separation gives teams a consistent place to publish approved policy bundles while applications make real-time decisions. section 10.2 section 10.5
A large organization may use several stores with distinct ownership and scope: an application store for document editing, a deployment store for engineering actions, and a central store for organization-wide guardrails. For a request, the authorization layer can gather relevant policies from these sources and evaluate them as one policy set. In Cedar, policies first match the request’s principal, action, and resource; matching policies then evaluate their conditions. No scope match produces an implicit deny. section 7.3.2
Treat a policy store as the execution endpoint of a controlled policy delivery process:
- Author policies, schemas, tests, and documentation in a policy repository, where people can review and version changes. section 10.2
- Validate syntax and schemas, run static analysis and tests, then build a signed policy bundle in continuous integration. section 10.2.4
- Publish the approved bundle to its corresponding store, where the authorizer retrieves it at runtime. section 10.2.4
- Observe decisions, latency, and denial reasons; republish a previous bundle when a deployed change must be rolled back. section 10.2.3
Customer Collaboration, deployments, and guardrails
A collaboration application can query a store paired with its own policy repository, while an engineering team manages a separate deployment store. An identity team can operate a central guardrails store for policies that apply across the organization. Keeping these mappings separate makes ownership, review, and deployment boundaries clear without forcing every access rule into one team’s workflow. section 10.2
Figure 10.6 Continuous integration for policies. Bob’s pull request triggers validation, analysis, and testing. After the checks pass, his changes are merged, bundled into a signed package, and published to a policy store, where the authorizer uses them to evaluate requests at runtime.
The pipeline shows the path from a pull request through validation, analysis, testing, signing, and publication to the store that serves runtime authorization. section 10.2.4
Operational visibility is part of running a store safely. Decision logs can identify the policy and condition behind a denial, while metrics reveal authorization latency. Versioned bundles make the active policy set traceable and provide a practical rollback path when a change blocks legitimate work. section 10.2.3 section 10.5
