Vai al contenuto principale
Le regole del firewall statiche catturano le chiamate che sapevi di dover nominare. Non possono catturare la chiamata che è individualmente consentita ma sbagliata in aggregato — 200 chiamate db.query alle 3 di domenica, un agent che martella un tool che fallisce in un loop stretto, un salto tool-a-tool che questo workspace non ha mai fatto prima. Ogni chiamata passa ogni regola; il pattern è il problema. Il rilevamento di anomalie del firewall è il layer comportamentale. Il gateway apprende la forma normale dell’uso dei tool del tuo workspace e valuta l’attività live rispetto ad essa, facendo emergere le deviazioni su un feed che ogni Member può leggere. È come noti un agent compromesso o un loop incontrollato senza aver pre-scritto una regola per una forma che non avevi mai visto. Questa pagina è l’atterraggio focalizzato per quel feed di firewall anomaly detection; la Panoramica del Firewall è il riferimento approfondito.
Il feed delle anomalie è rilevamento, non applicazione. Ti dice cosa sembra fuori posto — non blocca. Quando un pattern è reale, lo trasformi in una regola o in un verdetto con rate-limit così la prossima occorrenza viene fermata inline. Leggere il feed è aperto a ogni Member; trasformare una scoperta in policy è Developer+.

​
1. Cosa segnala il rilevamento di anomalie del firewall

Quattro tipi di segnale, ognuno legato a una diversa modalità di fallimento:
Il volume di chiamate per-tool valutato rispetto a una baseline ora-della-settimana appresa. Un tool fa scattare rate_spike quando il suo conteggio supera un pavimento assoluto e gira alto rispetto alla baseline di *quell’*ora, o quando il suo z-score supera la soglia. Basarsi sull’ ora-della-settimana (non sull’ora-del-giorno) significa che martedì-14:00 è confrontato con i passati martedì-14:00, così il traffico di picco legittimo nei giorni feriali non si legge come un picco mentre lo stesso volume alle 3 di domenica sì.
Lo stesso confronto ora-della-settimana, applicato al costo accumulato anziché al conteggio delle chiamate. Un tool la cui spesa gira ben oltre la sua norma di costo appresa emerge come un burn_spike — il segnale di preavviso per un agent che è costoso prima di essere distruttivo.
Un gruppo (conversazione, tool, argomenti) che si ripete molte volte dentro una finestra stretta — un agent bloccato a ri-emettere la stessa chiamata a tool che fallisce anziché recuperare. Un polling lento e legittimo non lo fa scattare; il segnale è un loop stretto.
Una transizione consecutiva tool_a → tool_b per cui questo workspace non ha alcuna baseline appresa. La prima volta che un agent va, diciamo, crm.read → http.fetch, quell’arco è inedito — esattamente il tipo di step che una catena di esfiltrazione di dati compie.
Il rilevamento di anomalie complementa le regole di sequenza. Una regola di sequenza corrisponde a una catena che hai definito in anticipo; novel_path segnala una transizione che non hai definito — è come scopri le catene per cui vale la pena scrivere una regola di sequenza.

​
2. La baseline di 14 giorni

Il detector non è una soglia fissa — è una norma appresa. Per ogni bucket (tool, ora-della-settimana) il gateway mantiene un conteggio di chiamate e un costo attesi mobili, riempiti da una retrospettiva di 14 giorni (circa due occorrenze di ogni bucket ora-della-settimana — abbastanza da smussare un singolo giorno strano senza perdere la forma settimanale). novel_path usa la baseline di transizione parallela: il conteggio di occorrenze appreso per ogni arco tool_a → tool_b in quell’ora-della-settimana. Un workspace nuovo di zecca non ha ancora una baseline. Va bene: senza una norma appresa, i detector di volume ricadono su un pavimento assoluto, così un’inondazione ovvia viene comunque catturata dal primo giorno mentre le norme per-ora si riempiono.
SegnaleDa cosa apprende
rate_spike / burn_spikeConteggio e costo per-(tool, ora-della-settimana), mobile su 14 giorni.
novel_pathConteggio di transizione per-(tool_a → tool_b, ora-della-settimana).
retry_loopNessuna baseline — una soglia di ripetizione su finestra su (conversazione, tool, args).
Il feed riporta solo nomi di tool, id di token redatti e conteggi. Un id di chiave API grezzo non compare mai — ogni item porta un digest unidirezionale del token chiamante, così puoi distinguere due anomalie senza che il feed faccia mai trapelare la chiave dietro di esse.

​
3. Una lettura concreta

Diciamo che una chiave di un agent inizia a fare loop. Tira il feed nella console sotto Security → Firewall → Anomalies, o leggilo direttamente — qualsiasi Member può: 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
Un item retry_loop non porta alcun baseline o z_score (quei campi restano 0 — appartengono ai detector di volume/costo), e porta un id opaco stabile così due loop distinti sullo stesso tool non collidono su una riga. Un rate_spike è l’inverso: riporta un baseline appreso e uno z_score, e lascia id vuoto.
$ORCA_SESSION_TOKEN è il tuo token di sessione / di accesso della console — la stessa auth di ogni rotta di gestione /api/workspace/firewall/*. Non è una chiave di relay sk-orca-… (quelle sono solo per le chiamate al modello /v1/*) e non è una chiave firewall-gateway. Una chiave di relay su questa rotta viene rifiutata.
Ogni item nomina il tool, il token redatto, quante chiamate sono scattate, lo z-score (solo segnali di volume/costo) e un suggested_action (rate_limit, block_tool o review). Da qui agisci: lascia una regola deny sul tool, valida i suoi argomenti, o apri il log degli eventi per vedere esattamente cosa ha fatto l’agent.

​
4. Mettere in snooze il feed

Un load test noto o un backfill pianificato illumineranno il feed. Anziché inseguire il rumore, mettilo in snooze — per un massimo di 7 giorni: 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
Mentre uno snooze è attivo il feed non restituisce item e riporta snoozed_until; si azzera da solo nel momento in cui la scadenza passa. Il limite è un tetto netto — un until digitato male o ostile più in là viene limitato così il rilevamento di anomalie non può essere silenziato indefinitamente. Inviare un until passato o attuale azzera uno snooze esistente.
Leggere il feed è un’azione Member; metterlo in snooze è Developer+ — silenziare un segnale di sicurezza a livello di workspace è una scrittura, non una lettura.

​
5. RBAC in breve

La superficie di analytics si divide lungo la solita linea leggi/agisci:
AzioneRuolo
Leggere il feed delle anomalieMember
Leggere impostazioni, policy, discovered toolsMember
Mettere in snooze il feedDeveloper+
Events, runs, aggregate, traceDeveloper+
Scrivere una regola da una scopertaDeveloper+
Le viste aggregate più leggere — impostazioni, policy e la mappa di copertura dei discovered-tools — sono anch’esse letture Member; il dettaglio a livello di riga di eventi e runs è Developer+, perché porta dati di argomenti per chiamata.

​
6. Dal segnale alla policy

Il feed è l’inizio di un loop, non la fine:
1

Individua il pattern

Un novel_path o rate_spike mostra una forma che non ti aspettavi. Leggilo rispetto al log degli eventi per confermare che sia reale, non un caso isolato.
2

Scrivi la regola

Trasforma la scoperta in applicazione — un block, una clausola sugli argomenti, una regola di sequenza per la catena, o un tetto di costo per il burn.
3

Fai il rollout in sicurezza

Atterra la regola sotto shadow mode prima così misuri il suo raggio d’impatto prima che blocchi una singola chiamata, poi applica.

​
Dove andare dopo

Panoramica del Firewall

Il riferimento completo del rilevamento di anomalie e il resto del piano di policy.

Log degli eventi

Approfondisci da un’anomalia alle chiamate esatte dietro di essa.

Blocca un tool

Trasforma una scoperta in una regola applicativa.

Modalità di applicazione

Come rilevamento, audit, shadow e applicazione si incastrano.
Per le minacce che questi segnali espongono, vedi esfiltrazione di dati e agenzia eccessiva.