Saltar al contenido principal
Una política de firewall es una lista ordenada de reglas, y una regla es solo una pequeña bolsa de campos: a qué llamadas a herramienta coincide, en qué superficie, y qué hacer al respecto. Cuando necesitas leer una regla que alguien más escribió — o razonar con precisión sobre una que estás construyendo — quieres la lista de campos en un solo lugar. Esa es esta página. Autoras reglas en el editor de reglas de la consola (las escrituras requieren Developer+); el editor escribe los campos estructurados de abajo. Esta página es el mapa a nivel de campo; el motor de coincidencia profundo vive en Reglas del Firewall.

​
1. El esquema de regla del firewall de un vistazo

Cada regla lleva los mismos campos. Solo verdict es siempre requerido — todo lo demás estrecha qué coincide la regla o configura el veredicto elegido, y un coincidente ausente es vacuamente verdadero.
CampoPropósito
priorityOrden de evaluación — el más bajo se ejecuta primero.
verdictLa acción cuando la regla coincide (requerido).
stageLa superficie a la que acotar; vacío = todas.
tool_name_globGlob sobre el nombre de la herramienta.
args_match_jsonPredicado de argumentos JSONPath, como string codificado en JSON.
egress_jsonLista de permitidos-denegados de host / CIDR (reglas de egress), como string codificado en JSON.
sanitize_jsonConfiguración de redacción (cuando verdict = sanitize), como string codificado en JSON.
cap_cost_centsTecho de coste de ejecución en centavos de USD (cuando verdict = cap_cost).
sequence_jsonPredicado de cadena de varios pasos ordenada (reglas de secuencia), como string codificado en JSON.
label / notesNombre humano y justificación — mostrados en eventos, ignorados por el motor.
Una regla se dispara cuando todos sus coincidentes declarados se cumplen a la vez — la etapa coincide (o está vacía), el glob de herramienta coincide, las cláusulas de argumentos coinciden (o están ausentes), y el alcance de egress coincide (solo reglas de egress). El motor recorre las reglas en orden de prioridad y gana la primera coincidencia; si nada coincide, aplica el default_verdict de la política.

​
2. priority — orden de evaluación

Un ordinal entero. El más bajo se ejecuta primero; dos reglas con la misma prioridad rompen el empate por id de regla (orden de inserción). Pon tus excepciones específicas por encima de tus capturadores amplios — un allow para una herramienta confiable en priority 10 supera un deny * en priority 100.
Deja huecos (10, 20, 30) para poder insertar una regla nueva entre dos existentes después sin renumerar toda la política. Ver Prioridad de reglas para estrategia de ordenamiento.

​
3. verdict — la acción

El único campo requerido. Cuando una regla coincide, su veredicto decide qué le pasa a la llamada:
VeredictoEfecto
allowDeja pasar la llamada, registrada.
auditPermite y registra para revisión — el default_verdict habitual.
denyBloquea la llamada.
sanitizeRedacta las subcadenas coincidentes de los argumentos de la herramienta, luego reenvía.
pending_approvalRetiene la llamada para un revisor humano.
cap_costDeniega una vez que el gasto acumulado de una ejecución de agente cruza un tope.
Un deny devuelve HTTP 400 firewall_blocked en la superficie inbound, o un error de herramienta en la superficie mcp. Una llamada retenida devuelve HTTP 400 firewall_approval_pending con un id sobre el que el agente hace polling. En modo shadow cada veredicto de aplicación se degrada a audit y la razón se prefija con [shadow] would …. Ver Veredictos para la tabla completa y las formas de bloqueo.

​
4. stage — la superficie de aplicación

Fija la regla a una de las superficies del firewall. Déjala vacía y la regla aplica a todas las superficies:
Las herramientas que un agente anuncia al modelo en la solicitud. Bloquea una herramienta peligrosa antes de que el modelo pueda siquiera elegirla.
Los tool_calls que el modelo emite en su respuesta.
Un tools/call enrutado a través del gateway MCP del Firewall.
Un host / IP / CIDR saliente que una herramienta alcanza — la superficie de SSRF y exfiltración de datos.
Algunas combinaciones de veredicto + etapa se rechazan al guardar porque el veredicto no puede dispararse ahí: cap_cost es un techo de coste de ejecución previo al despacho, inerte en response y egress; pending_approval solo retiene en inbound, así que una fijación explícita a response/egress se rechaza. El editor oculta estas combinaciones; la API las rechaza. Ver Etapas.

​
5. tool_name_glob — qué herramienta

Un glob pequeño y sensible a mayúsculas sobre el nombre de la herramienta — shell.* para toda una familia, *.delete para un verbo a través de servidores, http_fetch para una herramienta exacta. Vacío o * coincide con cada herramienta. Un glob de nombre de skill opcional (misma gramática) conjuga una segunda condición sobre la skill propietaria, así que puedes confiar en una herramienta de una skill integrada y gobernarla desde una de la comunidad. La gramática completa — prefijo, sufijo, infijo, exacto, y los bordes que hacen tropezar a la gente — es su propia referencia: Sintaxis de patrones glob.

​
6. args_match_json — con qué argumentos

El glob responde qué herramienta; args_match_json responde con qué argumentos — la diferencia entre “bloquear shell.exec” y “bloquear shell.exec solo cuando el comando es rm -rf”. Su valor es un string codificado en JSON que lleva un conjunto de cláusulas JSONPath, todas conjugadas con AND. Decodificado, el objeto de cláusulas 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 solicitud el campo lleva ese objeto como un string escapado, p. ej. "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". Los operadores son eq, contains, regex, in, cidr_match, gt y lt. Un args_match_json ausente es vacuamente verdadero — la regla coincide solo sobre el glob. El lenguaje de predicado completo, la sintaxis de path, y el comportamiento de fallo cerrado de una cláusula rota están en Validar argumentos y el recetario de argumentos.

​
7. egress_json — qué destinos

Usado en la superficie egress: un string codificado en JSON que contiene una lista de permitidos-y-denegados de host / CIDR coincidida contra un destino saliente que una herramienta alcanza. Decodificado, el objeto se ve así: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Las entradas coinciden como un CIDR, un literal de IP o un nombre de host insensible a mayúsculas. La polaridad sigue al veredicto — con un veredicto de aplicación la lista deny define qué se bloquea y allow talla excepciones de ella.
La plantilla de firewall Baseline incluye una regla de denegación de egress con una lista de denegados de SSRF / metadatos de nube lista para usar (la IP de metadatos 169.254.169.254, rangos RFC-1918, loopback, link-local, y metadata.google.internal), así que no tienes que autorar esos a mano. Añade tus propios destinos encima para cualquier otra cosa que quieras gobernar. Ver Control de egress para la receta completa y Exfiltración de datos para por qué importa.

​
8. sanitize_json — redactar argumentos

Usado cuando verdict = sanitize: un string codificado en JSON que nombra qué presets / regex personalizados redactan las subcadenas coincidentes de los argumentos de la herramienta antes de que la llamada limpia se reenvíe — útil para quitar un secreto o un valor PII que un agente soltó en un argumento sin bloquear toda la acción. Decodificado, el objeto se ve así: 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Sanitize redacta solo argumentos — nunca el contenido que una herramienta devuelve. Una regla de sanitize debe nombrar al menos un preset o patrón personalizado (un saneador vacío se rechaza). En la superficie inbound no hay argumentos en tiempo de llamada que redactar, así que un veredicto sanitize ahí escala a un deny.
Ver Sanear respuestas para la biblioteca de presets y las formas de redacción.

​
9. cap_cost_cents — un techo de gasto

Usado cuando verdict = cap_cost: un techo de coste de ejecución por regla, un entero en centavos de USD. Cuando la regla coincide, la llamada se deniega una vez que el gasto acumulado de la ejecución del agente cruza el tope — un interruptor de circuito para un bucle descontrolado, resolviendo a allow o deny en los eventos. El tope debe ser explícito y no negativo, y la regla no se puede fijar a response o egress (donde el veredicto es inerte). Comportamiento completo en Limitar coste.

​
10. Una regla completa

Juntando los campos — denegar shell.exec, pero solo cuando el comando se ve destructivo, acotado a las llamadas a herramienta emitidas por el modelo: 
{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}
La etapa coincide con la superficie response, el glob elige shell.exec, la única cláusula estrecha a un comando destructivo, y el veredicto deniega. Cualquier shell.exec cuyo comando no coincida con el regex cae a la siguiente regla o al valor por defecto de la política. Adjunta una clave a la política (firewall_policy_id en la clave) y está en vivo en la siguiente llamada — sin redespliegue.
Confirma que una regla se dispara en exactamente lo que esperas antes de depender de ella: Probar reglas ejecuta en seco una política contra una llamada a herramienta de muestra y devuelve el veredicto, la regla coincidente y la razón sin despachar nada.

​
11. Cómo se combinan los campos

Un verdict. Todo lo demás es opcional: una stage vacía coincide con todas las superficies, un tool_name_glob vacío (o *) coincide con cada herramienta, y un args_match_json ausente coincide con cualquier argumento. Un { "verdict": "audit" } pelado es un capturador válido.
Conjugan con AND. Una regla se dispara solo cuando su etapa, glob de herramienta, glob de skill, cláusulas de argumentos y alcance de egress todos se cumplen. Para expresar OR, escribe reglas separadas.
sanitize_json se lee solo para el veredicto sanitize; cap_cost_cents solo para cap_cost; egress_json solo en la superficie egress. La consola valida estas combinaciones al guardar, así que una regla que muestra un comportamiento pero nunca puede aplicarlo no se puede persistir.
La priority más baja gana (empates rotos por id de regla) — gana la primera coincidencia, y la evaluación se detiene ahí. Ver Prioridad de reglas.

​
Relacionado

Crear una política

Autora tu primera política y adjunta una clave.

Sintaxis glob

La gramática de glob de nombre de herramienta completa.

Veredictos

Cada veredicto y cómo se ve un bloqueo.

Validar argumentos

Cláusulas de argumentos JSONPath en profundidad.

Gestionar políticas

Edita, versiona y revierte políticas.

Reglas del Firewall

La referencia completa del motor de coincidencia.
¿Nuevo en el plano de acción? Empieza en la Visión general del Firewall, o ve cómo se empareja con el examen de texto en Guardrails vs Firewall.