Policy Information Point
Where do the facts used by a policy decision come from?
Reference notes by Min · Reviewed October 12, 2026
Definition
A Policy Information Point (PIP) is a source of attribute values used in an authorization evaluation. It can supply facts about the actor, resource, action, or environment.
A PIP supplies facts for an access decision. Those facts may come from identity records, resource catalogues or current task state. In an agent workflow, authority should come from trusted systems rather than an agent’s own description of its permissions.
What it covers
- Actor attributes
- Workload identity, requester, organization, and permitted task scope.
- Resource attributes
- Data classification, ownership, permitted region, or access restrictions.
- Action/environment attributes
- Requested operation, current time, destination, or approval state.
- Provenance and freshness
- Where each value came from, when it was observed, and how long it is usable.
For each attribute, define its issuer, meaning, data type and freshness expectation. A resource classification confirmed yesterday and an approval revoked a minute ago have different freshness requirements. Cache policy should reflect the consequences of a stale value.
In practice
Practical design patterns by Min.
- Name an authoritative source for each attribute and document its meaning.
- Avoid treating a model-generated claim of permission as authoritative evidence.
- Specify missing-attribute, outage, conflicting-value, and stale-cache behavior.
- Limit exposed attributes to the information required for the decision.
Create an attribute catalogue and assign an owner to each source. Record whether an attribute is asserted, verified, derived or unavailable.
Specify how consumers handle missing, contradictory or expired facts. For a consequential action, escalation may be preferable to treating an unavailable classification as unrestricted.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Trace the source of each fact
A PIP supplies attribute values; the context handler can collect them for a decision request. For an agent action, distinguish a verified identity or current approval from a value merely stated in a prompt or tool response. Record issuer and observation time so a reviewer can judge which facts were actually available.
Source: OASIS XACML 3.0 ↗
Define missing-data behavior
In XACML, a required missing attribute can lead to Indeterminate and identify information needed for a refined request. A service may retry with authoritative data, stop the operation, or escalate. Treating the absent value as permission would be a separate and potentially unsafe policy choice.
Source: OASIS XACML 3.0 ↗
Working example
May this agent email an external recipient?
A proposed policy requires an active agent, an authorized task, a permitted recipient, and current human approval.
- The PIP retrieves those attributes from the agent registry, identity system, task record, and approval service.
- The PDP evaluates the policy using the supplied context.
- The PEP allows or blocks sending. Human approval is an application workflow; it is not a fifth XACML decision type.
Why the controls matter
For a document export, retrieve the document’s classification from its catalogue and task authority from the approval service. Keep the agent’s suggested destination as a request parameter; it should not become a trusted approval attribute.
Policy roles at a glance
| Role | Responsibility | Example |
|---|---|---|
| PAPPolicy Administration Point | Creates policies. | The approved external-email rule. |
| PIPPolicy Information Point | Supplies attribute values. | Current approval status and data classification. |
| PDPPolicy Decision Point | Evaluates policy and returns a decision. | Permit, Deny, NotApplicable, or Indeterminate in XACML. |
| PEPPolicy Enforcement Point | Requests and enforces the decision. | The mail-service boundary allowing or blocking the send. |
- PEPIntercept the action
- PIPSupply current facts
- PDPEvaluate policy
- PEPEnforce the result
Common pitfalls
- Asking the PIP to make or enforce the authorization decision.
- Using stale approval data after permission has been revoked.
- Assuming a policy engine can infer facts that no authoritative system provides.
A perfectly formatted attribute can still be wrong or stale. Record retrieval time, source version and validation status so an investigator can reconstruct what the decision actually relied on.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Who is authoritative for each fact?
- How fresh must it be?
- Can the decision distinguish unknown from permitted?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- OASIS XACML 3.0 standard ↗Accessed October 12, 2026