Policy Decision Point
Where is the policy evaluated?
Reference notes by Min · Reviewed October 12, 2026
Definition
A policy decision point evaluates applicable access-control policies and produces an authorization decision.
The PDP evaluates a request against policy. In an agent system, its implementation should keep the request facts, selected policy version and decision outcome traceable together. The application must define how it handles outcomes beyond a simple allow/deny abstraction.
What it covers
- Inputs
- Request attributes and applicable policy.
- Result
- A decision, potentially with obligations or advice.
Separate decision logic from the caller proposing the action. A proposed request may be generated by an agent, but the agent should not choose a more permissive policy version or invent the trusted facts used to evaluate it.
In practice
Practical design patterns by Min.
- Keep policy versions identifiable.
- Handle missing context and evaluation errors explicitly.
- Ensure the caller enforces obligations as well as the decision.
Version policy deployments and retain representative decision cases. Return an outcome and enough structured reason information for operators to diagnose a denial or evaluation error.
Define the enforcement contract with the receiving service. Specify which decision conditions must be satisfied before the service commits the action.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Keep all four outcomes visible
The PDP returns Permit, Deny, NotApplicable or Indeterminate. NotApplicable means no evaluated policy applied; Indeterminate means evaluation could not produce a definitive result. Neither is a synonym for a successful approval, and the PEP needs an explicit rule for handling both.
Source: OASIS XACML 3.0 ↗
Inspect policy combination
When several rules or policies apply, the configured combining algorithm determines the final result. Review overlapping rules and policy targets with realistic requests, including cases where one branch is missing data. A valid individual rule does not prove the combined decision is the one the team intended.
Source: OASIS XACML 3.0 ↗
Working example
A refund rule
An agent proposes a customer refund.
- Build a request with verified identity and refund amount.
- Evaluate the applicable policy.
- Return the decision to the enforcement point.
Why the controls matter
A document service submits an export request with verified actor and resource attributes. It should record the policy result with the operation identifier rather than let the agent translate a narrative answer into an access decision.
Common pitfalls
- Assuming a decision engine itself blocks a tool.
- Interpreting Indeterminate as permission.
Correct decision logic provides little protection if the calling service ignores its result. Review the full decision-to-enforcement path.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which policy version was used?
- What facts were supplied?
- Can enforcement honor every required condition?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- OASIS XACML 3.0 ↗Accessed October 12, 2026