Saltar al contenido principal
Cuando dos reglas podrían ambas coincidir con la misma llamada a herramienta, la prioridad de reglas del firewall decide cuál gana. Una política de firewall es una lista ordenada de reglas — el motor las recorre en orden de prioridad, se detiene en la primera que coincide, y aplica su veredicto. Acierta el orden y un guardia amplio más una excepción estrecha coexisten limpiamente; falla y la regla amplia se traga la excepción que pretendías tallar. Esta página es la referencia enfocada al ordenamiento. Para la gramática de reglas completa ver Reglas del Firewall; para los veredictos que una regla puede producir ver Veredictos.

​
1. El orden: prioridad ascendente, gana la primera coincidencia

Dentro de una política, las reglas se evalúan en orden priority ASC, id ASC:
  1. La priority más baja se ejecuta primero. Una regla con priority: 0 se verifica antes que una con priority: 10. Piénsalo como una posición en la cola, no una puntuación de fuerza — el número más pequeño tiene la primera palabra.
  2. Los empates se rompen por id de regla. Dos reglas en la misma priority se ejecutan en orden de creación (id de regla ascendente), así que la regla más antigua gana el empate. Usa prioridades distintas cuando el orden realmente importa en vez de apoyarte en el desempate por id.
  3. Gana la primera coincidencia. El motor se detiene en la primera regla cuyas condiciones todas se cumplen y aplica su veredicto. Las reglas más abajo en la lista nunca se consultan para esa llamada.
  4. Ninguna coincidencia → el veredicto por defecto. Si nada coincide, aplica el default_verdict de la política — audit a menos que lo hayas cambiado.
Una regla coincide solo cuando cada condición declarada se cumple a la vez: la superficie, el glob de nombre de herramienta, el glob de skill opcional, las cláusulas de argumentos opcionales, y el alcance de egress (solo reglas de egress). Una coincidencia parcial es sin coincidencia, y la evaluación pasa a la siguiente regla.

​
2. Un ejemplo concreto: específico antes que amplio

El trabajo de ordenamiento canónico es dejar que un allow estrecho sobreviva a un deny amplio. Pon la regla específica en una prioridad más baja para que se alcance primero: 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
Una llamada a shell.echo golpea Rule A primero (priority 10), coincide, y se permite — el motor nunca alcanza Rule B. Una llamada a shell.exec cae por A (el glob no coincide), golpea Rule B, y se deniega. Invierte las prioridades y el deny amplio shell.* en priority 10 capturaría shell.echo primero, y tu allow en priority 20 sería código muerto. La regla general: lo más específico primero, lo más amplio al final.
No dependas del desempate por id para esto. Si el allow y el deny comparten la misma priority, el ganador es la regla que creaste primero — un ordenamiento frágil que se invierte silenciosamente si eliminas y recreas una regla. Dale a la regla específica una priority más baja y la intención es explícita.

​
3. Verifica el orden antes de depender de él

Razonar sobre la prioridad en papel es propenso a errores una vez que una política tiene más de un puñado de reglas. El sandbox de Test ejecuta el motor real contra una llamada a herramienta de muestra y te dice no solo el veredicto sino qué regla ganó — para que puedas confirmar que la regla que esperabas realmente se disparó:
1

Abre la pestaña Test de la política

En la consola, abre la política y cambia a Test (Developer+).
2

Envía una llamada de muestra

Introduce un nombre de herramienta (y argumentos, si tus reglas los inspeccionan) y ejecútala. Nada se despacha y nada se persiste — es una ejecución en seco.
3

Lee la regla coincidente

El resultado nombra el veredicto, la regla coincidente (por etiqueta/id) y la razón. Si una regla amplia ganó donde esperabas una estrecha, baja la priority de la regla estrecha y reprueba.
Ver Probar reglas para el sandbox completo, y Gestionar políticas para editar el orden de reglas en el lugar.

​
4. La aplicación de skill cabalga encima

La prioridad de reglas decide el veredicto de la regla ganadora — pero eso no siempre es la respuesta final. Si la llamada a herramienta es propiedad de una skill gobernada, el modo de aplicación de la skill se aplica encima del veredicto ganador, después de la resolución de primera-coincidencia:
Modo de skillEfecto sobre el veredicto ganador
allowSin cambio — el veredicto de la regla se mantiene.
quarantineEscala cualquier cosa por debajo de deny a pending_approval; un deny existente se deja tal cual.
blockFuerza un deny sin importar el veredicto de la regla.
Así que una skill quarantine puede convertir un allow de regla en una llamada retenida, y una skill block deniega una llamada incluso cuando ninguna regla nombra sus herramientas. La cuarentena solo escala — nunca degrada un deny a algo más suave. Por esto una skill autodetectada como arriesgada se queda en cuarentena hasta que la revises, sin importar cuán permisivas sean tus reglas.
El modo de skill no es una regla, así que no tiene una priority y no puedes reordenarlo en relación con tus reglas. Siempre evalúa después de que el veredicto ganador se elige. Si el modo de una skill gobernada está bloqueando llamadas que esperabas permitir, arréglalo en la skill, no añadiendo una regla allow de mayor prioridad — la regla no puede anular el modo.

​
5. Cosas que no cabalgan en primera-coincidencia

Algunos mecanismos se sitúan fuera del recorrido de prioridad por regla — sabe dónde aterrizan para no intentar ordenarlos:
Una regla cap_cost bajo su techo se trata como no coincidente, así que la evaluación continúa a la siguiente regla en vez de dejarla ganar por primera coincidencia como una concesión. Sobre el techo resuelve a un deny. Nunca hace corto-circuito a una regla de menor prioridad solo por ser alcanzada.
Una regla de secuencia coincide con una cadena de llamadas a lo largo de una ventana de tiempo, así que se aplica de forma reactiva por un coincidente asíncrono en vez de sobre la única llamada que completa la cadena. Ilumina el feed de eventos pero no gana el recorrido de primera-coincidencia para una llamada individual.
El modo shadow no cambia qué regla gana — degrada el veredicto de aplicación ganador a audit (razón prefijada con [shadow] would …) después de la resolución de primera-coincidencia, así que puedes medir el impacto de una política antes de que cambie el tráfico.

​
6. Juntándolo todo

Para cualquier llamada a herramienta la resolución completa es:
  1. Resolver la política — la adjunta a la clave que llama, o el valor por defecto del espacio de trabajo. Ver alcance.
  2. Recorrer reglas en priority ASC, id ASC — gana la primera coincidencia; ninguna coincidencia → default_verdict.
  3. Aplicar la aplicación de skill — el modo de una skill gobernada cabalga encima del veredicto ganador (block fuerza deny, quarantine escala).
  4. Aplicar el modo shadow — si está activado, degrada los veredictos de aplicación a audit.
  5. Registrar el evento — veredicto, superficie, herramienta y regla coincidente aterrizan en el feed de eventos.
Editar la prioridad de una regla surte efecto en la siguiente llamada para cada clave adjunta a la política — sin redespliegue, sin cambio de código del agente. Reejecuta el sandbox de Test después de reordenar para confirmar el nuevo ganador antes de que el tráfico en vivo dependa de él.

​
Dónde ir a continuación

Veredictos

Qué hace realmente cada veredicto ganador.

Sintaxis glob

Cómo la coincidencia de nombre de herramienta decide si una regla es siquiera un candidato.

Probar reglas

Ejecuta en seco una política y ve qué regla gana.

Lista de permitidos de herramientas

El patrón defecto-deny que más se apoya en el ordenamiento.
Para el lenguaje de coincidencia detrás de una regla, ver la referencia completa de Reglas del Firewall; para cómo las skills se apilan encima, ver Firewall Skills y modos de aplicación.