Saltar para o conteúdo principal
Quando sua política de firewall julga uma chamada de ferramenta, ela escreve uma linha. O feed de eventos é esse log corrente: um registro por avaliação, carregando o veredito, a superfície em que disparou, a ferramenta, o motivo, e a run/sessão à qual pertencia. É como você responde à única pergunta que importa depois de você lançar uma política — o firewall de fato fez o que eu acho que fez, nas chamadas em que eu acho que fez? Esta é sua superfície de logs de firewall de IA. Cada allow, cada deny, cada aprovação retida, cada “would-have” de shadow mode aterrissa aqui, filtrável e correlacionado de volta à run de agente que o produziu.
O feed de eventos é Developer+ para leitura. Cada linha reserva um campo args_summary limitado para um snapshot de argumento de chamada de ferramenta, então a superfície se situa acima das legíveis por Member (configurações, políticas, ferramentas descobertas, o feed de anomalias). Configure tudo isso a partir do console — essas são rotas autenticadas por sessão, não chamadas de relay.

​
1. O que aterrissa no feed de eventos

Cada avaliação que o motor roda é registrada — não apenas os blocks. Um allow e um audit deixam uma linha exatamente como um deny deixa, então o feed é uma trilha completa, não um log de exceções. O veredito em uma linha é o que o agente de fato viu:
VereditoSignifica
allow / auditDeixou passar; audit sinaliza como algo que você quis observar.
denyBloqueado — firewall_blocked (HTTP 400) no inbound, erro de ferramenta no mcp.
sanitizeEncaminhado com substrings correspondentes redigidas dos argumentos da chamada.
pending_approvalRetido para um humano; a linha marca que a chamada foi gated.
observeNenhuma política correspondeu — um gap de cobertura de observe-mode.
Você nunca verá um cap_cost literal no feed. Uma regra cap-cost resolve para um allow ou deny concreto em tempo de avaliação, e é isso que é registrado — o veredito que a run de fato experimentou.
No shadow mode os vereditos de enforcement são rebaixados para audit e o motivo recebe o prefixo [shadow] would …, então o feed mostra exatamente o que uma política teria bloqueado antes de você ativá-la.

​
2. O que cada evento registra

Um único evento é um snapshot desnormalizado — suficiente para reconstruir a decisão sem fazer join de volta com nada:
verdict, surface (inbound / response / mcp / egress), tool_name, e um reason legível (“destructive shell command”, “egress to 169.254.169.254 denied”). Quando a regra correspondente tinha um label, policy_name e rule_label nomeiam a regra exata que disparou — então a linha aponta direto de volta para a linha que você escreveu.
request_id faz join do evento com o log de requisições; conversation_id agrupa uma sessão multi-turno; agent_run_id (com step_id / parent_step_id) o liga a uma run de agente completa e à chamada de LLM que solicitou a ferramenta. São essas que fazem do feed um trace, não uma lista plana — veja §4.
token_name, model_name, e o ip do chamador — a chave, o modelo e a origem por trás da chamada. skill_name nomeia a skill proprietária quando a chamada era atribuível a uma, e quarantine sinaliza uma retenção por quarentena de skill.
args_summary é o campo de snapshot limitado de argumento de chamada de ferramenta (o motivo de esta superfície ser Developer+). Em um evento de egress, egress_host registra o destino outbound que foi julgado.
args_summary é limitado — os bytes brutos do argumento nunca são escritos literalmente no feed, e o hash de agrupamento de retry-loop que sustenta a detecção de anomalias é apenas-servidor: ele nunca é enviado na API.

​
3. Um exemplo concreto

Seu agente emitiu uma chamada shell.exec com rm -rf /data, uma regra deny a pegou, e você quer ver aquela decisão. Filtre o feed por veredito e ferramenta: 
# 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
}
O console renderiza as mesmas linhas como uma tabela filtrável — você raramente acessa a rota à mão. Configure filtros, aprofunde em uma run, e exporte a partir da visão de eventos; o curl acima é apenas para mostrar o formato.
$ORCA_CONSOLE_TOKEN é seu token de sessão / acesso, não uma chave de relay sk-orca-…. As rotas /api/workspace/firewall/* são autenticadas por console e role-gated; apenas o tráfego /v1/* usa uma chave de relay.

​
4. Correlacionar por run e sessão

O motivo de cada evento carregar agent_run_id e conversation_id é para que você possa parar de olhar chamadas isoladamente e começar a perguntar o que este agente fez ao longo de toda a sua run:
FiltroPergunta que responde
run_id=<run>Cada veredito em uma run de agente — a trilha de ação completa.
session_id=<conv>Cada veredito ao longo de uma conversa multi-turno.
verdict=deny,pending_approvalA visão “o que foi parado ou retido” em uma consulta.
surface=egressApenas decisões de destino outbound — a lente de exfiltração.
A lista de eventos também aceita since / until (segundos unix) e limit / skip para paginação. Para a visão consolidada — uma linha por run ou sessão com um breakdown por veredito, ferramentas e modelos distintos, e primeiro/último-visto — o console lê GET /api/workspace/firewall/events/aggregate?group_by=run (ou group_by=session), e a árvore de trace de agente lê /trace/by-run. Ambos são Developer+, igual ao feed bruto.
A partir do drawer de log de requisições você pode pivotar na outra direção: GET /api/workspace/firewall/events/by-request/:request_id retorna cada evento de firewall capturado sob uma única requisição — útil quando uma requisição disparou várias regras em superfícies diferentes.

​
5. Retenção e apagamento

Os eventos de firewall carregam seu próprio horizonte de retenção — um padrão de 30 dias, server-clamped a um máximo rígido de 365 dias. Cada evento é escrito com uma expiração e envelhecido automaticamente por um índice TTL; nada no feed vive além da sua configuração de retenção. Uma requisição de direito ao apagamento cascateia aqui também: deletar um usuário inicia um período de carência de 30 dias, após o qual seus PII são limpos e seus eventos de firewall são purgados junto com os logs de requisição e correspondências de guardrail do mesmo escopo.

​
Para onde ir a seguir

Vereditos

O que cada veredito no feed de fato fez com a chamada.

Shadow mode

Leia o feed em modo “would-have” antes de aplicar o enforcement.

Stages & superfícies

As quatro superfícies que o campo surface nomeia.

Referência de firewall

A referência completa de política, regra e API.
Para as ameaças que estes logs ajudam você a pegar em flagrante, veja exfiltração de dados e chamadas de ferramenta perigosas. Para como o firewall se combina com a filtragem de texto de prompt/response, veja firewall + guardrails.