Visão geral
O caminho de uma tool call, do token do agente até ALLOW ou DENY e a resposta da tool.
Quando um agente chama uma tool, ninguém escreveu antes a sequência de chamadas que ele vai fazer. O modelo escolhe a tool e os argumentos no momento. Por isso o Xokepoint não pergunta "este usuário tem acesso ao GitHub?". Ele pergunta, em cada chamada: este agente, agindo por este sujeito, pode chamar esta tool sobre este recurso, agora?
Responder a essa pergunta exige algumas peças, e cada uma entra num ponto preciso do caminho da chamada:
Antes da primeira chamada, o agente troca o token do usuário por um token do Xokepoint. Essa troca só acontece se o usuário delegou para aquele agente, e o token resultante carrega as duas identidades. É o assunto de Identidade e delegação.
A chamada chega ao PEP, que confere protocolo, token e argumentos (A chamada MCP) e reescreve a tool call como uma pergunta no padrão AuthZEN (O pedido de autorização). O PIP junta à pergunta os fatos que só existem em sistemas do cliente (Enriquecimento). O PDP decide: consulta as relações no OpenFGA e avalia as condições da chamada (A decisão). Só com ALLOW a tool roda (Execução e resposta), e toda decisão fica registrada (Observabilidade).
Três assuntos não são um passo da chamada, mas explicam o comportamento dela: como um acesso deixa de existir (Revogação), de onde vêm as relações que o PDP consulta (Ciclo de vida da política) e como os clientes ficam separados (Multitenancy).
Uma observação para quem chega com outros diagramas na cabeça: no Xokepoint, o OpenFGA não é o PDP. Ele responde às perguntas de relação que o PDP faz, e o PDP soma a elas condições que o OpenFGA não avalia. Arquitetura PEP, PDP, PIP e PAP explica a divisão.