Autenticação upstream
Com que credencial o Xokepoint chama cada MCP server, e por que o token do agente nunca é repassado.
O token que o agente apresentou ao Xokepoint é emitido para o ingress do Xokepoint no ambiente dele. Repassar esse token ao MCP server seria token passthrough, que a especificação do MCP proíbe: um server não deve aceitar um token que não foi emitido para ele. Se aceitasse, qualquer serviço que recebesse o token poderia usá-lo contra todos os outros que confiam no mesmo emissor.
Então o Xokepoint chama o server com outra credencial, e qual depende de quem é o server.
Servers de fornecedor
Um server de fornecedor não conhece o Xokepoint. Ele aceita a credencial do próprio fornecedor, obtida por OAuth no cadastro do server e guardada cifrada. O executor decifra a credencial só para a chamada.
Servers do cliente
Um server escrito pelo cliente pode confiar no Xokepoint em vez de guardar um segredo próprio. Cada requisição que o Xokepoint envia a ele leva um token emitido só para aquela requisição, pelo AS do ambiente, assinado com ES256 (typ at+jwt):
| Claim | Valor |
|---|---|
iss | O AS do ambiente |
aud | A URL canônica do endpoint do server (RFC 8707): esquema e host em minúsculas, sem porta padrão, sem query nem fragmento, path como foi registrado |
sub | O sujeito |
act.sub | O agente |
chokepoint_tool | {"server_id", "name"} da tool chamada, só em tools/call |
exp | 60 segundos, nunca depois do fim do token de entrada |
Nem toda mensagem é uma tool call, e o token diz de que tipo ela é:
| Mensagem | sub | act.sub | chokepoint_tool |
|---|---|---|---|
tools/call de um agente | o sujeito | o agente | a tool |
Outras mensagens do agente (initialize, server/discover) | o sujeito | o agente | ausente |
| Descoberta pelo registry, quando o administrador conecta ou redescobre o server | chokepoint:registry | ausente | ausente |
Um tools/list do agente nunca chega ao server: o Xokepoint responde a partir das tools revisadas (Transportes e perfis). Um server que vê um token sem act deve permitir a descoberta e nada mais. Em HTTP+SSE o stream abre com um token de descoberta, e cada POST de mensagem depois leva o próprio token, como acima.
O server valida o token com o JWKS do AS, que pode ficar em cache, e confere iss, aud e exp. Com isso ele sabe quem é o usuário e qual agente está agindo, o que um server de RAG, por exemplo, precisa para filtrar documentos. O Admin mostra o issuer, a URL do JWKS e a audience no diálogo de conexão, antes de o server ser salvo, porque a primeira descoberta já envia um token (Validar o token do Xokepoint).
Esse token é a única forma de autenticação de um server do cliente. Um server que só aceita uma API key fixa não é um server do cliente para o Xokepoint: ele precisa de uma conexão de fornecedor ou não é suportado. A audience presa à URL do server é o que impede o reaproveitamento: um token emitido para um server é recusado por qualquer outro.