Saltar para o conteúdo principal
Fazer allow-listing de uma ferramenta responde qual ferramenta um agente pode chamar. Não consegue responder com quais argumentos. shell.exec é fino para ls; é um desastre para rm -rf /. db.query é fino contra uma réplica; contra prod é um risco. A diferença vive nos argumentos, e uma regra de nome de ferramenta não consegue vê-la. As cláusulas de argumento do Firewall (args_match_json) fecham esse gap. Elas inspecionam os argumentos concretos que o modelo escolheu para uma chamada de ferramenta e decidem o veredito a partir de seus valores — então você pode permitir uma ferramenta amplamente enquanto nega a única forma perigosa que ela pode tomar. Esta página é o guia focado em criar essas cláusulas; para o vocabulário de regras completo veja Regras do Firewall, e para o modelo de política em torno delas, Firewall.
Os valores de argumento só existem uma vez que o modelo escolheu como chamar uma ferramenta, então as cláusulas de argumento pertencem aos stages response e mcp. Em inbound — onde o agente só anuncia definições de ferramenta — não há argumentos em tempo de chamada para verificar.

​
1. Quando validar argumentos de chamada de ferramenta

Recorra a uma cláusula de argumento sempre que uma ferramenta for segura em geral mas perigosa em uma forma específica:

Comandos destrutivos

Permita shell.exec, mas negue quando o comando corresponde a rm -rf, mkfs ou dd if=.

Raio de explosão em produção

Permita db.query, mas negue (ou retenha para aprovação) quando o alvo de conexão for prod.

Destinos internos

Permita uma ferramenta de fetch, mas negue quando seu argumento url/ip cai dentro de uma faixa RFC-1918 ou do IP de cloud-metadata.

Operações superdimensionadas

Permita uma ferramenta de bulk, mas negue quando um argumento limit ou count exceder um teto numérico.
A regra ainda corresponde ao nome da ferramenta primeiro; as cláusulas a estreitam de qual ferramenta para qual chamada.

​
2. A forma de um conjunto de cláusulas

args_match_json é uma string codificada em JSON cujo valor decodificado é um objeto contendo uma lista de clauses. Cada cláusula é um triplo { path, op, value }, e todas as cláusulas se combinam com AND — a regra dispara apenas quando cada cláusula é verdadeira. Decodificado, o valor se parece com: 
{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}
No corpo de uma regra o campo carrega esse JSON como uma única string escapada — ex.: "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Um args_match_json vazio ou ausente é vacuamente verdadeiro — a regra corresponde ao seu glob de nome de ferramenta sozinho, exatamente como uma regra só-de-nome faz.

​
3. Operadores

Sete operadores compõem o vocabulário fechado. O console valida o operador e a forma de seu valor quando você salva, então uma cláusula malformada nunca persiste.
OperadorCorresponde quando
eqIgualdade escalar (números comparados numericamente; uma incompatibilidade de tipo é sem correspondência).
containsSubstring — ambos os operandos devem ser strings.
regexUm padrão Go RE2 corresponde ao valor string (tempo linear, sem backreferences).
inO valor é um elemento do array JSON fornecido.
cidr_matchO IP string cai dentro do CIDR fornecido.
gt / ltMaior-que / menor-que numérico (strings não são coercidas).

​
4. Sintaxe de path

O path de uma cláusula é um pequeno subconjunto de JSONPath sobre o objeto de argumentos da ferramenta:
Lê um campo de objeto de nível superior ou aninhado pelo nome.
Indexa em um array, opcionalmente continuando nos campos do elemento.
Corresponde contra o blob de argumentos inteiro (útil com contains ou regex para uma varredura grossa).
Não há wildcards, filtros, slices ou descida recursiva — a gramática é deliberadamente pequena para que a correspondência permaneça de tempo linear e previsível no hot path.

​
5. Um exemplo trabalhado

Você deixa seus agentes rodarem shell.exec livremente, mas um force-delete recursivo nunca deve chegar ao shell. Crie uma regra de stage response que nega shell.exec apenas quando o argumento de comando parece destrutivo.
1

Abra o editor de regras

No console, abra a política de firewall vinculada à chave do seu agente (ou o padrão do workspace) e adicione uma regra. Editar políticas é uma ação Developer+ — Members podem ler políticas mas não escrevê-las.
2

Corresponda à ferramenta no stage response

Defina o stage como response e o glob de ferramenta como shell.exec. O stage response carrega os argumentos escolhidos pelo modelo, dos quais a cláusula precisa.
3

Adicione a cláusula de argumento

Adicione uma cláusula regex em $.command, depois defina o veredito como deny:
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm\\\\s+-rf|mkfs|dd\\\\s+if=\"}]}"
}
args_match_json é uma string codificada em JSON; seu valor decodificado é o objeto { "clauses": [ … ] } mostrado no §2.
4

Faça dry-run antes de depender dela

Use a aba Test para avaliar a regra contra uma chamada shell.exec de amostra. Ela retorna o veredito, a regra correspondente e o motivo — nada é despachado e nada é persistido.
Agora shell.exec com "command": "ls -la" flui como antes, enquanto "command": "rm -rf /var" é negado. Um deny em response deixa o modelo ver um erro de ferramenta e reagir — escolher outra ferramenta, perguntar ao usuário, ou parar — em vez de quebrar.
Quer permitir a chamada mas remover um valor vazado em vez de bloquear? Troque o veredito para sanitize. O sanitize não redige o que a cláusula correspondeu — ele roda um redator separado (presets nomeados como openai_key, anthropic_key, ssn_us, mais seus próprios regexes customizados) sobre as strings de argumento, substitui cada acerto por um token [redacted:…] e encaminha a chamada limpa. A cláusula args_match_json ainda decide se a regra dispara; o sanitizer decide o que é limpo. Veja Sanitizar argumentos. O sanitize redige apenas os argumentos da chamada de ferramenta — nunca o conteúdo que uma ferramenta retorna.

​
6. As cláusulas falham fechadas — a regra, não a requisição

Se uma cláusula não pode ser avaliada — o path não resolve, os argumentos são malformados, ou um regex / CIDR é inválido — a cláusula avalia para false e a regra simplesmente não dispara. A chamada cai para a próxima regra ou o default_verdict da política. Uma cláusula quebrada nunca auto-nega e nunca perturba o relay.
Porque uma cláusula que não pode avaliar faz sua regra não corresponder, nunca se apoie em uma cláusula para falhar de uma maneira particular. Crie sua regra de “capturar tudo perigoso” como um deny explícito com seu próprio glob de ferramenta, e use cláusulas de argumento para estreitar uma permissão — não como sua última linha de defesa.

​
7. Combinando cláusulas com o resto de uma regra

As cláusulas de argumento se empilham com tudo o mais que uma regra expressa — elas são uma condição combinada com AND entre várias:
Combine comEfeito
tool_name_globA cláusula só roda uma vez que o nome da ferramenta corresponde — nome primeiro, argumentos depois.
skill_name_globControle os argumentos da mesma ferramenta de forma diferente por skill proprietária (ex.: mais estrito em community.*).
verdictCombine cláusulas com deny, sanitize, pending_approval ou cap_cost, não apenas deny.
Múltiplas cláusulasTodas devem valer — combine uma verificação regex de comando com uma verificação in de ambiente para dar escopo apertado a um deny.
Para a semântica precisa de veredito que cada combinação produz, veja Vereditos; para como uma chamada retida resolve, veja Aprovações.

​
8. Onde isso se encaixa

Regras do Firewall

A referência de regras completa — globs, cláusulas, sanitizers, egress e sequências.

Cookbook de argumentos

Receitas args_match_json para copiar-colar das formas perigosas comuns.

Stages do firewall

Por que cláusulas de argumento vivem em response e mcp, não em inbound.

Bloquear ferramentas

Negue uma ferramenta totalmente quando nenhum argumento é seguro.
Para o quadro mais amplo, veja Chamadas de ferramenta perigosas e Como o OrcaRouter inspeciona.