Authorization patterns
Where the access decision lives, and why Xokepoint sits in the path of the call.
Every application decides access somewhere. Architectures differ in where that decision lives and in who guarantees that it was consulted.
In the inline pattern, the rule is code. Each service has its own version of it, and auditing who can do what means reading every service. In the decoupled pattern, the rule moves to a PDP, but each service still has to remember to ask. In the externalized pattern, an enforcement point sits in the path of the call: the service does not change, and no call reaches it without a decision.
For agents, the third pattern is the one that solves the problem. Vendor MCP servers, such as GitHub's or Google's, will not consult each customer's policy. Xokepoint sits between the agent and those servers, and it is Xokepoint that decides.
The second pattern stays useful where the customer controls the code. After an ALLOW, a customer's own MCP server receives from Xokepoint a token made only for it, with the subject and the agent. The server validates that token with the Xokepoint public key and can decide about its own data, for example filter RAG documents by user. Upstream authentication shows how.
OAuth scopes replace none of these patterns. A scope such as repo says what an application can do in general. It does not say whether this agent can open an issue in this repository, for this person. Why ReBAC returns to this point.