Saltar al contenido principal
Una política de firewall es una lista ordenada de reglas. Esta página es la referencia completa de lo que una regla puede expresar — el lenguaje de coincidencia, los veredictos y cómo el motor los evalúa. Las reglas se autoran en el editor de reglas de la consola, que escribe objetos de coincidencia JSON estructurados. Todo lo de abajo describe ese vocabulario para que puedas leer, razonar sobre y verificar una regla con precisión — ya sea que la construyas en la UI o la postees a través de la API.

​
1. Anatomía de una regla

CampoTipoSignificado
priorityintLa menor se ejecuta primero. Los empates se rompen por id de regla.
labelstringNombre humano, mostrado en eventos y auditoría.
stageenumLa superficie — inbound / response / mcp / egress. Vacío = todas las superficies.
tool_name_globstringGlob sobre el nombre de la herramienta.
skill_name_globstringGlob opcional sobre la skill propietaria. Se hace AND con el glob de herramienta; vacío = cualquier skill.
verdictenumLa acción — ver §7.
args_matchobjectPredicado de argumentos opcional.
sanitizeobjectConfiguración de redacción, usada cuando verdict = sanitize. Ver §5.
egressobjectLista de allow/deny de host/CIDR, usada cuando stage = egress. Ver §6.
cap_cost_centsintTecho de coste de ejecución, usado cuando verdict = cap_cost.
sequenceobjectCoincidencia ordenada de varios pasos, aplicada de forma reactiva. Ver §8.
notesstringJustificación del autor; ignorada por el motor.
Una regla coincide con una llamada a herramienta cuando todas sus condiciones declaradas se cumplen: la etapa coincide (o está vacía), el glob de herramienta coincide, el glob de skill coincide (o está vacío), 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.

​
2. Glob de nombre de herramienta

Una gramática deliberadamente pequeña, sensible a mayúsculas y minúsculas — sin sorpresas de regex, tiempo lineal, segura en la ruta caliente del relay:
PatrónCoincide con
"" o *Toda herramienta.
foo.*Prefijo — foo.bar, foo.exec (no el foo desnudo).
*.execSufijo — shell.exec, db.exec (no el exec desnudo).
*.shell.*Infijo — local.shell.exec (necesita ≥1 carácter a cada lado).
cualquier otra cosaCoincidencia exacta de cadena (incluyendo foo.*.bar).
Las herramientas se nombran convencionalmente con espacio de nombres server.tool o category.action, así que shell.* captura toda una familia y *.delete captura un verbo a través de servidores.

​
3. Glob de nombre de skill

La misma gramática de glob, comparada contra la skill propietaria de la llamada a herramienta (p. ej. community.*, builtin.send). Se hace AND con tool_name_glob, así que: 
tool_name_glob:  http.fetch
skill_name_glob: community.*
coincide con http.fetch solo cuando es propiedad de una skill community.* — confía en la misma herramienta desde una skill integrada, gatea esa misma desde una de la comunidad. Un glob de skill vacío coincide con cualquier propietario. Cómo se atribuye una llamada a herramienta a una skill se cubre en Skills.

​
4. Cláusulas de argumentos

La coincidencia de nombre de herramienta responde qué herramienta; las cláusulas de argumentos responden con qué argumentos — la diferencia entre “bloquear shell.exec” y “bloquear shell.exec solo cuando el comando es rm -rf.” args_match es un conjunto de cláusulas, todas unidas con AND: 
{
  "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" }
  ]
}
Un args_match vacío / ausente es vacuamente verdadero — la regla coincide solo con el glob.

​
Operadores

OperadorCoincide cuando
eqIgualdad escalar (los números se comparan numéricamente; desajuste de tipo → no coincide).
containsSubcadena (ambos operandos deben ser cadenas).
regexUn patrón RE2 de Go coincide con el valor de cadena (tiempo lineal, sin backreferences).
inEl valor es un elemento del array JSON dado.
cidr_matchLa IP de cadena cae dentro del CIDR dado.
gt / ltMayor-que / menor-que numérico (las cadenas no se coercen).

​
Sintaxis de path

Un pequeño subconjunto de JSONPath sobre el objeto de argumentos de la herramienta:
  • $.foo, $.foo.bar — acceso a campo
  • $.foo[0], $.arr[1].k — indexación de array
  • $ — el objeto de argumentos completo
Sin comodines, filtros, slices ni descenso recursivo.
Las cláusulas de argumentos fallan cerrado — la regla, no la solicitud. Si un 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 veredicto por defecto. Una cláusula rota nunca auto-deniega y nunca tumba el relay. Escribe tu regla de “capturar todo lo peligroso” como un deny explícito con su propio glob en vez de confiar en que una cláusula falle de una forma particular.
La consola valida las cláusulas de forma estricta al guardar (operadores desconocidos, paths malos, valores in que no son array, regexes no compilables y CIDRs inválidos se rechazan todos) para que una cláusula malformada no pueda persistirse en primer lugar.

​
5. Saneadores

Un veredicto sanitize redacta las subcadenas coincidentes de los argumentos de la herramienta y reenvía la llamada limpia — útil para eliminar secretos o PII que un agente puso en un argumento de herramienta sin bloquear toda la acción. 
{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }
Las coincidencias de preset se reemplazan con [redacted:<preset>]; las coincidencias de regex personalizado con [redacted:custom]. La biblioteca de presets integrada: aws_access_key, aws_secret_key, openai_key, anthropic_key, bearer_token, email, ssn_us, credit_card (con una verificación de Luhn). Una regla de sanitize debe declarar al menos un preset o patrón personalizado — un saneador vacío se rechaza al guardar. En la superficie inbound no hay argumentos en tiempo de llamada que redactar, así que un veredicto sanitize ahí escala a un bloqueo.

​
6. Listas de destino de egress

Una regla egress (etapa egress) coincide con un destino saliente — la superficie de SSRF y exfiltración: 
{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}
Las entradas coinciden como un CIDR, una IP literal o un hostname sin distinguir mayúsculas y minúsculas; los hostnames se resuelven en modo best-effort y se reverifican contra las entradas de IP/CIDR. La polaridad sigue al veredicto: con un veredicto allow la lista allow define qué está en alcance y deny talla excepciones de ella; con un veredicto de aplicación (deny) la lista deny define qué se bloquea y allow talla excepciones. 169.254.169.254 (el endpoint de metadatos de la nube) y los rangos RFC-1918 son las cosas canónicas a denegar — el preset block_ssrf_egress y el nivel de autonomía tight envían exactamente eso.

​
7. Veredictos

VeredictoEfectoNotas
allowDeja pasar, registrado.
auditPermite + registra para revisión.El default_verdict habitual.
denyBloquea la llamada.HTTP 400 en inbound; error de herramienta en mcp.
sanitizeRedacta args, reenvía.Necesita un saneador; escala a deny en inbound.
pending_approvalRetiene para un humano.Requiere el almacén de aprobaciones configurado; rechazado en response/egress.
cap_costDeniega pasado un tope de gasto.Necesita un cap_cost_cents no negativo; inerte en response/egress.
En modo shadow cada veredicto de aplicación se degrada a audit y la razón se prefija con [shadow] would ….

​
8. Secuencias

Algunos riesgos solo son visibles a través de varias llamadas — leer 50 registros de CRM, luego exportar, luego golpear un host externo. Una regla sequence coincide con una cadena ordenada en vez de una sola llamada: 
{
  "window_seconds": 600,
  "steps": [
    { "match": "crm.*",   "min_count": 3 },
    { "match": "*.export" },
    { "match": "*",       "egress": true }
  ]
}
Cada paso es un glob de herramienta con un min_count opcional (por defecto
  1. y un egress: true opcional (el paso debe ser una llamada de egress). Los pasos deben ocurrir en orden — intercalar con otras llamadas está bien — y toda la cadena debe completarse dentro de window_seconds (0 = sin límite).
Las secuencias se aplican reactivamente por un matcher asíncrono, no en línea en cada llamada — una secuencia con un paso * coincidiría de otro modo con cada llamada a herramienta individual. Encienden el feed de eventos y pueden disparar una acción de seguimiento, pero no bloquean en tiempo real la llamada individual que completa la cadena.

​
9. Presets integrados

Empieza desde un preset en vez de una regla en blanco. Se autoran del lado del servidor para que la consola y estos docs describan comportamiento idéntico:
PresetQué hace
block_destructive_shellDeniega comandos de shell destructivos (rm -rf, mkfs, dd, fork bombs, …) vía un conjunto de reglas deny-by-glob.
block_ssrf_egressAudita el egress al endpoint de metadatos y a los rangos RFC-1918.
block_secrets_in_argsOrientado a detección — marca credenciales que aparecen en argumentos de herramienta.
block_pii_in_tool_resultsOrientado a detección — saca a la luz PII en resultados de herramienta.
Aplica un preset como semilla, luego edita libremente — un preset es un punto de partida, no un candado.

​
10. Evaluación, límites y seguridad

  • Gana la primera coincidencia. Las reglas se ejecutan en orden priority ASC, id ASC; la primera regla cuyas condiciones se cumplen todas decide el veredicto. Ninguna regla coincide → el default_verdict de la política.
  • Determinista y sin dependencias. La coincidencia de glob y de cláusula son operaciones puras de cadena/JSON sin llamada de red, seguras de ejecutar en cada llamada a herramienta. Los regexes son RE2 — tiempo lineal, sin backtracking catastrófico.
  • Cláusulas fail-closed. Una cláusula que no se puede evaluar hace que su regla no se dispare en vez de auto-denegar (§4).
  • Validación estricta en tiempo de guardado. Las parejas veredicto/etapa, la no vacuidad del saneador, la presencia de cap_cost_cents, la forma de la cláusula y la resolución de referencias se verifican todas al guardar — las reglas inválidas no pueden persistirse.
  • Auditado. Cada creación/actualización/eliminación de regla escribe una fila de auditoría después de que el cambio se confirma; los blobs de reglas y los secretos nunca se escriben en el log de auditoría.

​
API reference

Las reglas viven bajo una política y tienen alcance de espacio de trabajo; las escrituras requieren Developer+.
Método y rutaRolPropósito
POST /api/workspace/firewall/rulesDeveloper+Crear una regla.
PUT /api/workspace/firewall/rulesDeveloper+Actualizar una regla (id en el cuerpo).
DELETE /api/workspace/firewall/rules/:idDeveloper+Eliminar una regla.
GET /api/workspace/firewall/presetsMemberLista presets integrados.
POST /api/workspace/firewall/testDeveloper+Ejecutar en seco una política (reglas incluidas) contra una llamada a herramienta de muestra.
Para previsualizar una regla antes de depender de ella, usa Test — devuelve el veredicto, la regla coincidente y la razón sin despachar nada.

​
Véase también

¿Quieres profundizar en la seguridad de agentes? Las guías de Protege tus agentes (Zero Trust) sitúan esta función dentro de un flujo de trabajo de confianza cero.

Construye una política de firewall

Redacta una política de confianza cero paso a paso, luego ejecútala en modo sombra antes de aplicarla.

Referencia del esquema de reglas

Todos los campos de una regla — globs, predicados de argumentos, salida y topes de coste.