Overview

When an agent calls a tool, nobody wrote down in advance the sequence of calls it will make. The model picks the tool and the arguments at that moment. So Xokepoint does not ask "does this user have access to GitHub?". On every call it asks: can this agent, acting for this subject, call this tool on this resource, now?

Answering that question takes a few pieces, and each one enters at a precise point of the call path:

Before the first call, the agent exchanges the user token for a Xokepoint token. The exchange only happens if the user delegated to that agent, and the resulting token carries both identities. That is the subject of Identity and delegation.

The call reaches the PEP, which checks protocol, token and arguments (The MCP call) and rewrites the tool call as a question in the AuthZEN standard (The authorization request). The PIP adds the facts that exist only in customer systems (Enrichment). The PDP decides: it queries the relations in OpenFGA and evaluates the call conditions (The decision). The tool runs only on ALLOW (Execution and response), and every decision is recorded (Observability).

Three subjects are not a step of the call, but they explain how it behaves: how access stops existing (Revocation), where the relations that the PDP queries come from (Policy lifecycle) and how customers stay apart (Multitenancy).

A note for readers who arrive with other diagrams in mind: in Xokepoint, OpenFGA is not the PDP. It answers the relation questions that the PDP asks, and the PDP adds conditions that OpenFGA does not evaluate. PEP, PDP, PIP and PAP explains the split.