A shared operational policy is a cross-system authorization rule owned by the functional group responsible for a domain. It governs several systems, workflows, or environments without becoming an enterprise-wide security mandate or being copied into each application. Engineering, operations, finance, and support can each express rules that reflect how their work must operate. section 15.3 section 15.3.2
Shared operational policies occupy the middle layer of a layered authorization design:
- Foundational security policies set requirements for every system, such as organization-wide security controls. section 15.3
- Shared operational policies apply a functional group's rules across related systems or workflows, such as deployment pipelines or sensitive-report access. section 15.3
- Application policies define authorization logic specific to one service or resource. section 15.3
After-hours production deployments
A deployment rule can allow production changes during business hours, while allowing them after hours only when the requester is the on-call engineer. Rather than modify every pipeline, engineering defines one forbid-unless policy that each production pipeline references. The policy engine then enforces the same operational condition across environments. section 15.3.2
forbid(
principal,
action == Pipeline::"deploy",
resource in Pipeline::"production"
)
unless {
/* During business hours */
context.time.hour >= 8 && context.time.hour < 18
||
/* After hours, only the on-call engineer may deploy */
context.oncall.current_engineer == principal
};
The policy listing shows the forbid-unless structure: it blocks production deployment except during business hours or when the requester is the current on-call engineer. section 15.3.2
For an access request, the policy engine selects applicable foundational, shared operational, and application policies from their policy stores and evaluates them together as one effective policy set. This centralizes a functional rule without fragmenting the decision. In Cedar, a forbid overrides a permit, so a restriction from any applicable layer remains effective even when an application policy would otherwise allow the action. section 15.3.4 section 15.4
Figure 15.4 Access control in a zero-trust security architecture. The PEP collects authentication context, device posture, and other request information to create a normalized request for the policy engine. The policy engine forms an effective policy set by selecting relevant foundational, shared operational, and application policies, and then evaluates the normalized request once to make a unified authorization decision. The PEP then enforces that decision at the target resource.
The diagram traces a normalized request from the policy enforcement point to the policy engine, where policies from all three layers produce one authorization decision. section 15.4
This separation gives functional groups responsibility for operational constraints while security and identity teams retain enterprise requirements and product teams retain service behavior. It avoids hard-coding the same rule into separate tools, supports consistent enforcement, and makes ownership of authorization intent clearer. section 15.3.4 section 15.7
