Vai al contenuto principale
Una singola chiamata a tool può sembrare perfettamente innocente. Leggi un record CRM: consentito. Chiama un tool di export: consentito. Colpisci un host esterno: consentito. La forma dell’esecuzione — cinquanta letture, poi un export, poi egress verso un host che non hai mai visto alle 3 di domenica notte — è l’attacco. I verdetti per chiamata giudicano ogni chiamata in isolamento e non lo vedono mai. Questa pagina copre i due meccanismi del firewall che osservano un’esecuzione nel tempo anziché una chiamata alla volta: le regole di sequenza (una catena ordinata che scrivi tu) e il rilevamento di anomalie comportamentali (deviazione dal normale appreso del tuo workspace). Insieme sono il modo in cui rilevi il comportamento da catena d’attacco degli agent che nessuna singola regola di allow/deny può catturare.
Tutto qui è configurato nella console (Security → Firewall), le cui rotte di gestione usano la tua sessione / token di accesso — non una chiave di relay sk-orca-…. Le chiamate /v1/* del tuo agent non cambiano.

​
1. Perché le regole per chiamata mancano la catena

I glob sui tool e le clausole sugli argomenti del firewall sono stateless e deterministici per design — decidono una chiamata, velocemente, sul percorso caldo. È esattamente ciò che vuoi per “blocca shell.exec rm -rf”. È esattamente sbagliato per un’esfiltrazione a fuoco lento dove ogni singola chiamata è legale. Due tool complementari colmano il gap:

Regole di sequenza

Una regola che scrivi tu che corrisponde a una catena ordinata di chiamate in una finestra temporale — “bulk read → export → egress.” Nomini tu il pattern.

Rilevamento di anomalie

Il firewall apprende la forma normale dell’uso dei tool di ogni workspace e segnala le deviazioni — loop di retry, percorsi di tool mai visti prima e picchi di volume/costo. Nessuna regola da scrivere.

​
2. Regole di sequenza: nomina la catena d’attacco

Una regola sequence vive dentro una policy del firewall come ogni altra regola, ma invece di un singolo tool_name_glob porta un elenco ordinato di step. Ogni step è un glob sul tool con un min_count opzionale e un egress: true opzionale; gli step devono verificarsi in ordine (l’interleaving con chiamate non correlate va bene) e l’intera catena deve completarsi entro window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Questa scatta quando un agent legge 50+ record crm.*, poi chiama qualsiasi tool *.export, poi fa qualsiasi chiamata egress — tutto entro dieci minuti. Ogni chiamata da sola passerebbe; il pattern è il segnale.
Una sequenza è valutata sulla chiamata che la completa. Il loop di regole inline salta le regole di catena (una chiamata non può soddisfare una catena multi-step); il match gira quando una chiamata potrebbe essere l’ultimo step di una catena, momento in cui il firewall recupera gli eventi recenti di quel principal e testa la catena. Il verdict che imposti sulla regola è ciò che poi succede alla chiamata che completa: audit la registra e la lascia passare, pending_approval la mette in attesa per la revisione umana, e deny la blocca. Quindi una catena può fermare la sua chiamata finale in tempo reale — scegli il verdetto adatto. Usa audit quando vuoi solo rilevare e avvisare; usa pending_approval o deny (o abbina a un deny / regola egress per chiamata) quando ti serve uno stop netto.
La sintassi completa del campo sequence — window_seconds: 0 per nessun limite temporale, i default di min_count, la semantica di ordinamento degli step — è nello schema delle regole. Scrivi le regole di sequenza nell’editor delle regole della console; salvare è un’azione Developer+.

​
3. Rilevamento di anomalie: deviazione dal normale appreso

Dove le regole di sequenza chiedono “è successo questo specifico pattern”, il rilevamento di anomalie chiede “c’è qualcosa in questa esecuzione che è anormale per questo workspace”. Non serve alcuna regola — il firewall costruisce una baseline dal tuo stesso traffico e valuta l’attività live rispetto ad essa. Emergono quattro tipi:
Il volume di chiamate per-(tool, chiave) valutato rispetto alla baseline appresa per questa ora-della-settimana. Una riga emerge quando il conteggio supera un pavimento assoluto e gira alto rispetto alla baseline, o quando il suo z-score supera la soglia statistica. Così “100 chiamate db.query alle 3 di domenica” salta all’occhio anche se un burst delle stesse dimensioni il martedì alle 14 non lo farebbe.
La stessa idea applicata alla spesa: un tool che brucia multipli del suo costo di baseline appreso per questa ora-della-settimana. Il preavviso del denial-of-wallet — abbinalo a una regola cap_cost per applicare un tetto netto.
Un gruppo (conversazione, tool, argomenti) che si ripete molte volte in una finestra stretta — un agent bloccato a chiamare lo stesso tool che fallisce con gli stessi argomenti ripetutamente, anziché un polling legittimo lento.
Una transizione tool_a → tool_b che questo workspace non ha mai fatto prima. La prima volta che un agent va da read_file direttamente a http_fetch, quell’arco si illumina anche se entrambi i tool sono individualmente consentiti.

​
La baseline ora-della-settimana

La baseline è una media mobile a 14 giorni suddivisa per ora della settimana (weekday × 24 + hour), così martedì-14:00 è confrontato specificamente con la storia passata di martedì-14:00 — non una media piatta di sempre che laverebbe via il tuo vero ritmo giornaliero e settimanale. Un workspace nuovo di zecca senza ancora una norma appresa cattura comunque un’inondazione ovvia tramite un pavimento assoluto, così sei protetto dal primo giorno.
Il feed riporta nomi di tool, id di chiave redatti, conteggi e uno z-score — mai materiale grezzo di chiave. Ogni anomalia porta una remediation suggerita (rate_limit, review o block_tool) così il passo successivo è un clic, non una supposizione.

​
4. Una procedura concreta

Supponiamo che un prompt compromesso spinga uno dei tuoi agent in un loop di fallimento stretto, poi sondi un percorso di export che non ha mai toccato. Ecco cosa vedi — nessuna regola scritta in anticipo:
1

L'agent si comporta male

Istruzioni iniettate spingono l’agent a riprovare un db.query che fallisce con argomenti identici, poi a chiamare report.export seguito da un fetch in uscita — un percorso che questo workspace non ha mai eseguito.
2

Apri il feed delle anomalie

In Security → Firewall → Anomalies, l’esecuzione fa emergere un retry_loop su db.query e un novel_path sull’arco report.export → http_fetch. Leggere il feed è un’azione Member — chiunque nel team può fare triage.
3

Conferma nella trace degli eventi

Clicca fino al log degli eventi e alle analytics dell’esecuzione per vedere la sequenza esatta delle chiamate, correlata all’esecuzione dell’agent e alla conversazione. Il feed delle anomalie è leggibile dai Member, ma il log degli eventi e la trace dell’esecuzione portano la provenienza delle chiamate a tool e sono Developer+.
4

Converti la scoperta in una regola

Ora che hai visto la catena, codificala: un deny sull’export pericoloso, una allow-list di egress sul fetch, o una regola di sequenza che audita l’intero pattern la prossima volta. Il rilevamento di anomalie trova l’ignoto; una regola fissa il noto.
Se il feed è rumoroso mentre metti a punto — un job batch legittimo che fa genuinamente picco ogni domenica, diciamo — metti in snooze il feed delle anomalie per un massimo di 7 giorni mentre indaghi. Lo snooze è un’azione Developer+; la finestra è limitata dal server così il rilevamento torna sempre da solo.

​
5. Regole di sequenza vs. rilevamento di anomalie

Risolvono problemi adiacenti — scegli quello che corrisponde a ciò che sai:
Regola di sequenzaRilevamento di anomalie
Scrivi tuLa catena esattaNulla — apprende
CatturaUn pattern multi-step notoL’ignoto / anormale
AgisceApplica il verdetto della regola alla chiamata che completa (audit / pending_approval / deny)Emerge sul feed
Un workspace maturo fa girare entrambi: il rilevamento di anomalie è il radar che fa emergere catene che non avevi anticipato — solo emersione, mai blocco; le regole di sequenza sono come codifichi quelle che hai, così sono etichettate, tracciate e (con un verdetto pending_approval o deny) in grado di governare la chiamata che completa. Per uno stop netto su una singola chiamata indipendentemente da qualsiasi catena, ricorri a un verdetto per chiamata.

​
6. RBAC e le rotte dietro il feed

Il feed delle anomalie e le regole di sequenza stanno sotto le rotte di gestione del firewall del workspace — il tuo token di sessione / di accesso, mai una chiave di relay:
Metodo & pathRuoloScopo
GET /api/workspace/firewall/anomaliesMemberLegge il feed delle anomalie (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Mette in snooze il feed ({until}, limitato a 7 giorni).
POST /api/workspace/firewall/rulesDeveloper+Crea una regola di sequenza (o qualsiasi) sotto una policy.
POST /api/workspace/firewall/testDeveloper+Dry-run di una policy contro una chiamata di esempio prima di farci affidamento.
Le letture del feed sono aperte a ogni Member così l’intero team può fare triage; scrivere regole e mettere in snooze il feed sono scritture Developer+, coerenti con il resto del modello RBAC del firewall.

​
Dove andare dopo

Schema delle regole

Il campo sequence completo — step, min_count, window_seconds e ogni altro campo di regola.

Log degli eventi

Dove atterrano sequenze corrisposte e anomalie — filtra per esecuzione, superficie e verdetto.

Tetto di costo

Trasforma un segnale burn_spike in un tetto di spesa netto per esecuzione.

Controllo dell'egress

Ferma lo step finale di esfiltrazione di una catena al confine di rete.
Per i playbook degli attaccanti che questi meccanismi contrastano, vedi attacchi concatenati, esfiltrazione di dati e agenzia eccessiva. Per il riferimento approfondito del firewall, vedi Regole del Firewall.