Saltar al contenido principal
Poner una herramienta en lista de permitidos responde qué herramienta puede llamar un agente. No puede responder con qué argumentos. shell.exec está bien para ls; es un desastre para rm -rf /. db.query está bien contra una réplica; contra prod es un riesgo. La diferencia vive en los argumentos, y una regla de nombre de herramienta no puede verla. Las cláusulas de argumentos del Firewall (args_match_json) cierran ese hueco. Inspeccionan los argumentos concretos que el modelo eligió para una llamada a herramienta y deciden el veredicto a partir de sus valores — así que puedes permitir una herramienta de forma amplia mientras deniegas la única forma peligrosa que puede tomar. Esta página es la guía enfocada a autorar esas cláusulas; para el vocabulario de reglas completo ver Reglas del Firewall, y para el modelo de política a su alrededor, Firewall.
Los valores de los argumentos solo existen una vez que el modelo ha elegido cómo llamar a una herramienta, así que las cláusulas de argumentos pertenecen a las etapas response y mcp. En inbound — donde el agente solo anuncia definiciones de herramienta — no hay argumentos en tiempo de llamada que verificar.

​
1. Cuándo validar argumentos de llamadas a herramienta

Recurre a una cláusula de argumentos cuando una herramienta es segura en general pero peligrosa en una forma específica:

Comandos destructivos

Permite shell.exec, pero deniega cuando el comando coincide con rm -rf, mkfs o dd if=.

Radio de explosión en producción

Permite db.query, pero deniega (o retén para aprobación) cuando el objetivo de conexión es prod.

Destinos internos

Permite una herramienta de fetch, pero deniega cuando su argumento url/ip cae dentro de un rango RFC-1918 o la IP de metadatos de nube.

Operaciones sobredimensionadas

Permite una herramienta masiva, pero deniega cuando un argumento limit o count excede un techo numérico.
La regla aún coincide primero sobre el nombre de la herramienta; las cláusulas la estrechan de qué herramienta a qué llamada.

​
2. La forma de un conjunto de cláusulas

args_match_json es un string codificado en JSON cuyo valor decodificado es un objeto que contiene una lista de clauses. Cada cláusula es un triple { path, op, value }, y todas las cláusulas se conjugan con AND — la regla se dispara solo cuando cada cláusula es verdadera. Decodificado, el valor se ve así: 
{
  "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" }
  ]
}
En un cuerpo de regla el campo lleva ese JSON como un único string escapado — p. ej. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Un args_match_json vacío o ausente es vacuamente verdadero — la regla coincide solo sobre su glob de nombre de herramienta, exactamente como lo hace una regla de solo nombre.

​
3. Operadores

Siete operadores conforman el vocabulario cerrado. La consola valida el operador y la forma de su valor al guardar, así que una cláusula malformada nunca se persiste.
OperadorCoincide cuando
eqIgualdad escalar (los números se comparan numéricamente; una discordancia de tipo es sin coincidencia).
containsSubcadena — ambos operandos deben ser strings.
regexUn patrón Go RE2 coincide con el valor string (tiempo lineal, sin retro-referencias).
inEl valor es un elemento del array JSON dado.
cidr_matchLa IP string cae dentro del CIDR dado.
gt / ltMayor-que / menor-que numérico (los strings no se coaccionan).

​
4. Sintaxis de path

El path de una cláusula es un pequeño subconjunto de JSONPath sobre el objeto de argumentos de la herramienta:
Lee un campo de objeto de nivel superior o anidado por nombre.
Indexa en un array, opcionalmente continuando hacia los campos del elemento.
Coincide contra el blob de argumentos entero (útil con contains o regex para un escaneo grueso).
No hay comodines, filtros, slices ni descenso recursivo — la gramática es deliberadamente pequeña para que la coincidencia se mantenga en tiempo lineal y predecible en la ruta caliente.

​
5. Un ejemplo trabajado

Dejas que tus agentes ejecuten shell.exec libremente, pero un borrado forzado recursivo nunca debería llegar al shell. Autora una regla de etapa response que deniega shell.exec solo cuando el argumento de comando se ve destructivo.
1

Abre el editor de reglas

En la consola, abre la política de firewall adjunta a la clave de tu agente (o el valor por defecto del espacio de trabajo) y añade una regla. Editar políticas es una acción Developer+ — los Members pueden leer políticas pero no escribirlas.
2

Coincide la herramienta en la etapa response

Establece la etapa a response y el glob de herramienta a shell.exec. La etapa response lleva los argumentos elegidos por el modelo, que la cláusula necesita.
3

Añade la cláusula de argumentos

Añade una cláusula regex sobre $.command, luego establece el veredicto a 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 es un string codificado en JSON; su valor decodificado es el objeto { "clauses": [ … ] } mostrado en §2.
4

Ejecútala en seco antes de depender de ella

Usa la pestaña Test para evaluar la regla contra una llamada shell.exec de muestra. Devuelve el veredicto, la regla coincidente y la razón — nada se despacha y nada se persiste.
Ahora shell.exec con "command": "ls -la" fluye como antes, mientras "command": "rm -rf /var" se deniega. Un deny en response deja que el modelo vea un error de herramienta y reaccione — elegir otra herramienta, preguntar al usuario o detenerse — en vez de fallar.
¿Quieres permitir la llamada pero quitar un valor filtrado en vez de bloquear? Cambia el veredicto a sanitize. Sanitize no redacta lo que la cláusula coincidió — ejecuta un redactor separado (presets nombrados como openai_key, anthropic_key, ssn_us, más tus propios regex personalizados) sobre los strings de los argumentos, reemplaza cada coincidencia con un token [redacted:…] y reenvía la llamada limpia. La cláusula args_match_json aún decide si la regla se dispara; el saneador decide qué se limpia. Ver Sanear argumentos. Sanitize redacta solo los argumentos de la llamada a herramienta — nunca el contenido que una herramienta devuelve.

​
6. Las cláusulas fallan cerradas — la regla, no la solicitud

Si una cláusula no se puede evaluar — el path no resuelve, los argumentos están malformados, o un regex / CIDR es inválido — la cláusula evalúa a falso y la regla simplemente no se dispara. La llamada cae a la siguiente regla o al default_verdict de la política. Una cláusula rota nunca auto-deniega y nunca perturba el relay.
Como una cláusula que no puede evaluar hace que su regla no coincida, nunca te apoyes en una cláusula para fallar de una forma particular. Autora tu regla de “capturar todo lo peligroso” como un deny explícito con su propio glob de herramienta, y usa cláusulas de argumentos para estrechar un permiso — no como tu última línea de defensa.

​
7. Combinar cláusulas con el resto de una regla

Las cláusulas de argumentos se apilan con todo lo demás que una regla expresa — son una condición conjugada con AND entre varias:
Combina conEfecto
tool_name_globLa cláusula solo se ejecuta una vez que el nombre de la herramienta coincide — nombre primero, argumentos segundo.
skill_name_globGobierna los argumentos de la misma herramienta de forma diferente según la skill propietaria (p. ej. más estricto en community.*).
verdictCombina cláusulas con deny, sanitize, pending_approval o cap_cost, no solo deny.
Múltiples cláusulasTodas deben cumplirse — combina una verificación regex de comando con una verificación in de entorno para acotar un deny estrechamente.
Para la semántica de veredicto precisa que cada combinación produce, ver Veredictos; para cómo se resuelve una llamada retenida, ver Aprobaciones.

​
8. Dónde encaja esto

Reglas del Firewall

La referencia de reglas completa — globs, cláusulas, saneadores, egress y secuencias.

Recetario de argumentos

Recetas args_match_json de copiar y pegar para las formas peligrosas comunes.

Etapas del firewall

Por qué las cláusulas de argumentos viven en response y mcp, no en inbound.

Bloquear herramientas

Deniega una herramienta de plano cuando ningún argumento es seguro.
Para el panorama más amplio, ver Llamadas a herramienta peligrosas y Cómo inspecciona OrcaRouter.