Saltar al contenido principal
Nombrar una herramienta y denegarla es contundente: mata la herramienta para cada llamada. La mayoría de las veces la herramienta está bien y una forma de llamada es el problema — shell.exec está bien hasta que el comando es rm -rf, db.query está bien hasta que golpea prod. Esa distinción es lo que expresa una cláusula de argumentos: un predicado de argumento de herramienta con jsonpath que coincide sobre los valores que un agente pasa, así que el veredicto se dispara solo en la llamada peligrosa y deja el resto en paz. Esta página es un recetario — un puñado de recetas args_match_json de copiar y pegar para los casos que surgen con más frecuencia. Para la gramática de cláusulas completa, la tabla de operadores y la semántica de fallo cerrado, ver Validar argumentos y la referencia de Esquema de regla.

1. Cómo funciona una cláusula de argumento de herramienta con jsonpath

El args_match_json de una regla es un string codificado en JSON que lleva un conjunto de cláusulas, todas conjugadas con AND. El valor decodificado es un objeto, {"clauses": [ … ]}, donde cada cláusula es un triple { path, op, value }:
  • path — un pequeño subconjunto de JSONPath sobre el objeto de argumentos de la herramienta: $.command, $.foo.bar, $.items[0], o $ para el objeto completo. Sin comodines, filtros, slices ni descenso recursivo.
  • op — uno de un conjunto cerrado: eq, contains, regex, in, cidr_match, gt, lt.
  • value — el literal con el que comparar (un string, número, bool, o — para in — un array JSON).
Una cláusula se conjuga con AND sobre el tool_name_glob de la regla: la regla se dispara solo cuando el nombre de la herramienta coincide y cada cláusula se cumple. Omite args_match_json por completo (o déjalo un "{}" vacío) y la regla coincide solo sobre el glob.
Las cláusulas fallan cerradas — la regla, no la solicitud. Si un path no resuelve, los argumentos están malformados, o un valor es del tipo equivocado, la cláusula evalúa falso y la regla simplemente no se dispara — la llamada cae a la siguiente regla o al veredicto por defecto. Una cláusula rota nunca auto-deniega. Escribe tu respaldo duro como un deny de glob simple, no como una cláusula en la que te apoyas para fallar de cierta forma.

2. Receta: bloquear un comando destructivo

El caso canónico. Permite shell.exec en general, deniégalo solo cuando el comando se ve destructivo. Una cláusula regex sobre $.command lo logra:
{
  "label": "block destructive shell commands",
  "tool_name_glob": "*.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Los regex son Go RE2 — tiempo lineal, sin retro-referencias, sin retroceso catastrófico — así que son seguros de ejecutar en cada llamada a herramienta. Un $.command no string (o uno ausente) nunca coincide, así que una llamada malformada cae en vez de ser bloqueada erróneamente.
Prefiere contains sobre regex cuando estés coincidiendo una subcadena fija — es más simple de leer y no puede tropezar con un metacarácter sin escapar. Recurre a regex solo cuando genuinamente necesites alternación o anclas.

3. Receta: denegar una herramienta contra un entorno nombrado

Deja que db.query se ejecute, pero solo contra conexiones seguras — deniégalo cuando el objetivo es prod o una replica. El operador in coincide el valor resuelto contra cualquier elemento de un array JSON:
{
  "label": "no agent queries against prod",
  "tool_name_glob": "db.query",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.connection\",\"op\":\"in\",\"value\":[\"prod\",\"replica\"]}]}"
}
El valor de in debe ser un array JSON — un no-array se rechaza cuando guardas la regla. Los elementos comparan con igualdad escalar, así que los números y los strings coinciden cada uno con su propio tipo.

4. Receta: denegar un destino de IP privada o metadatos

Cuando una herramienta toma una IP objetivo como argumento, cidr_match prueba si cae dentro de un CIDR — la forma SSRF de “un agente recuperando 10.x o la dirección de metadatos de nube”:
{
  "label": "deny tool calls aimed at RFC-1918",
  "tool_name_glob": "*",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.target_ip\",\"op\":\"cidr_match\",\"value\":\"10.0.0.0/8\"}]}"
}
El valor del argumento debe parsearse como un literal de IP que se sitúa dentro del CIDR; un nombre de host o un string no-IP nunca coincide.
cidr_match solo inspecciona un valor que ya está en los argumentos de la herramienta. Para gobernar el destino que una herramienta realmente alcanza en la capa de red — listas de permitidos y denegados de host/CIDR — usa una regla de egress dedicada en la superficie egress en su lugar. Las dos son complementarias: inspección de argumentos a la entrada, control de egress a la salida.

5. Receta: limitar un argumento numérico

gt y lt comparan números. Úsalos para rechazar un tamaño de lote absurdo, un límite sobredimensionado o cualquier conteo descontrolado — aquí, denegar un borrado masivo que apunta a más de 100 filas:
{
  "label": "block large bulk deletes",
  "tool_name_glob": "*.bulk_delete",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.count\",\"op\":\"gt\",\"value\":100}]}"
}
Ambos lados deben ser números — un string que parece numérico como "500" es una discordancia de tipo y no coincide, así que la regla no se disparará sobre un argumento tipado como string. Mantén el argumento numérico, o normalízalo antes de que la herramienta lo vea.

6. Receta: combinar cláusulas (AND)

Todas las cláusulas en una regla se conjugan con AND, así que puedes estrechar un veredicto a una llamada muy específica — por ejemplo, denegar shell.exec solo cuando es un comando destructivo y apunta a un host prod:
{
  "label": "destructive shell on a prod host",
  "tool_name_glob": "*.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"},{\"path\":\"$.host\",\"op\":\"in\",\"value\":[\"db-prod-1\",\"db-prod-2\"]}]}"
}
¿Necesitas un OR en su lugar? No hay OR dentro de un solo args_match_json — autora dos reglas (o dos globs) en prioridades diferentes. El motor recorre las reglas en orden de prioridad y gana la primera coincidencia, así que pon las reglas estrechas primero. Ver Prioridad de reglas.

7. Elige el veredicto para la forma coincidente

Una cláusula decide qué llamadas coinciden; el verdict de la regla decide qué pasa. deny es el valor por defecto del recetario, pero la misma cláusula puede llevar un veredicto más suave:
Cuando el argumento coincidente lleva un secreto o PII en vez de una instrucción peligrosa, sanitize redacta las subcadenas coincidentes de los argumentos de la herramienta y reenvía la llamada limpia. Redacta solo argumentos — nunca el contenido que una herramienta devuelve. Ver Sanear respuestas.
Retén exactamente la forma arriesgada para revisión en vez de bloquearla de plano: un revisor aprueba o rechaza fuera de banda, y el agente reenvía la llamada aprobada una vez. Ver Aprobaciones.
Establece el veredicto a audit para registrar la llamada coincidente sin bloquear mientras afinas la cláusula. Combina con modo shadow para medir un deny contra tráfico en vivo antes de que cambie nada.

8. Prueba la cláusula antes de depender de ella

La pestaña Test de la consola ejecuta en seco una política contra una llamada a herramienta de muestra y devuelve el veredicto, la regla coincidente y la razón — nada se despacha, nada se persiste. Pega un objeto de argumentos realista y confirma que la cláusula se dispara en las llamadas que pretendes y solo esas, ya que una cláusula que no puede resolver un valor silenciosamente no se dispara. Ver Probar reglas.
Las cláusulas se validan estrictamente al guardar — operadores desconocidos, paths malos, un valor in que no es array, un regex no compilable y CIDRs inválidos se rechazan todos, así que una cláusula malformada no se puede persistir en primer lugar.

9. Quién puede autorar cláusulas de argumentos

Todo esto se ejecuta en la consola bajo tu sesión (/api/workspace/firewall/*):
AcciónRol
Leer políticas, presets, herramientas descubiertasMember
Crear / editar / eliminar reglasDeveloper+
Sandbox de Test (ejecutar en seco una política)Developer+
Leer eventos y agregados de ejecucionesDeveloper+
Autorar o cambiar una cláusula de argumentos es una escritura Developer+. El sandbox de Test también es Developer+ — puede previsualizar contra una política en borrador y su traza de veredicto expone nombres de política y etiquetas de regla, así que se sitúa en el lado de escritura de la línea, no en el de lectura.

Relacionado

Validar argumentos

El caso de uso de coincidencia de argumentos completo.

Bloquear herramientas

Deniega una herramienta entera por nombre — sin cláusula necesaria.

Control de egress

Gobierna destinos salientes de host / IP / CIDR.

Esquema de regla

Cada campo que una regla puede llevar.

Prioridad de reglas

Gana la primera coincidencia — ordena estrecho antes que amplio.

Llamadas a herramienta peligrosas

La amenaza que abordan estas recetas.