Vai al contenuto principale
Hai scritto una policy del firewall — una postura default-deny, un deny su shell.exec, una allow-list di egress — e credi che sia giusta. Ma attivarla contro il traffico di produzione degli agent è un atto di fede: una regola troppo ampia e stai bloccando chiamate che i tuoi agent fanno legittimamente. La shadow mode del firewall è l’interruttore per il rollout sicuro. È un flag per-policy che dice al gateway di valutare la policy esattamente come farebbe in produzione, loggare tutto, ma bloccare nulla. Ogni verdetto applicativo viene declassato a audit, e la motivazione dell’evento è prefissata [shadow] would … così puoi leggere con precisione cosa la policy avrebbe fatto — senza che abbia ancora fatto nulla.
La shadow mode è un flag sulla policy, impostato nella console (o nelle rotte di gestione /api/workspace/firewall/policies, che usano la tua sessione / token di accesso — non una chiave di relay sk-orca-…). Attivarla è un’azione Developer+. Le chiamate di relay /v1/* del tuo agent non cambiano.

​
1. Cosa fa la shadow mode del firewall

Quando il flag shadow_mode di una policy è attivo, il gateway esegue l’intera valutazione — risolve la policy, percorre le regole in ordine di priorità, sceglie un verdetto — e poi, proprio prima che il verdetto abbia effetto, declassa qualsiasi cosa avrebbe modificato la chiamata:
Verdetto risoltoSotto shadow mode
deny→ audit, motivazione [shadow] would deny — …
sanitize→ audit, motivazione [shadow] would sanitize — …
pending_approval→ audit, motivazione [shadow] would pending_approval — …
allow / auditinvariato (già non bloccante)
La chiamata passa sempre. Nulla viene bloccato, nessun argomento viene redatto, nessun hold umano viene aperto — ma l’evento è registrato con il verdetto che la policy avrebbe prodotto, così il feed degli eventi si legge come un’esecuzione di produzione con l’applicazione disattivata.
Il prefisso [shadow] would … è il tuo filtro principale. Ordina il feed degli eventi per esso e hai un elenco completo di ogni chiamata che questa policy sta per iniziare a bloccare, prima che ne blocchi una.

​
2. Un rollout concreto

Diciamo che hai una policy prod-agents con una regola deny sui comandi shell distruttivi, e vuoi confermare che non scatti su nulla di legittimo.
1

Attiva la shadow mode

In Security → Firewall → Policies, apri prod-agents, attiva Shadow mode e salva. La policy mantiene il suo collegamento e le sue regole — semplicemente smette di applicare.
2

Lascia scorrere il traffico reale

I tuoi agent continuano a chiamare il gateway esattamente come prima. Ogni chiamata a tool viene valutata; nulla viene bloccato. Concedi una finestra rappresentativa — abbastanza lunga da coprire il tuo mix reale di tool.
3

Leggi i would-be denial

Apri Events e filtra per la motivazione [shadow]. Ogni riga mostra il tool, la superficie, l’esecuzione e la regola corrispondente — così un [shadow] would deny — destructive shell command su una chiamata shell.exec è esattamente ciò che vedresti in produzione, meno l’HTTP 400.
4

Disattiva la shadow mode

Una volta che il feed mostra la policy scattare su ciò che ti aspetti e nulla che non vuoi, disattiva la Shadow mode. Dalla chiamata successiva in poi, quegli eventi [shadow] would deny diventano deny reali firewall_blocked.
Se la shadow mode ha fatto emergere un falso positivo — una chiamata legittima che ha corrisposto a una regola deny — sistema la regola (restringi il glob o aggiungi una clausola sugli argomenti) ancora in shadow, e osserva di nuovo il feed. Iteri contro il traffico reale con raggio d’impatto zero.

​
3. Cosa la shadow mode non ammorbidisce

La shadow mode è un’anteprima della policy, non un interruttore di spegnimento generale.
Le skill governate applicano comunque sotto una policy in shadow. Una skill in modalità block nega comunque, e una skill in modalità quarantine mette comunque in attesa di approvazione, anche quando la policy corrispondente è in shadow. La modalità di applicazione di una skill è una proprietà dello stato di revisione della skill, non della policy che stai visualizzando in anteprima — mettere in shadow una policy non è mai stata una richiesta di togliere dalla quarantine una skill. La policy rimane marcata come in shadow negli eventi, ma la disposizione della skill vince.
Qualche altro confine che vale la pena conoscere:
Solo i verdetti applicativi (deny, sanitize, pending_approval) vengono declassati. Un allow o audit lascia già passare la chiamata, quindi non c’è nulla da ammorbidire — quegli eventi portano comunque il badge shadow così puoi capire che la policy era in shadow quando sono stati registrati.
Una regola cap_cost si risolve in un concreto allow o deny in base alla spesa accumulata dell’esecuzione, e quel verdetto risolto è ciò che la shadow mode poi declassa — un would-be deny da superamento del tetto compare come [shadow] would deny come ogni altro.
La shadow mode vive su ogni policy in modo indipendente. Puoi mettere in shadow una policy nuova di zecca mentre una collaudata continua ad applicare — non c’è un interruttore shadow a livello di workspace che ti dimentichi di disattivare.

​
4. Shadow mode vs. gli altri controlli di rollout

Il firewall ti dà tre diversi controlli “non rompere ancora nulla”. Risolvono problemi diversi:
ControlloScopeDomanda a cui risponde
Shadow modeUna policy”Cosa bloccherebbe questa policy se la applicassi?”
Verdetto di default auditUna policy”Logga tutto ciò che nessuna regola nomina, blocca nulla.”
Observe modeWorkspace”Quali tool girano senza policy che li copra?”
La shadow mode è quella a cui ricorrere quando hai una policy reale e applicativa e vuoi misurarne l’impatto esatto prima che modifichi il traffico. Un verdetto di default audit è per la coda non corrisposta di una policy; l’observe mode riguarda i gap di copertura nel workspace, non l’applicazione di una policy specifica.
Puoi impilarli. Una nuova policy default-deny sotto shadow mode è il rollout più delicato possibile: anche il pavimento default-deny si limita a loggare [shadow] would deny invece di bloccare, così vedi l’intero insieme di chiamate che le tue regole di allow non coprono ancora prima che il deny sia live.

​
5. I compliance pack atterrano prima in shadow

Quando installi un compliance pack in modalità observe (non applicativa), le policy del firewall che materializza vengono create con la shadow mode attiva — valutano e loggano contro il tuo traffico senza bloccare nulla. Promuovere il pack ad applicare toglie quelle policy dallo shadow. Stesso meccanismo, applicato per te: esegui un dry-run dei controlli, leggi i would-be verdict, poi applica.

​
6. Attivarla

Nella console, la shadow mode è un toggle nell’editor delle policy. Lo stesso flag è esposto sull’API di gestione come shadow_mode sull’oggetto policy — queste rotte usano il tuo token di sessione / di accesso e richiedono Developer+:
Metodo & pathRuoloNota
PUT /api/workspace/firewall/policiesDeveloper+Imposta shadow_mode: true / false sulla policy nel corpo.
GET /api/workspace/firewall/policies/:idMemberLegge lo stato shadow_mode corrente di una policy.
Ogni modifica scrive una riga di audit e incrementa l’intero version della policy, così attivare e disattivare lo shadow è esso stesso tracciato.

​
Dove andare dopo

Crea e collega una policy

La configurazione in due passi di cui la shadow mode fa il rollout — crea la policy, collega una chiave.

Log degli eventi

Dove compare [shadow] would … — filtra, approfondisci esecuzioni e regole.

Verdetti

I verdetti applicativi che la shadow mode declassa, e cosa fa ognuno live.

Modalità di applicazione

Come shadow, audit e observe si inseriscono nel modello di applicazione più ampio.
Per le minacce che una policy ferma una volta disattivato lo shadow, vedi chiamate a tool pericolose e agenzia eccessiva.