Limites da instância (RAR)
Como uma instância em execução de um agente pede limites mais estreitos que a política, com o RFC 9396 Rich Authorization Requests.
As permissões de um agente são escritas para o agente, não para cada cópia dele que está rodando. Um agente de suporte pode ter dez instâncias abertas ao mesmo tempo, uma por ticket, e a política diz o que qualquer uma delas pode fazer: chamar refund_payment, reembolsar até USD 1.000. Algumas dessas instâncias deveriam ter menos. A que está tratando um pedido contestado de um cliente novo não deveria conseguir reembolsar mais de USD 100, mesmo que o agente consiga.
Colocar isso na política significaria uma regra por ticket. O Xokepoint faz o contrário: a instância pede os próprios limites, mais estreitos, ao obter o token, e o token os carrega. O mecanismo é o RFC 9396, Rich Authorization Requests (RAR), que adiciona um parâmetro authorization_details às requisições OAuth para o cliente descrever exatamente o que pretende fazer, em vez de uma string de scope.
Fora do Admin por enquanto
O backend aceita e confere limites de instância, mas o Admin não os oferece, porque o agente define o próprio limite no token, então não é um controle do administrador; um limite é conferido a cada chamada, sem total entre chamadas; e o login pelo harness não envia limites. Para limitar uma tool, escreva uma regra.
O pedido
A instância envia authorization_details na troca de token, como um array JSON. O Xokepoint define um único tipo, chokepoint_tool_call, com uma entrada por tool:
[
{
"type": "chokepoint_tool_call",
"server_id": "<ID do servidor>",
"tool": "refund_payment",
"limits": { "max_amount": 100 }
}
]O AS confere o formato antes de assinar qualquer coisa:
| Regra | Limite |
|---|---|
| Entradas | No máximo 16, uma por server_id e tool |
| Tool | O agente precisa poder chamá-la (tool#can_call@agent) |
limits | De 1 a 16 nomes no formato ^[a-z][a-z0-9_]{0,63}$ |
| Valores | Um número, ou uma string de no máximo 256 caracteres |
Qualquer outra coisa (um tipo desconhecido, um campo a mais, uma tool que o agente não pode chamar) é recusada com invalid_authorization_details, e nenhum token é emitido. A recusa é registrada com esse motivo e aparece no inspetor de trocas de token. O AS anuncia o tipo nos metadados como authorization_details_types_supported: ["chokepoint_tool_call"].
Limites só estreitam
Uma entrada nunca concede nada. Ela não adiciona tool, recurso nem delegação; a conferência da tool acima existe para que um limite só possa citar algo que o agente já tem. As entradas aceitas vão na resposta da troca e no JWT assinado, então um limite não pode ser aumentado editando o token: a assinatura deixaria de bater.
Cada troca é independente. Para renovar o token, a instância envia de novo os seus authorization_details. Um pedido sem o parâmetro recebe um token sem limites.
Como uma regra os usa
Numa chamada, o PEP pega os limits da entrada cujos server_id e tool batem com a chamada validada e os escreve em context.chokepoint.limits, ao lado do ator e dos argumentos. As entradas de outras tools são ignoradas, e nenhum mapeamento consegue definir ou substituir esse campo (Contexto confiável).
Uma condição de chamada lê o limite como qualquer outra entrada:
double(context.chokepoint.arguments.amount) <= double(context.chokepoint.limits.max_amount)A condição declara os limites que lê em required_limits. Se o token não tem esse limite, a condição é falsa e a chamada é negada com motivo condition. Essa diferença em relação a um fato do PIP que falta, que bloqueia com 503, é proposital: um fato que falta é uma indisponibilidade; um limite que falta é um cliente que não pediu o que a política exige.
O limite da instância soma às regras do Admin, não as substitui. Todas as condições da aresta agente · servidor · tool precisam passar, então com uma regra do Admin amount <= 1000 e um limite de instância de 100, o teto efetivo é 100. Com um limite de instância de 5000, continua 1000. O AS não compara os dois na emissão; o PDP aplica ambos em cada chamada.
O que o RAR não é aqui
O RAR costuma ser usado para o usuário aprovar uma transação específica no momento do consentimento. O Xokepoint o usa só para autorrestrição de uma instância de agente: ninguém aprova os limites, porque eles só conseguem reduzir o que já foi aprovado. Uma contagem de chamadas, como "no máximo 3 reembolsos", também não é um limite. Ela precisa de uma reserva antes da execução e de regras para falhas e janelas de tempo, e não faz parte do modelo atual (Condições).