Saltar al contenido principal
Escribiste una regla de firewall — un deny sobre shell.exec, una lista de permitidos de egress, una cláusula de argumentos que solo se dispara en rm -rf — y ahora quieres saber que hace exactamente lo que crees antes de que cambie una sola llamada a herramienta en producción. El firewall te da tres formas no destructivas de probar reglas de firewall, cada una respondiendo una pregunta diferente:

Ejecuta en seco una llamada

El sandbox de Test alimenta una llamada a herramienta sintética a través del motor real y devuelve el veredicto — nada despachado, nada registrado. Developer+.

Reproduce una postura

Simulate reproduce un nivel de autonomía contra tu tráfico reciente y cuenta cuántas llamadas bloquearía. Legible por Member.

Ejecuta contra tráfico en vivo

El modo shadow evalúa toda una política sobre llamadas reales pero degrada cada veredicto de aplicación a audit. Cero radio de explosión.
Los tres se configuran a través de la consola (o las rutas de gestión /api/workspace/firewall/*, que se autentican con tu sesión / token de acceso — no una clave de relay sk-orca-…). Las llamadas de relay /v1/* de tu agente nunca cambian mientras pruebas.

​
1. Prueba reglas de firewall con el sandbox de Test de ejecución en seco

El sandbox de Test es el bucle más ajustado: dale una sola llamada a herramienta sintética y ejecuta el motor de evaluación real — resolución de política completa, reglas recorridas en orden de prioridad, gana-la-primera-coincidencia — luego devuelve el veredicto, la regla que lo produjo y la razón legible por humanos. La llamada es una ejecución en seco: nada se despacha a ninguna herramienta, y nada se escribe en el feed de eventos o el inventario de Herramientas descubiertas. Responde una pregunta con precisión: dado este nombre de herramienta exacto y estos argumentos, ¿qué decide mi política — y qué regla lo decide?
El sandbox de Test es Developer+. Puede previsualizar contra una política en borrador sin guardar por id y la respuesta saca a la luz el nombre de política coincidente y la etiqueta de regla, así que se sitúa más cerca de una vista previa de superficie de escritura que de una lectura simple — a diferencia de Simulate y las otras vistas de lectura, que están abiertas a cada miembro.

​
Una ejecución en seco concreta

Supón que has añadido una regla que debería denegar shell.exec solo cuando el comando contiene rm -rf. Quieres confirmar dos cosas en una sola sesión: el comando peligroso se deniega, y uno inocente aún pasa.
1

Prueba la llamada peligrosa

En Security → Firewall, abre la pestaña Test, elige la superficie response, introduce el nombre de herramienta shell.exec y los argumentos {"command": "rm -rf /data"}, y ejecuta. La respuesta nombra el veredicto y la regla coincidente:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Prueba la llamada inocente

Ejecútala de nuevo con {"command": "ls -la"}. La cláusula de argumentos ya no coincide, así que la regla cae al valor por defecto de la política — deberías ver allow o audit y un rule_label vacío. Si rm -rf deniega y ls -la no, tu cláusula de argumentos está acotada correctamente.
3

Previsualiza un borrador antes de adjuntarlo

Pasa un policy_id para evaluar contra una política en borrador específica en vez de la que tu tráfico resuelve actualmente — para que puedas probar que una política nueva es correcta antes de adjuntarle una clave o promoverla a valor por defecto del espacio de trabajo.
Lee gap en la respuesta. gap: true significa que una política resolvió pero ninguna regla dentro de ella coincidió con la llamada (y el espacio de trabajo está en modo observe) — la herramienta se escapó por cada regla y cayó al valor por defecto. Ese es un agujero de cobertura que cerrar antes de lanzar, no un veredicto en el que confiar.
El sandbox de Test usa las mismas superficies que la evaluación en vivo — inbound, response, mcp, egress (por defecto inbound) — así que prueba cada regla en la superficie a la que está fijada. En inbound no hay argumentos en tiempo de llamada, así que una regla sanitize escala a un bloqueo ahí exactamente como lo haría en producción; ver etapas para por qué la superficie importa.

​
2. Simula un nivel de autonomía antes de aplicarlo

El sandbox de Test verifica una llamada. Simulate responde la pregunta a nivel de postura: si cambiara todo este espacio de trabajo a un nivel de autonomía más estricto, ¿cuánto de mi tráfico reciente bloquearía? Simulate reproduce las reglas deny de un nivel candidato contra tus eventos de firewall recientes y devuelve el impacto potencial — solo nombres de herramienta y conteos, nunca argumentos. Es de solo lectura y legible por Member, así que cualquiera en el equipo puede previsualizar el radio de explosión de tight antes de que un Developer se comprometa con él.
  • tight — defecto-deny, denegar shell destructivo, denegar herramientas con forma de fetch (el vector SSRF), PII Shield + Secrets Blocker aplicados. Simulate muestra cuánto de tu tráfico real capturaría este piso.
  • balanced — audit por defecto, denegar shell destructivo, PII Shield solo audit (marca PII). La postura de inicio recomendada.
  • permissive — solo observe; nada aplicado.
Simulate no cambia nada — es un qué-pasaría-si sobre eventos pasados. Aplicar un nivel de autonomía (una escritura Developer+) materializa filas de política y guardrail autonomy_* reales y editables, con deshacer de un clic desde el snapshot de auditoría. Previsualiza con Simulate, luego aplica cuando el conteo se vea correcto.

​
3. Modo shadow: prueba contra tráfico en vivo sin radio de explosión

El sandbox de Test y Simulate son vistas previas sin conexión. El modo shadow es la en vivo: un flag por política que evalúa la política sobre tráfico de agente real, recorre cada regla, elige un veredicto — luego degrada cada veredicto de aplicación (deny, sanitize, pending_approval) a audit y prefija la razón con [shadow] would …. La llamada siempre pasa; nada se bloquea, redacta ni retiene. Eso hace que el feed de eventos se lea como una ejecución en producción con la aplicación apagada. Filtra por [shadow] y tienes una lista completa de cada llamada que la política está a punto de empezar a bloquear — antes de que bloquee una.
Método de pruebaSe ejecuta contraPregunta que responde
Sandbox de TestUna llamada sintética”¿Qué veredicto obtiene esta llamada exacta, y qué regla decide?”
SimulateEventos recientes”¿Cuántas llamadas bloquearía un nivel de autonomía más estricto?”
Modo shadowTráfico en vivo”¿Qué bloquearía esta política a lo largo del tráfico de producción real?”
El modo shadow es el más profundo de los tres — cobertura en vivo completa con cero radio de explosión. Tiene su propia página: Lanza una política de firewall con modo shadow recorre el interruptor, las razones [shadow] would … y el cambio a aplicar.

​
4. Un orden de prueba práctico

Las tres herramientas se componen en una ruta de lanzamiento seguro — la verificación más barata primero, la cobertura más amplia al final:
1

Ejecuta en seco las reglas que acabas de escribir

Usa Test para confirmar que cada regla nueva se dispara en las llamadas que debería y pasa las que no debería — incluidos los casos negativos. Rápido, Developer+, nada persistido.
2

Calibra la postura (opcional)

Si estás recurriendo a un nivel de autonomía en vez de reglas escritas a mano, Simulate el nivel y lee el conteo de potencialmente-bloqueadas contra tráfico real antes de aplicarlo.
3

Pon en shadow contra tráfico en vivo

Activa el modo shadow y deja que una ventana representativa de llamadas reales fluya. Lee los eventos [shadow] would …; ajusta cualquier regla que saque a la luz un falso positivo — aún en shadow, cero radio de explosión.
4

Aplica

Cuando el feed se dispara en lo que esperas y en nada que no, apaga shadow. La siguiente llamada aplica de verdad.
Las pruebas previsualizan la política, no las skills gobernadas. Una skill en modo block o quarantine sigue aplicando incluso bajo una política en shadow — la disposición de revisión de la skill gana. Poner una política en shadow nunca fue una petición para sacar una skill de cuarentena.

​
5. Referencia de la API

Estas rutas de gestión usan tu sesión / token de acceso y tienen alcance de espacio de trabajo:
Método y rutaRolPropósito
POST /api/workspace/firewall/testDeveloper+Ejecuta en seco una llamada a herramienta sintética contra la política resuelta (o un policy_id en borrador). Devuelve verdict, policy_name, rule_label, reason, gap, shadow_mode. Nada despachado ni registrado.
GET /api/workspace/firewall/simulate?level=MemberReproduce un nivel de autonomía contra eventos recientes; devuelve conteos de potencialmente-bloqueadas.
GET /api/workspace/firewall/policies/:idMemberLee el flag shadow_mode actual de una política.
PUT /api/workspace/firewall/policiesDeveloper+Alterna shadow_mode en la política.
El cuerpo de Test toma surface (por defecto inbound), un tool_name requerido, un args_json opcional, y un policy_id opcional para anular la resolución.

​
Dónde ir a continuación

Modo shadow

El lanzamiento de tráfico en vivo: [shadow] would …, el filtro de eventos, y el cambio a aplicar.

Validar argumentos

Acota una regla a qué argumentos — las cláusulas que el sandbox de Test te deja verificar contra rm -rf vs ls -la.

Veredictos

Qué hacen allow / audit / deny / sanitize / pending_approval / cap_cost cada uno cuando una prueba deja de ser una prueba.

Registro de eventos

Dónde aterrizan los veredictos en shadow — filtra, profundiza en ejecuciones y reglas coincidentes.
Para la gramática de coincidencia de reglas que estas pruebas ejercitan, ver la referencia completa de reglas del firewall; para dónde encajan las pruebas en el modelo más amplio, ver modos de aplicación.