Modelo de autorização
Os tipos e relações do OpenFGA que o Xokepoint usa para sujeitos, agentes, tools e recursos.
O modelo tem poucos tipos, e cada relação responde a uma pergunta da decisão.
| Relação | Pergunta que responde | Quem escreve |
|---|---|---|
agent#delegator@user ou @service_account | O sujeito delegou para o agente? | Publicação das permissões |
tool#can_call@agent | O agente pode chamar a tool? | Publicação das permissões |
resource#can_act_on@agent | O valor é um dos allowed values do agente? | Publicação das permissões. O Admin não grava allowed values por enquanto |
tool#parent@mcp_server | A tool pertence ao server? | Está no modelo, ainda não é escrita |
A capacidade é dada por tool, nunca pelo server inteiro. Um server que publica uma tool nova não dá ao agente acesso a ela.
A relação de recurso protege a chamada, não o resultado
O can_act_on é checado para o recurso que a chamada nomeia nos argumentos, pelo mapeamento da tool. O Xokepoint não inspeciona o que a tool devolve. Uma tool que lista ou busca pode devolver recursos que o agente não poderia abrir um por um: o agente pode chamar get_item só para os itens 1 e 2, e ainda ver o item 3 no resultado de list_items.
Quem guarda os dados filtra o resultado. Um server próprio recebe, em cada requisição, um token com o sujeito em sub e o agente em act.sub (Autenticação upstream), então pode devolver só o que aquela pessoa e aquele agente podem ver. Filtrar o texto livre de um resultado no gateway seria frágil: o conteúdo em texto de um resultado repete os dados estruturados.
Um tipo de recurso para todos
Existe um único tipo resource. A espécie do recurso, como github_repository, vem do resource.type do mapping COAZ e entra no identificador. Um fornecedor novo ou um MCP server próprio do cliente não exigem mudança no modelo, só um mapping. As relações parent, entre uma tool e o server dela e entre recursos, estão no modelo para uma hierarquia futura, como repositório dentro de organização, e ainda não são escritas. Nenhuma decisão depende delas hoje: o identificador da tool já carrega o ID do server.
Identificadores
| Objeto | Formato |
|---|---|
| Sujeito | user:<connection>|<sub> ou service_account:<connection>|<sub> |
| Agente | agent:<agent ID> |
| Server | mcp_server:<server ID> |
| Tool | tool:<server ID>/<nome da tool> |
| Recurso | resource:<server ID>/<resource.type>/<resource.id> |
O sujeito usa o ID da identity connection, não a URL do issuer. Assim a troca de URL de um IdP não invalida as relações. Os identificadores não têm prefixo de workspace ou ambiente, porque cada ambiente tem um store próprio no OpenFGA (Multitenancy).
Como ilustração, estas são as tuplas que deixam um agente de suporte abrir issues em um repositório pela 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