The fine-grained model
The three questions Xokepoint asks on every tool call, and how each part of the agent configuration answers one of them.
Most access control for agents stops at the tool: the agent can call merge_pull_request or it cannot. That leaves out almost everything that matters. Merge in which repository? Acting for whom? With how many approvals on the pull request? Until when?
Xokepoint decides every call with three questions, in order, and each part of the agent configuration answers one of them:
| Question | Configuration part | Where it lives | Page |
|---|---|---|---|
| Who delegated? | Who can delegate, per identity provider | Relation in OpenFGA | Who can delegate |
| Which tool? | The agent's servers and tools | Relation in OpenFGA | Tools |
| Under which conditions? | Rules on the agent · server · tool link | CEL in the PDP | Rules |
The first two are relations: they exist or they do not, and they can have an end date. They are published before any call and queried in OpenFGA on every call. The third is a rule on call data: it only has an answer with the arguments and trusted attributes of that moment, and the PDP evaluates it (Conditions).
What makes it fine-grained
A rule reaches the concrete object. "Can call merge_pull_request" becomes "can merge in acme/payments-api, and only there", with the rule repository is one of [acme/payments-api] on that tool. Each tool has its own rules, so the agent can list issues in two repositories and merge in only one.
A rule reads the real world. A rule can compare a call argument with a trusted attribute that Xokepoint fetches at that moment from a customer API: the approvals of a pull request, the refund limit of an employee, the status of an order.
Delegation is per person. The agent acts only for those checked in the identity provider directory, and the same agent can serve 80 people in one team and nobody in another.
Everything is checked on every call. Nothing is frozen in a token. Revoking a relation or changing a rule applies on the next call.
The unit of configuration
Everything belongs to the agent. Delegation links subjects to the agent, and tools and rules are the same for every subject that delegates to it and for every instance of the agent. That is why there is no "rule for alice": if alice needs a different set of permissions, that is another agent, another tool or another rule on the agent link.
The worked example builds an agent from scratch and shows the result of five different calls.