Saltar al contenido principal
Cuando tu política de firewall juzga una llamada a herramienta, escribe una fila. El feed de eventos es ese registro continuo: un registro por evaluación, que lleva el veredicto, la superficie en que se disparó, la herramienta, la razón, y la ejecución/sesión a la que pertenecía. Es cómo respondes la única pregunta que importa después de lanzar una política — ¿el firewall realmente hizo lo que creo que hizo, en las llamadas en que creo que lo hizo? Esta es tu superficie de logs del firewall de IA. Cada allow, cada deny, cada aprobación retenida, cada “habría” de modo shadow aterriza aquí, filtrable y correlacionado de vuelta a la ejecución de agente que lo produjo.
El feed de eventos es Developer+ para leer. Cada fila reserva un campo args_summary acotado para un snapshot de argumentos de llamada a herramienta, así que la superficie se sitúa por encima de las legibles por Member (configuración, políticas, herramientas descubiertas, el feed de anomalías). Configura todo esto desde la consola — estas son rutas autenticadas por sesión, no llamadas de relay.

​
1. Qué aterriza en el feed de eventos

Cada evaluación que el motor ejecuta se registra — no solo los bloqueos. Un allow y un audit dejan una fila exactamente como lo hace un deny, así que el feed es un rastro completo, no un registro de excepciones. El veredicto en una fila es el que el agente realmente vio:
VeredictoSignifica
allow / auditDejado pasar; audit lo marca como algo que quisiste observar.
denyBloqueado — firewall_blocked (HTTP 400) inbound, error de herramienta en mcp.
sanitizeReenviado con las subcadenas coincidentes redactadas de los argumentos de la llamada.
pending_approvalRetenido para un humano; la fila marca que la llamada fue gobernada.
observeNinguna política coincidió — un hueco de cobertura de modo observe.
Nunca verás un cap_cost literal en el feed. Una regla cap-cost resuelve a un allow o deny concreto en tiempo de evaluación, y eso es lo que se registra — el veredicto que la ejecución realmente experimentó.
En modo shadow los veredictos de aplicación se degradan a audit y la razón se prefija con [shadow] would …, así que el feed te muestra exactamente qué habría bloqueado una política antes de cambiarla a vivo.

​
2. Qué registra cada evento

Un solo evento es un snapshot desnormalizado — suficiente para reconstruir la decisión sin volver a unir con nada:
verdict, surface (inbound / response / mcp / egress), tool_name, y una reason humana (“destructive shell command”, “egress to 169.254.169.254 denied”). Cuando la regla coincidente tenía una etiqueta, policy_name y rule_label nombran la regla exacta que se disparó — así que la fila apunta directamente de vuelta a la línea que escribiste.
request_id une el evento al registro de solicitudes; conversation_id agrupa una sesión de varios turnos; agent_run_id (con step_id / parent_step_id) lo ata a una ejecución de agente completa y la llamada al LLM que solicitó la herramienta. Estas son las que hacen del feed una traza, no una lista plana — ver §4.
token_name, model_name, y la ip del llamador — la clave, el modelo y el origen detrás de la llamada. skill_name nombra la skill propietaria cuando la llamada era atribuible a una, y quarantine marca una retención de cuarentena de skill.
args_summary es el campo de snapshot de argumentos de llamada a herramienta acotado (la razón por la que esta superficie es Developer+). En un evento egress, egress_host registra el destino saliente que fue juzgado.
args_summary está acotado — los bytes de argumentos en bruto nunca se escriben literalmente en el feed, y el hash de agrupación de retry-loop que respalda la detección de anomalías es solo del servidor: nunca se envía en la API.

​
3. Un ejemplo concreto

Tu agente emitió una llamada shell.exec con rm -rf /data, una regla deny la capturó, y quieres ver esa única decisión. Filtra el feed por veredicto y herramienta: 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
La consola renderiza las mismas filas como una tabla filtrable — rara vez golpeas la ruta a mano. Configura filtros, profundiza en una ejecución, y exporta desde la vista de eventos; el curl de arriba es solo para mostrar la forma.
$ORCA_CONSOLE_TOKEN es tu sesión / token de acceso, no una clave de relay sk-orca-…. Las rutas /api/workspace/firewall/* están autenticadas por consola y gobernadas por rol; solo el tráfico /v1/* usa una clave de relay.

​
4. Correlacionar por ejecución y sesión

La razón por la que cada evento lleva agent_run_id y conversation_id es para que puedas dejar de mirar las llamadas de forma aislada y empezar a preguntar qué hizo este agente a lo largo de toda su ejecución:
FiltroPregunta que responde
run_id=<run>Cada veredicto en una ejecución de agente — el rastro de acción completo.
session_id=<conv>Cada veredicto a lo largo de una conversación de varios turnos.
verdict=deny,pending_approvalLa vista de “qué se detuvo o retuvo” en una consulta.
surface=egressSolo decisiones de destino saliente — la lente de exfiltración.
La lista de eventos también acepta since / until (segundos unix) y limit / skip para paginación. Para la vista agregada — una fila por ejecución o sesión con un desglose por veredicto, herramientas y modelos distintos, y primera/última vez vistos — la consola lee GET /api/workspace/firewall/events/aggregate?group_by=run (o group_by=session), y el árbol de traza de agente lee /trace/by-run. Ambos son Developer+, igual que el feed en bruto.
Desde el cajón del registro de solicitudes puedes pivotar en la otra dirección: GET /api/workspace/firewall/events/by-request/:request_id devuelve cada evento del firewall capturado bajo una sola solicitud — útil cuando una solicitud disparó varias reglas a través de superficies.

​
5. Retención y borrado

Los eventos del firewall llevan su propio horizonte de retención — un valor por defecto de 30 días, acotado por el servidor a un máximo duro de 365 días. Cada evento se escribe con una expiración y se envejece automáticamente por un índice TTL; nada en el feed vive más allá de tu ajuste de retención. Una solicitud de derecho al borrado cascada aquí también: eliminar un usuario inicia un periodo de gracia de 30 días, después del cual su PII se limpia y sus eventos del firewall se purgan junto a los registros de solicitudes y las coincidencias de guardrail del mismo alcance.

​
Dónde ir a continuación

Veredictos

Qué le hizo realmente a la llamada cada veredicto en el feed.

Modo shadow

Lee el feed en modo “habría” antes de aplicar.

Etapas y superficies

Las cuatro superficies que el campo surface nombra.

Referencia del Firewall

La referencia completa de política, regla y API.
Para las amenazas que estos logs te ayudan a capturar en el acto, ver exfiltración de datos y llamadas a herramienta peligrosas. Para cómo el firewall se empareja con el examen de texto de prompt/respuesta, ver firewall + guardrails.