Saltar al contenido principal
Tienes una política que quieres poner frente a producción. El miedo no es la política — es activarla y descubrir que bloquea una herramienta que tu agente realmente necesita, o enmascara un campo del que tu app depende. El arreglo no es más pruebas en un sandbox; es lanzar contra tráfico real en una postura que no puede romper nada, luego endurecer solo una vez que has visto qué se dispara. Esta receta es ese lanzamiento: observe → shadow → enforce, con autonomía balanced antes de tight. Te quedas en la consola (o la API REST) todo el camino; el agente sigue llamando a https://api.orcarouter.ai/v1/... exactamente como antes.
¿Nuevo en el modelo? Lee Modos de aplicación para qué hace cada postura mecánicamente, y la línea base de Agentes Seguros para qué establece cada nivel de autonomía. Esta página es la secuencia — el orden en que volteas los interruptores.

​
1. El lanzamiento de seguridad de IA en tres movimientos

Todo el lanzamiento intercambia autonomía por seguridad en tres pasos, cada uno verificado contra tráfico en vivo antes del siguiente:

Observe

Permite todo, registra todo. Las llamadas a herramienta sin cubrir aterrizan en Discovered Tools; las reglas flag del guardrail registran coincidencias sin cambiar el tráfico. Aprendes la forma real de tu agente.

Shadow

Una política real evalúa cada llamada, pero cada veredicto de aplicación se degrada a audit y se registra [shadow] would …. Ves exactamente qué bloquearía — sin nada realmente bloqueado.

Enforce

Shadow apagado. deny bloquea, mask redacta, pending_approval retiene. La autonomía va de amplia (balanced) a estricta (tight), y tu agente queda gobernado.
La disciplina es el punto: nunca aplicas una regla que no hayas visto dispararse primero en shadow contra tu propio tráfico.

​
2. Movimiento uno — observe (autonomía = permissive)

Empieza tan amplio como llega. Aplica el nivel de autonomía permissive desde Firewall → Posture (Developer+) — o POST /api/workspace/firewall/autonomy. Habilita el modo observe del espacio de trabajo y no deja ninguna política de aplicación, así que cada llamada se permite y cada llamada sin cubrir se registra como un hueco de cobertura. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Las rutas /api/workspace/firewall/* se ejecutan sobre tu sesión de consola / token de acceso, no sobre una clave de relay sk-orca-.... Aplicar un nivel de autonomía es una escritura de espacio de trabajo — Developer+. Solo las llamadas de modelo /v1/* usan la clave de relay.
Ahora apunta tráfico real a él y déjalo correr. Vigila dos feeds:
  • Firewall → Discovered Tools (Member) — cada herramienta que tu agente llama, marcada covered o gap. Esta es la entrada para tus reglas: estás a punto de escribir política para tráfico que realmente ocurre, no hipotéticos.
  • Guardrails → Matches (Member) — si has añadido reglas de acción flag, cada coincidencia que registran, sin tocar la solicitud.
Déjalo correr hasta que Discovered Tools deje de exponer herramientas nuevas. Esa lista estable es tu especificación de autoría de reglas.

​
3. Movimiento dos — shadow (una política real, cero bloqueo)

Ahora autora la política que realmente quieres — globs de herramienta, cláusulas de argumentos, listas de egress, un techo cap_cost — y activa shadow_mode antes de adjuntarla. (Construye reglas desde reglas del firewall; el modelo de política completo está en la referencia del Firewall.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
Con shadow_mode: true, ese deny y ese cap_cost están ambos degradados a audit en tiempo de evaluación — el motor computa el veredicto real, lo registra prefijado [shadow] would …, y deja pasar la llamada. Adjunta la política a las claves que estás lanzando (establece firewall_policy_id en la clave) o hazla el valor por defecto del espacio de trabajo. Luego lee Firewall → Events / Runs (Developer+) filtrado por el prefijo [shadow] y confirma ambos lados:
Cada llamada shell.exec muestra [shadow] would deny. Cada ejecución que cruza tu tope muestra [shadow] would cap_cost. La política ve el tráfico para el que la construiste.
Ninguna herramienta legítima aparece con un veredicto de se-bloquearía. Esta es la verificación de falsos positivos — la razón por la que shadow existe. Si una herramienta que necesitas se marca, arregla la regla y re-observa antes de aplicar siquiera.
Los guardrails no tienen shadow a nivel de política. El equivalente es la acción flag por regla: registra una coincidencia en el feed de Matches y no cambia nada, así que puedes medir una regla de contenido antes de cambiarla a block o mask. Ejecuta tus reglas de guardrail como flag a través de este mismo movimiento.

​
4. Movimiento tres — enforce (autonomía balanced, luego tight)

Cuando el registro de shadow se vea bien, aplica en dos etapas, no una. No saltes directo a default-deny. Primero, balanced. Esta es la primera postura de aplicación recomendada: el veredicto por defecto del firewall es audit, pero las acciones más destructivas (como shell destructivo) se deniegan, y el guardrail PII Shield se ejecuta solo-audit — marca PII sin enmascararla aún. Ahora estás bloqueando lo peor mientras aún observas el resto. Apaga shadow_mode en tu propia política en el mismo movimiento para que sus veredictos deny / cap_cost vayan en vivo junto a la línea base. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Vigila Events durante una hora. Los bloqueos reales ahora aparecen sin el prefijo [shadow]. Una llamada a herramienta denegada devuelve HTTP 400 firewall_blocked; es skip-retry y no cuesta tokens de modelo. Luego, tight. Una vez que balanced esté tranquilo, pasa a default-deny. El nivel tight deniega por defecto, deniega shell destructivo y egress SSRF, y aplica PII Shield + Secrets Blocker — la PII se enmascara en la solicitud antes de que el modelo la vea, y los secretos en tus solicitudes se bloquean. Un prompt bloqueado devuelve HTTP 400 guardrail_blocked, no cuesta cuota, y es skip-retry.
EtapaFirewall (acciones)Guardrails (texto)Qué estás demostrando
permissiveObserve; nada bloqueadoSolo flagForma del tráfico real
balancedAudit por defecto; shell destructivo denegadoPII marcadaEl peor caso se detiene
tightDefault-deny; shell + herramientas con forma de fetch (SSRF) denegadasPII enmascarada, secretos bloqueadosZero-trust completo
Salvedad de streaming para PII. Bajo tight, PII Shield enmascara PII en la solicitud antes de que el modelo la vea — eso está en vivo. El enmascarado del lado de salida de una respuesta en streaming aún no está en vivo; un block de salida se aplica en streaming (el escáner corta el stream). Si dependes de redactar la salida del modelo, verifica tu combinación de etapa/streaming en la pestaña Test del guardrail primero. Ver Guardrails.

​
5. La salida de emergencia — deshacer de un clic

Cada cambio de autonomía es una única transacción que captura tu postura previa, así que puedes retroceder directamente desde Firewall → Posture (o POST /api/workspace/firewall/autonomy/undo/:audit_id). También puedes simplemente re-aplicar un nivel más suave — baja tight de vuelta a balanced, o balanced de vuelta a permissive — en cualquier momento.
Deshacer restaura desde el snapshot de auditoría de la aplicación más reciente. Si has hecho ediciones manuales de política desde la aplicación que estás deshaciendo, ese snapshot ya no es el último sin usar y deshacer declina en vez de revertir silenciosamente esas ediciones. Cuando eso pasa, re-aplica un nivel más suave en su lugar — siempre está disponible.

​
6. De dónde vienen los veredictos de cada movimiento

El lanzamiento nunca bloquea algo que no pediste, porque cada postura mapea a un mecanismo explícito y observable:
PosturaMecanismoResultado
Observefirewall_observe_mode del espacio de trabajo activado + flag de guardrailPermitir + registrar huecos / coincidencias
Shadowshadow_mode por políticaVeredicto real computado, degradado a audit, registrado [shadow] would …
Enforceshadow_mode apagado + autonomía tight/balanceddeny / mask / cap_cost van en vivo
Los cuatro términos — modo observe, el veredicto audit, la acción flag y shadow_mode — son interruptores distintos, documentados lado a lado en Modos de aplicación.

​
7. Próximos pasos

Modos de aplicación

El mapa de mecanismos detrás de observe, shadow y enforce.

Línea base de Agentes Seguros

Qué establece cada nivel de autonomía, y cómo simularlo primero.

Domar un agente autónomo

El siguiente paso una vez que has aplicado: topes de coste, detección de anomalías y aprobaciones.

Agent Firewall

Políticas, reglas, veredictos, modo shadow y el gateway MCP al completo.
Un go-live en el que puedes confiar es un lanzamiento, no un interruptor. Observa lo que hace tu agente, haz shadow de la política contra su tráfico real, luego aplica — balanced antes de tight — y cada regla queda verificada en producción antes de que la bloquee siquiera.