Passer au contenu principal
Lorsque votre politique firewall juge un appel d’outil, elle écrit une ligne. Le flux d’événements est ce journal continu : un enregistrement par évaluation, portant le verdict, la surface sur laquelle il s’est déclenché, l’outil, la raison, et l’exécution/session à laquelle il appartenait. C’est ainsi que vous répondez à la seule question qui compte une fois une politique déployée — le firewall a-t-il vraiment fait ce que je crois qu’il a fait, sur les appels où je crois qu’il l’a fait ? C’est votre surface de logs du firewall IA. Chaque allow, chaque deny, chaque approbation mise en attente, chaque « aurait fait » du mode shadow atterrit ici, filtrable et corrélé à l’exécution d’agent qui l’a produit.
Le flux d’événements est en lecture Developer+. Chaque ligne réserve un champ args_summary plafonné pour un instantané des arguments de l’appel d’outil, de sorte que cette surface se situe au-dessus de celles lisibles par les Members (réglages, politiques, outils découverts, le flux d’anomalies). Configurez tout cela depuis la console — ce sont des routes authentifiées par session, pas des appels de relais.

​
1. Ce qui atterrit dans le flux d’événements

Chaque évaluation effectuée par le moteur est enregistrée — pas seulement les blocks. Un allow et un audit laissent une ligne exactement comme un deny, de sorte que le flux est une trace complète, pas un journal d’exceptions. Le verdict d’une ligne est celui que l’agent a réellement vu :
VerdictSignifie
allow / auditLaissé passer ; audit le marque comme quelque chose que vous vouliez surveiller.
denyBloqué — firewall_blocked (HTTP 400) en inbound, erreur d’outil sur mcp.
sanitizeTransmis avec les sous-chaînes correspondantes redactées des arguments de l’appel.
pending_approvalMis en attente d’un humain ; la ligne marque que l’appel a été filtré.
observeAucune politique n’a correspondu — une lacune de couverture en mode observe.
Vous ne verrez jamais un cap_cost littéral dans le flux. Une règle cap-cost se résout en un allow ou deny concret au moment de l’évaluation, et c’est cela qui est journalisé — le verdict que l’exécution a réellement vécu.
En mode shadow, les verdicts appliquants sont rétrogradés en audit et la raison est préfixée [shadow] would …, de sorte que le flux vous montre exactement ce qu’une politique aurait bloqué avant que vous ne la passiez en live.

​
2. Ce que chaque événement enregistre

Un seul événement est un instantané dénormalisé — assez pour reconstruire la décision sans avoir à joindre quoi que ce soit :
verdict, surface (inbound / response / mcp / egress), tool_name, et une reason humaine (« destructive shell command », « egress to 169.254.169.254 denied »). Lorsque la règle correspondante avait un label, policy_name et rule_label nomment la règle exacte qui s’est déclenchée — de sorte que la ligne pointe directement vers la ligne que vous avez écrite.
request_id joint l’événement au log de requête ; conversation_id regroupe une session multi-tours ; agent_run_id (avec step_id / parent_step_id) le relie à une exécution d’agent complète et à l’appel LLM qui a demandé l’outil. Ce sont ces clés qui font du flux une trace, pas une liste plate — voir §4.
token_name, model_name, et l’ip de l’appelant — la clé, le modèle et l’origine derrière l’appel. skill_name nomme le skill propriétaire lorsque l’appel lui était attribuable, et quarantine signale une mise en attente de quarantaine de skill.
args_summary est le champ d’instantané plafonné des arguments de l’appel d’outil (la raison pour laquelle cette surface est Developer+). Sur un événement egress, egress_host enregistre la destination sortante qui a été jugée.
args_summary est plafonné — les octets bruts des arguments ne sont jamais écrits verbatim dans le flux, et le hash de regroupement de boucle de retry qui alimente la détection d’anomalies est uniquement côté serveur : il n’est jamais expédié dans l’API.

​
3. Un exemple concret

Votre agent a émis un appel shell.exec avec rm -rf /data, une règle deny l’a attrapé, et vous voulez voir cette décision précise. Filtrez le flux par verdict et outil : 
# 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 console rend les mêmes lignes sous forme de tableau filtrable — vous atteignez rarement la route à la main. Configurez les filtres, descendez dans une exécution, et exportez depuis la vue des événements ; le curl ci-dessus n’est là que pour montrer la forme.
$ORCA_CONSOLE_TOKEN est votre token de session / d’accès, pas une clé de relais sk-orca-…. Les routes /api/workspace/firewall/* sont authentifiées par console et soumises à des rôles ; seul le trafic /v1/* utilise une clé de relais.

​
4. Corréler par exécution et session

La raison pour laquelle chaque événement porte agent_run_id et conversation_id est que vous puissiez cesser de regarder les appels isolément et commencer à demander qu’a fait cet agent sur toute son exécution :
FiltreQuestion à laquelle il répond
run_id=<run>Chaque verdict d’une exécution d’agent — la trace d’actions complète.
session_id=<conv>Chaque verdict à travers une conversation multi-tours.
verdict=deny,pending_approvalLa vue « ce qui a été arrêté ou mis en attente » en une seule requête.
surface=egressUniquement les décisions de destination sortante — la lentille d’exfiltration.
La liste d’événements accepte aussi since / until (secondes unix) et limit / skip pour la pagination. Pour la vue agrégée — une ligne par exécution ou session avec une répartition par verdict, des outils et modèles distincts, et première/dernière apparition — la console lit GET /api/workspace/firewall/events/aggregate?group_by=run (ou group_by=session), et l’arbre de trace d’agent lit /trace/by-run. Les deux sont Developer+, comme le flux brut.
Depuis le tiroir du log de requête, vous pouvez pivoter dans l’autre sens : GET /api/workspace/firewall/events/by-request/:request_id renvoie chaque événement firewall capturé sous une seule requête — pratique quand une requête a déclenché plusieurs règles sur plusieurs surfaces.

​
5. Rétention et effacement

Les événements firewall portent leur propre horizon de rétention — un défaut de 30 jours, plafonné côté serveur à un maximum dur de 365 jours. Chaque événement est écrit avec une expiration et purgé automatiquement par un index TTL ; rien dans le flux ne vit au-delà de votre réglage de rétention. Une requête de droit à l’effacement se propage aussi ici : supprimer un utilisateur démarre une période de grâce de 30 jours, après laquelle sa PII est purgée et ses événements firewall sont purgés en même temps que les logs de requête et les correspondances de guardrail de la même portée.

​
Où aller ensuite

Verdicts

Ce que chaque verdict du flux a réellement fait à l’appel.

Mode shadow

Lisez le flux en mode « aurait fait » avant d’appliquer.

Étapes & surfaces

Les quatre surfaces que le champ surface nomme.

Référence Firewall

La référence complète des politiques, règles et API.
Pour les menaces que ces logs vous aident à attraper sur le fait, voir exfiltration de données et appels d’outils dangereux. Pour comment le firewall se couple au filtrage de texte des prompts/réponses, voir firewall + guardrails.