PEP, PDP, PIP and PAP
The four roles of externalized authorization and who fills each one in Xokepoint.
Externalized authorization separates four roles. The split comes from the ABAC model of NIST SP 800-162 and reappears in the Zero Trust architecture of NIST SP 800-207. It guarantees that whoever enforces the decision is not whoever decides, and whoever decides is not whoever writes the policy.
| Role | In Xokepoint |
|---|---|
| PEP | Receives the tool call, validates it, builds the question, enforces the decision and executes |
| PIP | Fetches attributes from the customer's trusted sources |
| PDP | Queries the relations, evaluates the conditions and decides |
| PAP | Stores each agent's permissions, publishes the relations and the conditions |
OpenFGA is not the PDP
Many market diagrams put OpenFGA in the place of the PDP. In Xokepoint it is a piece that the PDP queries. OpenFGA answers whether a relation exists, including conditions of the relation itself, such as an expiration date. It does not read the call arguments or the PIP facts. That part belongs to the PDP, in CEL.
The split has a practical consequence. Replacing the relation engine, or adding another, does not change the contract between PEP and PDP, which is AuthZEN.
One process, separate roles
PEP, PIP and PDP run in the same backend process and exchange AuthZEN models through Go interfaces. The roles stay separate in the code: the PEP does not decide, the PDP does not fetch external data, and the PIP does not evaluate policy.