Vai al contenuto principale
Quando la tua policy del firewall giudica una chiamata a tool, scrive una riga. Il feed degli eventi è quel log in corso: un record per valutazione, che porta il verdetto, la superficie su cui è scattato, il tool, la motivazione e l’esecuzione/sessione a cui apparteneva. È come rispondi all’unica domanda che conta dopo aver rilasciato una policy — il firewall ha effettivamente fatto ciò che penso abbia fatto, sulle chiamate su cui penso l’abbia fatto? Questa è la tua superficie di log del firewall AI. Ogni allow, ogni deny, ogni approvazione messa in attesa, ogni “avrebbe fatto” della shadow mode atterra qui, filtrabile e correlato all’esecuzione dell’agent che l’ha prodotto.
Il feed degli eventi è Developer+ in lettura. Ogni riga riserva un campo args_summary limitato per uno snapshot degli argomenti della chiamata a tool, quindi la superficie sta sopra quelle leggibili dai Member (impostazioni, policy, discovered tools, il feed delle anomalie). Configura tutto questo dalla console — sono rotte autenticate con la sessione, non chiamate di relay.

​
1. Cosa atterra nel feed degli eventi

Ogni valutazione che il motore esegue è registrata — non solo i block. Un allow e un audit lasciano una riga esattamente come fa un deny, così il feed è una traccia completa, non un log di eccezioni. Il verdetto su una riga è quello che l’agent ha effettivamente visto:
VerdettoSignifica
allow / auditLasciato passare; audit lo segnala come qualcosa che volevi osservare.
denyBloccato — firewall_blocked (HTTP 400) inbound, errore di tool su mcp.
sanitizeInoltrato con le sottostringhe corrispondenti redatte dagli argomenti della chiamata.
pending_approvalMesso in attesa per un umano; la riga marca che la chiamata è stata governata.
observeNessuna policy ha corrisposto — un gap di copertura in observe-mode.
Non vedrai mai un cap_cost letterale nel feed. Una regola cap-cost si risolve in un concreto allow o deny al momento della valutazione, ed è quello che viene loggato — il verdetto che l’esecuzione ha effettivamente sperimentato.
In shadow mode i verdetti applicativi vengono declassati a audit e la motivazione è prefissata [shadow] would …, così il feed ti mostra esattamente cosa una policy avrebbe bloccato prima che tu la renda live.

​
2. Cosa registra ogni evento

Un singolo evento è uno snapshot denormalizzato — abbastanza per ricostruire la decisione senza fare join con nient’altro:
verdict, surface (inbound / response / mcp / egress), tool_name, e una reason umana (“destructive shell command”, “egress to 169.254.169.254 denied”). Quando la regola corrispondente aveva un’etichetta, policy_name e rule_label nominano la regola esatta che è scattata — così la riga punta direttamente alla linea che hai scritto.
request_id unisce l’evento al log delle richieste; conversation_id raggruppa una sessione multi-turno; agent_run_id (con step_id / parent_step_id) lo lega a un’intera esecuzione dell’agent e alla chiamata LLM che ha richiesto il tool. Sono questi a fare del feed una trace, non un elenco piatto — vedi §4.
token_name, model_name e l’ip del chiamante — la chiave, il modello e l’origine dietro la chiamata. skill_name nomina la skill proprietaria quando la chiamata era attribuibile a una, e quarantine segnala un hold da skill-quarantine.
args_summary è il campo di snapshot limitato degli argomenti della chiamata a tool (il motivo per cui questa superficie è Developer+). Su un evento egress, egress_host registra la destinazione in uscita che è stata giudicata.
args_summary è limitato — i byte grezzi degli argomenti non vengono mai scritti verbatim nel feed, e l’hash di raggruppamento del retry-loop che sta dietro il rilevamento di anomalie è solo lato server: non viaggia mai nell’API.

​
3. Un esempio concreto

Il tuo agent ha emesso una chiamata shell.exec con rm -rf /data, una regola deny l’ha catturata, e vuoi vedere quella sola decisione. Filtra il feed per verdetto e tool: 
# 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 rende le stesse righe come una tabella filtrabile — raramente colpisci la rotta a mano. Configura i filtri, approfondisci un’esecuzione ed esporta dalla vista degli eventi; il curl sopra è solo per mostrare la forma.
$ORCA_CONSOLE_TOKEN è il tuo token di sessione / di accesso, non una chiave di relay sk-orca-…. Le rotte /api/workspace/firewall/* sono autenticate con la console e role-gated; solo il traffico /v1/* usa una chiave di relay.

​
4. Correla per esecuzione e sessione

Il motivo per cui ogni evento porta agent_run_id e conversation_id è perché tu possa smettere di guardare le chiamate in isolamento e iniziare a chiederti cosa ha fatto questo agent nell’intera sua esecuzione:
FiltroDomanda a cui risponde
run_id=<run>Ogni verdetto in un’esecuzione dell’agent — l’intera traccia delle azioni.
session_id=<conv>Ogni verdetto attraverso una conversazione multi-turno.
verdict=deny,pending_approvalLa vista “cosa è stato fermato o messo in attesa” in una query.
surface=egressSolo le decisioni sulla destinazione in uscita — la lente di esfiltrazione.
L’elenco degli eventi accetta anche since / until (secondi unix) e limit / skip per la paginazione. Per la vista aggregata — una riga per esecuzione o sessione con una ripartizione per verdetto, tool e modelli distinti e primo/ultimo visto — la console legge GET /api/workspace/firewall/events/aggregate?group_by=run (o group_by=session), e l’albero di trace dell’agent legge /trace/by-run. Entrambi sono Developer+, come il feed grezzo.
Dal drawer del log delle richieste puoi fare pivot nell’altra direzione: GET /api/workspace/firewall/events/by-request/:request_id restituisce ogni evento del firewall catturato sotto una singola richiesta — comodo quando una richiesta ha fatto scattare diverse regole su più superfici.

​
5. Retention e cancellazione

Gli eventi del firewall portano il proprio orizzonte di retention — un default di 30 giorni, limitato dal server a un massimo netto di 365 giorni. Ogni evento è scritto con una scadenza e fatto invecchiare automaticamente da un indice TTL; nulla nel feed vive oltre la tua impostazione di retention. Una richiesta di diritto alla cancellazione si propaga anche qui: eliminare un utente avvia un periodo di grazia di 30 giorni, dopo il quale le sue PII vengono ripulite e i suoi eventi del firewall vengono eliminati insieme ai log delle richieste e ai match dei guardrail dello stesso scope.

​
Dove andare dopo

Verdetti

Cosa ha effettivamente fatto alla chiamata ogni verdetto nel feed.

Shadow mode

Leggi il feed in modalità “avrebbe fatto” prima di applicare.

Stage e superfici

Le quattro superfici che il campo surface nomina.

Riferimento del firewall

Il riferimento completo di policy, regole e API.
Per le minacce che questi log ti aiutano a catturare sul fatto, vedi esfiltrazione di dati e chiamate a tool pericolose. Per come il firewall si abbina al filtraggio del testo di prompt/risposta, vedi firewall + guardrails.