An authorization decision determines whether a principal may perform a requested action on a resource under the current conditions. Authentication establishes who or what is making the request; authorization evaluates whether that identified principal should be allowed to act now. A correct sign-in is therefore necessary but insufficient: stolen or weakly verified credentials can make an otherwise sound policy grant access to the wrong party. section 2.3.2 section 4.0
The decision is contextual rather than a simple role check. Roles, attributes, relationships, schedules, device status, network, and external obligations can all affect the result. A project manager may view dashboards and assign tasks because of her organizational role; a call-center agent may access sensitive data only during an assigned shift; a student may be admitted only from a registered device. section 4.2 section 5.3
A policy-driven flow turns a request into an enforceable result: a Policy Enforcement Point (PEP) intercepts the request, a Policy Decision Point (PDP) evaluates policy, and a Policy Information Point (PIP) supplies needed attributes. The resulting permit or deny is enforced at the access point. Separating enforcement, evaluation, policy management, and contextual data keeps rules visible, changeable, and consistent instead of scattering them through application code. section 4.4.1 section 4.6
A deny that can be explained
Alice requests a team report at 9:17 p.m. from her company-issued laptop at home. The policy evaluation finds that she is a project manager and uses a registered device, but report access is allowed only from 7 a.m. to 8 p.m. The PDP returns a deny to the PEP and identifies the time policy, allowing the application to explain the restriction rather than merely reject the request. section 4.4.1
Reliable authorization decisions require more than an allow-or-deny output:
- Use accurate, current identity and attribute data; stale or ambiguous inputs undermine the result. section 2.3.2 section 6.2.3
- Evaluate policies deterministically so identical requests under identical conditions produce reproducible outcomes that can support audits, reviews, and incident response. section 17.1
- Log and consistently enforce decisions across entry points, including API gateways, service meshes, and per-service proxies. section 11.1.4
- Make decisions continuously when relationships, context, or delegated authority can change between requests. section 19.9
Figure 9.2 The Policy Enforcement Point (PEP) in ACME’s Customer Collaboration platform translates a real-world /share request into a Cedar evaluation by combining session data (principal), entity data (resource relationships), and context signals (environment attributes). Cedar’s is_authorized API provides an allow or deny decision, which the PEP enforces before forwarding the request to the backend.
This request mapping shows how a PEP converts an actual document-sharing operation into principal, action, resource, and context for a Cedar evaluation, then enforces the result. section 9.8
Authorization decisions also constrain AI systems and agents. AI may assist with policy analysis or explanations, but it should not infer enforcement outcomes from prompts because its results can be nondeterministic. For retrieval and agent actions, policy evaluation determines the authorized data or delegated scope first; a denial blocks the action and can guide the agent toward a revised plan. section 17.1 section 18.3.1 section 18.6.4
