An application-specific policy defines who may perform which actions on which resources within one service or domain. It is the narrowest policy layer: a finance reporting service, for example, can express its own reporting rules without also carrying organization-wide requirements for device posture, authentication freshness, or time limits. section 15.3.3 section 15.3
Product or engineering teams own these policies because they know the domain’s resources, roles, actions, and business logic. This separation lets service teams keep rules accurate while security and identity teams retain responsibility for enterprise-wide controls, and functional teams manage rules shared across systems. section 15.3.3 section 15.3.4
Finance report access
A finance service can permit members of the Finance group to view an internal financial report. The rule is deliberately about the service’s domain: the principal group, the Report:view action, and the internal_financials resource. section 15.3.3
permit(
principal in Group::"Finance",
action == ACME::Action::"Report:view",
resource in Report::"internal_financials"
);
This concise permit rule shows the three domain-level decisions an application policy names: principal, action, and resource. section 15.3.3
Application policies do not decide access in isolation. For each request, a policy engine selects applicable foundational security, shared operational, and application policies from their stores and evaluates them as one effective policy set. The resulting decision is returned to the policy enforcement point (PEP), which enforces it at the target resource. section 15.3.4 section 15.4
Layering keeps scopes distinct while combining their effects:
- Foundational security policies impose organization-wide requirements, such as device posture and authentication strength. section 15.3
- Shared operational policies govern conditions that span systems or workflows, such as operational status or time of day. section 15.4
- Application-specific policies express the individual service’s resources, allowed actions, roles, and business logic. section 15.3.3
A service-level permit cannot weaken a higher-level safeguard. Under Cedar’s forbid-overrides-permit semantics, a foundational forbid wins even when an application policy permits the request. Thus, a user otherwise allowed to view a finance report is denied if the laptop fails the required device-posture check. section 15.3.4 section 15.4
This design supports zero trust: access is evaluated for each request using identity, device posture, and application behavior rather than a network location alone. Clear policy ownership also improves governance by allowing teams to state their intent at the right scope without fragmenting the final authorization decision. section 15.4 section 15.7
