Contexto confiável
O que o PEP escreve em context.chokepoint e por que nenhum mapping pode mudar.
Um mapping pode vir do schema de uma tool de terceiros. Então o Xokepoint trata o mapping como entrada não confiável: ele decide qual é o recurso, mas não decide quem está pedindo nem qual tool está sendo chamada. Essas informações vêm de lugares que o PEP já verificou, e ele as escreve em context.chokepoint depois da projeção, sobrescrevendo o que o mapping tiver posto ali.
O ator é o agente de act.sub. A tool é o par MCP server e nome da tool da chamada validada. Os argumentos são os originais, já conferidos contra o schema aprovado. Os limites são os da instância (context.chokepoint.limits): vêm do authorization_details do token verificado (RFC 9396), só da entrada da tool desta chamada. Junto vão o workspace e o ambiente da chamada, a identity connection do sujeito e as revisões do catálogo usadas na validação.
Dois valores dizem como o token foi obtido:
| Campo | Valores | Origem |
|---|---|---|
context.chokepoint.subject.presence | headless (token exchange) ou interactive (harness login) | Escrito pelo AS a partir do grant que emitiu o token, nunca de um valor do cliente |
context.chokepoint.binding | dpop ou none | dpop quando o token tem cnf.jkt e a chamada trouxe uma prova DPoP válida |
Uma condição de chamada pode lê-los, por exemplo para permitir uma tool destrutiva só com uma pessoa presente (Condições).
O ator e a tool são o que o PDP usa para perguntar ao OpenFGA se o agente pode chamar a tool. Se um mapping pudesse mudar a tool, um schema malicioso faria a pergunta ser sobre uma tool inofensiva enquanto a execução chama outra. Por isso a tool da relação tool#can_call vem sempre da chamada validada, nunca do mapping.
O AuthZEN continua com o sentido padrão: subject é o sujeito, resource é o recurso. O ator, a tool e os limites ficam no contexto, controlados pelo backend.