Authorization model
The OpenFGA types and relations that Xokepoint uses for subjects, agents, tools and resources.
The model has few types, and each relation answers one question of the decision.
| Relation | Question it answers | Written by |
|---|---|---|
agent#delegator@user or @service_account | Did the subject delegate to the agent? | Permission publication |
tool#can_call@agent | Can the agent call the tool? | Permission publication |
resource#can_act_on@agent | Is the value one of the allowed values of the agent? | Permission publication. The Admin does not write allowed values for now |
tool#parent@mcp_server | Does the tool belong to the server? | In the model, not written yet |
A capability is granted per tool, never for the whole server. A server that publishes a new tool does not give the agent access to it.
The resource relation guards the call, not its result
can_act_on is checked for the resource that the call names in its arguments, through the mapping of the tool. Xokepoint does not inspect what the tool returns. A tool that lists or searches can return resources that the agent could not open one by one: the agent may call get_item only for items 1 and 2, and still see item 3 in the result of list_items.
The server that holds the data filters its result. A custom server receives, in each request, a token with the subject in sub and the agent in act.sub (Upstream authentication), so it can return only what that person and agent may see. Filtering free text of a result in the gateway would be fragile: the text content of a result repeats the structured data.
One resource type for all
There is a single resource type. The kind of resource, such as github_repository, comes from the resource.type of the COAZ mapping and is part of the identifier. A new vendor or a customer's own MCP server needs no model change, only a mapping. The parent relations, between a tool and its server and between resources, are in the model for a future hierarchy, such as a repository inside an organization, and are not written yet. Nothing in a decision depends on them today: the tool identifier already carries the server ID.
Identifiers
| Object | Format |
|---|---|
| Subject | user:<connection>|<sub> or service_account:<connection>|<sub> |
| Agent | agent:<agent ID> |
| Server | mcp_server:<server ID> |
| Tool | tool:<server ID>/<tool name> |
| Resource | resource:<server ID>/<resource.type>/<resource.id> |
The subject uses the identity connection ID, not the issuer URL. So a change of an IdP URL does not invalidate the relations. Identifiers have no workspace or environment prefix, because each environment has its own OpenFGA store (Multitenancy).
As an illustration, these are the tuples that let a support agent open issues in one repository for alice:
- user: user:kc-prod|alice
relation: delegator
object: agent:support-bot
- user: agent:support-bot
relation: can_call
object: tool:github/create_issue
- user: agent:support-bot
relation: can_act_on
object: resource:github/github_repository/acme/payments