deny
sobre shell.exec, una lista de permitidos de egress — y crees que es
correcta. Pero activarla contra el tráfico de agente en producción es un
salto de fe: una regla demasiado amplia y estás bloqueando llamadas que tus
agentes hacen legítimamente.
El modo shadow del firewall es el interruptor de lanzamiento seguro. Es
un flag por política que le dice al gateway que evalúe la política
exactamente como lo haría en producción, registre todo, pero no bloquee
nada. Cada veredicto de aplicación se degrada a audit, y la razón del
evento se prefija con [shadow] would … para que puedas leer con precisión
qué habría hecho la política — sin que haya hecho nada todavía.
El modo shadow es un flag en la política, establecido en la consola (o
las rutas de gestión
/api/workspace/firewall/policies, que usan tu sesión
/ token de acceso — no una clave de relay sk-orca-…). Alternarlo es una
acción Developer+. Las llamadas de relay /v1/* de tu agente no cambian.1. Qué hace el modo shadow del firewall
Cuando el flagshadow_mode de una política está activado, el gateway
ejecuta la evaluación completa — resuelve la política, recorre las reglas en
orden de prioridad, elige un veredicto — y luego, justo antes de que el
veredicto surta efecto, degrada cualquier cosa que habría cambiado la
llamada:
| Veredicto resuelto | Bajo modo shadow |
|---|---|
deny | → audit, razón [shadow] would deny — … |
sanitize | → audit, razón [shadow] would sanitize — … |
pending_approval | → audit, razón [shadow] would pending_approval — … |
allow / audit | sin cambios (ya no bloqueantes) |
2. Un lanzamiento concreto
Supón que tienes una políticaprod-agents con una regla deny sobre
comandos shell destructivos, y quieres confirmar que no se dispara en nada
legítimo.
Activa el modo shadow
En Security → Firewall → Policies, abre
prod-agents, alterna
Shadow mode a activado y guarda. La política conserva su vinculación
y sus reglas — solo deja de aplicar.Deja fluir el tráfico real
Tus agentes siguen llamando al gateway exactamente como antes. Cada
llamada a herramienta se evalúa; nada se bloquea. Dale una ventana
representativa — lo suficientemente larga para cubrir tu mezcla real de
herramientas.
Lee las denegaciones potenciales
Abre Events y filtra por la razón
[shadow]. Cada fila muestra la herramienta, la superficie, la ejecución
y la regla que coincidió — así que un
[shadow] would deny — destructive shell command sobre una llamada
shell.exec es exactamente lo que verías en producción, menos el HTTP
400.Apaga el modo shadow
Una vez que el feed muestre que la política se dispara en lo que esperas y
en nada que no, alterna Shadow mode a apagado. Desde la siguiente
llamada en adelante, esos eventos
[shadow] would deny se convierten en
denegaciones firewall_blocked
reales.deny — corrige la regla (ajusta el
glob o añade una
cláusula de argumentos) mientras
sigues en shadow, y observa el feed de nuevo. Iteras contra el tráfico real
con cero radio de explosión.
3. Lo que el modo shadow no suaviza
El modo shadow es una vista previa de la política, no un interruptor de apagado maestro. Algunas fronteras más que vale la pena conocer:Los veredictos allow y audit quedan intactos
Los veredictos allow y audit quedan intactos
Solo los veredictos de aplicación (
deny, sanitize,
pending_approval) se degradan. Un allow o audit ya deja pasar la
llamada, así que no hay nada que suavizar — esos eventos aún llevan la
insignia de shadow para que puedas saber que la política estaba en shadow
cuando se registraron.cap_cost se resuelve antes de la degradación
cap_cost se resuelve antes de la degradación
Una regla
cap_cost se resuelve a un
allow o deny concreto según el gasto acumulado de la ejecución, y
ese veredicto resuelto es lo que el modo shadow luego degrada — una
denegación potencial por cruce de tope aparece como [shadow] would deny
como cualquier otra.Es por política, no por espacio de trabajo
Es por política, no por espacio de trabajo
El modo shadow vive en cada política de forma independiente. Puedes poner
en shadow una política nueva mientras otra probada en batalla sigue
aplicando — no hay un interruptor de shadow a nivel de espacio de trabajo
que olvides apagar.
4. Modo shadow vs. los otros diales de lanzamiento
El firewall te da tres controles diferentes de “no rompas nada todavía”. Resuelven problemas distintos:| Control | Alcance | Pregunta que responde |
|---|---|---|
| Modo shadow | Una política | ”¿Qué bloquearía esta política si la aplicara?” |
Veredicto por defecto audit | Una política | ”Registra todo lo que ninguna regla nombra, no bloquees nada.” |
| Modo observe | Espacio de trabajo | ”¿Qué herramientas se ejecutan sin política que las cubra?” |
audit es para la cola no coincidente de una política; el modo observe
trata de huecos de cobertura a lo largo del espacio de trabajo, no de la
aplicación de una política específica.
Puedes apilarlos. Una nueva política defecto-deny bajo modo shadow es el
lanzamiento más suave posible: incluso el piso defecto-deny solo registra
[shadow] would deny en vez de bloquear, así que ves el conjunto completo de
llamadas que tus reglas allow aún no cubren antes de que el deny esté en
vivo.5. Los packs de cumplimiento aterrizan primero en shadow
Cuando instalas un pack de cumplimiento en modo observe (no de aplicación), las políticas de firewall que materializa se crean con el modo shadow activado — evalúan y registran contra tu tráfico sin bloquear nada. Promover el pack a aplicar saca esas políticas de shadow. El mismo mecanismo, aplicado por ti: ejecuta en seco los controles, lee los veredictos potenciales, luego aplica.6. Alternarlo
En la consola, el modo shadow es un interruptor en el editor de políticas. El mismo flag se expone en la API de gestión comoshadow_mode en el objeto de
política — estas rutas usan tu sesión / token de acceso y requieren
Developer+:
| Método y ruta | Rol | Nota |
|---|---|---|
PUT /api/workspace/firewall/policies | Developer+ | Establece shadow_mode: true / false en la política en el cuerpo. |
GET /api/workspace/firewall/policies/:id | Member | Lee el estado shadow_mode actual de una política. |
version de la política, así que activar y desactivar
shadow se rastrea en sí mismo.
Dónde ir a continuación
Crear y adjuntar una política
La configuración en dos pasos que lanza el modo shadow — crea la
política, adjunta una clave.
Registro de eventos
Dónde aparece
[shadow] would … — filtra, profundiza en ejecuciones y
reglas.Veredictos
Los veredictos de aplicación que el modo shadow degrada, y qué hace cada
uno en vivo.
Modos de aplicación
Cómo shadow, audit y observe encajan en el modelo de aplicación más
amplio.