Vai al contenuto principale
Mettere in allowlist un tool risponde a quale tool un agent può chiamare. Non può rispondere con quali argomenti. shell.exec va bene per ls; è un disastro per rm -rf /. db.query va bene contro una replica; contro prod è un rischio. La differenza vive negli argomenti, e una regola sul nome del tool non può vederla. Le clausole sugli argomenti del Firewall (args_match_json) colmano quel gap. Ispezionano gli argomenti concreti che il modello ha scelto per una chiamata a tool e decidono il verdetto dai loro valori — così puoi permettere un tool in modo ampio negando l’unica forma pericolosa che può assumere. Questa pagina è la guida focalizzata alla scrittura di quelle clausole; per il vocabolario completo delle regole vedi Regole del Firewall, e per il modello di policy che le circonda, Firewall.
I valori degli argomenti esistono solo una volta che il modello ha scelto come chiamare un tool, quindi le clausole sugli argomenti appartengono agli stage response e mcp. Su inbound — dove l’agent pubblicizza solo le definizioni dei tool — non ci sono argomenti al momento della chiamata da controllare.

​
1. Quando validare gli argomenti delle chiamate a tool

Ricorri a una clausola sugli argomenti ogni volta che un tool è sicuro in generale ma pericoloso in una forma specifica:

Comandi distruttivi

Consenti shell.exec, ma nega quando il comando corrisponde a rm -rf, mkfs o dd if=.

Raggio d'impatto su produzione

Consenti db.query, ma nega (o metti in attesa di approvazione) quando il target della connessione è prod.

Destinazioni interne

Consenti un fetch tool, ma nega quando il suo argomento url/ip cade dentro un range RFC-1918 o l’IP cloud-metadata.

Operazioni sovradimensionate

Consenti un tool bulk, ma nega quando un argomento limit o count supera un tetto numerico.
La regola fa comunque matching sul nome del tool per prima cosa; le clausole la restringono da quale tool a quale chiamata.

​
2. La forma di un insieme di clausole

args_match_json è una stringa codificata in JSON il cui valore decodificato è un oggetto che contiene un elenco di clauses. Ogni clausola è una tripla { path, op, value }, e tutte le clausole sono in AND — la regola scatta solo quando ogni clausola è vera. Decodificato, il valore appare così: 
{
  "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" }
  ]
}
In un corpo di regola il campo porta quel JSON come una singola stringa con escape — es. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Un args_match_json vuoto o assente è vacuamente vero — la regola fa matching sul suo glob del nome del tool da solo, esattamente come fa una regola con solo il nome.

​
3. Operatori

Sette operatori compongono il vocabolario chiuso. La console valida l’operatore e la forma del suo valore al salvataggio, così una clausola malformata non persiste mai.
OperatoreCorrisponde quando
eqUguaglianza scalare (i numeri confrontati numericamente; un mismatch di tipo è un non-match).
containsSottostringa — entrambi gli operandi devono essere stringhe.
regexUn pattern Go RE2 corrisponde al valore stringa (tempo lineare, niente backreference).
inIl valore è un elemento dell’array JSON dato.
cidr_matchL’IP stringa cade dentro il CIDR dato.
gt / ltMaggiore-di / minore-di numerico (le stringhe non vengono convertite).

​
4. Sintassi del path

Il path di una clausola è un piccolo sottoinsieme di JSONPath sull’oggetto degli argomenti del tool:
Legge un campo di oggetto di primo livello o annidato per nome.
Indicizza un array, continuando opzionalmente nei campi dell’elemento.
Fa matching sull’intero blob degli argomenti (utile con contains o regex per una scansione grossolana).
Non ci sono wildcard, filtri, slice o discesa ricorsiva — la grammatica è deliberatamente piccola così il matching resta a tempo lineare e prevedibile sul percorso caldo.

​
5. Un esempio svolto

Lasci che i tuoi agent eseguano shell.exec liberamente, ma un force-delete ricorsivo non dovrebbe mai raggiungere la shell. Scrivi una regola di stage response che neghi shell.exec solo quando l’argomento del comando appare distruttivo.
1

Apri l'editor delle regole

Nella console, apri la policy del firewall collegata alla chiave del tuo agent (o il default del workspace) e aggiungi una regola. Modificare le policy è un’azione Developer+ — i Member possono leggere le policy ma non scriverle.
2

Fai matching sul tool nello stage response

Imposta lo stage su response e il glob del tool su shell.exec. Lo stage response porta gli argomenti scelti dal modello, di cui la clausola ha bisogno.
3

Aggiungi la clausola sugli argomenti

Aggiungi una clausola regex su $.command, poi imposta il verdetto su 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 è una stringa codificata in JSON; il suo valore decodificato è l’oggetto { "clauses": [ … ] } mostrato in §2.
4

Esegui un dry-run prima di farci affidamento

Usa la scheda Test per valutare la regola contro una chiamata shell.exec di esempio. Restituisce il verdetto, la regola corrispondente e la motivazione — nulla viene dispatchato e nulla viene persistito.
Ora shell.exec con "command": "ls -la" scorre come prima, mentre "command": "rm -rf /var" viene negato. Un deny su response lascia che il modello veda un errore di tool e reagisca — scegliere un altro tool, chiedere all’utente o fermarsi — anziché andare in crash.
Vuoi permettere la chiamata ma rimuovere un valore trapelato invece di bloccare? Cambia il verdetto in sanitize. Sanitize non redige ciò che la clausola ha corrisposto — esegue un redactor separato (preset nominati come openai_key, anthropic_key, ssn_us, più le tue regex custom) sulle stringhe degli argomenti, sostituisce ogni hit con un token [redacted:…] e inoltra la chiamata ripulita. La clausola args_match_json decide comunque se la regola scatta; il sanitizer decide cosa viene ripulito. Vedi Sanitizza gli argomenti. Sanitize redige solo gli argomenti della chiamata a tool — mai il contenuto che un tool restituisce.

​
6. Le clausole fanno fail closed — la regola, non la richiesta

Se una clausola non può essere valutata — il path non si risolve, gli argomenti sono malformati, o una regex / CIDR è invalida — la clausola valuta a false e la regola semplicemente non scatta. La chiamata ricade sulla regola successiva o sul default_verdict della policy. Una clausola rotta non auto-nega mai e non disturba mai il relay.
Poiché una clausola che non può essere valutata fa non corrispondere la sua regola, non fare mai affidamento su una clausola per fallire in un modo particolare. Scrivi la tua regola “cattura tutto ciò che è pericoloso” come un deny esplicito con il proprio glob del tool, e usa le clausole sugli argomenti per restringere un permesso — non come la tua ultima linea di difesa.

​
7. Combinare le clausole con il resto di una regola

Le clausole sugli argomenti si impilano con tutto il resto che una regola esprime — sono una condizione in AND tra diverse:
Combina conEffetto
tool_name_globLa clausola gira solo una volta che il nome del tool corrisponde — prima il nome, poi gli argomenti.
skill_name_globGoverna gli argomenti dello stesso tool diversamente in base alla skill proprietaria (es. più severo su community.*).
verdictAbbina le clausole a deny, sanitize, pending_approval o cap_cost, non solo deny.
Più clausoleTutte devono valere — combina un controllo regex sul comando con un controllo in sull’ambiente per dare scope stretto a un deny.
Per la precisa semantica dei verdetti che ciascun abbinamento produce, vedi Verdetti; per come si risolve una chiamata messa in attesa, vedi Approvazioni.

​
8. Dove si inserisce

Regole del Firewall

Il riferimento completo delle regole — glob, clausole, sanitizer, egress e sequenze.

Ricettario degli argomenti

Ricette args_match_json copia-incolla per le forme pericolose comuni.

Stage del firewall

Perché le clausole sugli argomenti vivono su response e mcp, non inbound.

Blocca i tool

Nega un tool del tutto quando nessun argomento è sicuro.
Per il quadro più ampio, vedi Chiamate a tool pericolose e Come OrcaRouter ispeziona.