Padrões de autorização
Onde a decisão de acesso mora, e por que o Xokepoint fica no caminho da chamada.
Toda aplicação decide acesso em algum lugar. A diferença entre as arquiteturas está em onde fica essa decisão e em quem garante que ela foi consultada.
No padrão embutido, a regra é código. Cada serviço tem a sua versão dela, e auditar quem pode o quê significa ler todos os serviços. No padrão desacoplado, a regra vai para um PDP, mas cada serviço ainda precisa lembrar de perguntar. No padrão externalizado, um ponto de enforcement fica no caminho da chamada: o serviço não muda, e nenhuma chamada chega a ele sem decisão.
Para agentes, o terceiro padrão é o que resolve o problema. Os MCP servers de fornecedores, como os do GitHub ou do Google, não vão consultar a política de cada cliente. O Xokepoint fica entre o agente e esses servers, e é ele quem decide.
O segundo padrão continua útil onde o cliente controla o código. Um MCP server do próprio cliente recebe do Xokepoint, depois de um ALLOW, um token feito só para ele, com o sujeito e o agente. O server valida esse token com a chave pública do Xokepoint e pode decidir sobre os próprios dados, por exemplo filtrar documentos de um RAG pelo usuário. Autenticação upstream mostra como.
Escopos OAuth não substituem nenhum desses padrões. Um escopo como repo diz o que uma aplicação pode fazer em geral. Ele não diz se este agente pode abrir uma issue neste repositório, por esta pessoa. Por que ReBAC volta a esse ponto.