Vai al contenuto principale
Hai scritto una regola del firewall — un deny su shell.exec, una allow-list di egress, una clausola sugli argomenti che scatta solo su rm -rf — e ora vuoi sapere che faccia esattamente ciò che pensi prima che modifichi una singola chiamata a tool di produzione. Il firewall ti dà tre modi non distruttivi per testare le regole del firewall, ognuno che risponde a una domanda diversa:

Dry-run di una chiamata

La sandbox Test alimenta una singola chiamata a tool sintetica attraverso il motore reale e restituisce il verdetto — nulla dispatchato, nulla loggato. Developer+.

Riproduci una postura

Simulate riproduce un livello di autonomia contro il tuo traffico recente e conta quante chiamate bloccherebbe. Leggibile dai Member.

Esegui contro il traffico live

La shadow mode valuta un’intera policy su chiamate reali ma declassa ogni verdetto applicativo a audit. Raggio d’impatto zero.
Tutti e tre si configurano attraverso la console (o le rotte di gestione /api/workspace/firewall/*, che si autenticano con la tua sessione / token di accesso — non una chiave di relay sk-orca-…). Le chiamate di relay /v1/* del tuo agent non cambiano mai mentre testi.

​
1. Testa le regole del firewall con la sandbox Test di dry-run

La sandbox Test è il loop più stretto: passale una singola chiamata a tool sintetica e fa girare il motore di valutazione reale — risoluzione completa della policy, regole percorse in ordine di priorità, vince-il-primo-match — poi restituisce il verdetto, la regola che l’ha prodotto e la motivazione leggibile. La chiamata è un dry run: nulla viene dispatchato ad alcun tool, e nulla viene scritto nel feed degli eventi o nell’inventario Discovered-tools. Risponde a una domanda con precisione: dato questo esatto nome di tool e questi argomenti, cosa decide la mia policy — e quale regola lo decide?
La sandbox Test è Developer+. Può fare anteprima contro una policy in bozza non salvata per id e la risposta fa emergere il nome della policy corrispondente e l’etichetta della regola, quindi sta più vicina a un’anteprima di superficie di scrittura che a una semplice lettura — a differenza di Simulate e delle altre viste di lettura, che sono aperte a ogni membro.

​
Un dry run concreto

Diciamo che hai aggiunto una regola che dovrebbe negare shell.exec solo quando il comando contiene rm -rf. Vuoi confermare due cose in una sola sessione: il comando pericoloso è negato, e uno innocente passa comunque.
1

Testa la chiamata pericolosa

In Security → Firewall, apri la scheda Test, scegli la superficie response, inserisci il nome del tool shell.exec e gli argomenti {"command": "rm -rf /data"}, ed esegui. La risposta nomina il verdetto e la regola corrispondente:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Testa la chiamata innocente

Eseguila di nuovo con {"command": "ls -la"}. La clausola sugli argomenti non corrisponde più, quindi la regola ricade sul default della policy — dovresti vedere allow o audit e un rule_label vuoto. Se rm -rf nega e ls -la no, la tua clausola sugli argomenti ha lo scope corretto.
3

Fai anteprima di una bozza prima di collegarla

Passa un policy_id per valutare contro una specifica policy in bozza anziché quella su cui il tuo traffico si risolve attualmente — così puoi dimostrare che una nuova policy è giusta prima di collegarle una chiave o promuoverla a default del workspace.
Leggi gap nella risposta. gap: true significa che una policy si è risolta ma nessuna regola al suo interno ha corrisposto alla chiamata (e il workspace è in observe mode) — il tool è sgusciato attraverso ogni regola ed è ricaduto sul default. Quello è un buco di copertura da chiudere prima di rilasciare, non un verdetto di cui fidarsi.
La sandbox Test usa le stesse superfici della valutazione live — inbound, response, mcp, egress (default inbound) — quindi testa ogni regola sulla superficie a cui è fissata. Su inbound non ci sono argomenti al momento della chiamata, quindi una regola sanitize escala a un block lì esattamente come farebbe in produzione; vedi stage per perché la superficie conta.

​
2. Simula un livello di autonomia prima di applicarlo

La sandbox Test controlla una chiamata. Simulate risponde alla domanda a livello di postura: se passassi tutto questo workspace a un livello di autonomia più severo, quanto del mio traffico recente bloccherebbe? Simulate riproduce le regole di deny di un livello candidato contro i tuoi eventi del firewall recenti e restituisce l’impatto che ci sarebbe — solo nomi di tool e conteggi, mai argomenti. È in sola lettura e leggibile dai Member, così chiunque nel team può fare anteprima del raggio d’impatto di tight prima che un Developer si impegni su di esso.
  • tight — default-deny, deny della shell distruttiva, deny dei tool a forma di fetch (il vettore SSRF), PII Shield + Secrets Blocker applicati. Simulate mostra quanto del tuo traffico reale questo pavimento catturerebbe.
  • balanced — audit di default, deny della shell distruttiva, PII Shield solo in audit (segnala le PII). La postura di partenza consigliata.
  • permissive — solo observe; nulla applicato.
Simulate non cambia nulla — è un what-if sugli eventi passati. Applicare un livello di autonomia (una scrittura Developer+) materializza righe di policy e di guardrail autonomy_* reali e modificabili, con undo a un clic dallo snapshot di audit. Fai anteprima con Simulate, poi applica quando il conteggio sembra giusto.

​
3. Shadow mode: testa contro il traffico live senza raggio d’impatto

La sandbox Test e Simulate sono anteprime offline. La shadow mode è quella live: un flag per-policy che valuta la policy sul traffico reale degli agent, percorre ogni regola, sceglie un verdetto — poi declassa ogni verdetto applicativo (deny, sanitize, pending_approval) a audit e prefissa la motivazione [shadow] would …. La chiamata passa sempre; nulla viene bloccato, redatto o messo in attesa. Questo fa sì che il feed degli eventi si legga come un’esecuzione di produzione con l’applicazione disattivata. Filtra per [shadow] e hai un elenco completo di ogni chiamata che la policy sta per iniziare a bloccare — prima che ne blocchi una.
Metodo di testGira controDomanda a cui risponde
Sandbox TestUna chiamata sintetica”Quale verdetto ottiene questa esatta chiamata, e quale regola decide?”
SimulateEventi recenti”Quante chiamate bloccherebbe un livello di autonomia più severo?”
Shadow modeTraffico live”Cosa bloccherebbe questa policy sull’intero traffico di produzione reale?”
La shadow mode è la più approfondita delle tre — copertura live completa con raggio d’impatto zero. Ha la sua pagina: Fai il rollout di una policy del firewall con la shadow mode percorre il toggle, le motivazioni [shadow] would … e il passaggio ad applicare.

​
4. Un ordine di test pratico

I tre tool si compongono in un unico percorso di rollout sicuro — il controllo più economico per primo, la copertura più ampia per ultima:
1

Dry-run delle regole appena scritte

Usa Test per confermare che ogni nuova regola scatti sulle chiamate che dovrebbe e lasci passare quelle che non dovrebbe — inclusi i casi negativi. Veloce, Developer+, nulla persistito.
2

Valuta la postura (opzionale)

Se stai ricorrendo a un livello di autonomia anziché a regole scritte a mano, Simulate il livello e leggi il conteggio di would-be-blocked contro il traffico reale prima di applicarlo.
3

Shadow contro il traffico live

Attiva la shadow mode e lascia scorrere una finestra rappresentativa di chiamate reali. Leggi gli eventi [shadow] would …; restringi qualsiasi regola che faccia emergere un falso positivo — ancora in shadow, raggio d’impatto zero.
4

Applica

Quando il feed scatta su ciò che ti aspetti e su nulla che non vuoi, disattiva lo shadow. La chiamata successiva applica per davvero.
Il test fa anteprima della policy, non delle skill governate. Una skill in modalità block o quarantine applica comunque anche sotto una policy in shadow — la disposizione di revisione della skill vince. Mettere in shadow una policy non è mai stata una richiesta di togliere dalla quarantine una skill.

​
5. Riferimento API

Queste rotte di gestione usano il tuo token di sessione / di accesso e hanno scope a livello di workspace:
Metodo & pathRuoloScopo
POST /api/workspace/firewall/testDeveloper+Dry-run di una chiamata a tool sintetica contro la policy risolta (o una policy_id in bozza). Restituisce verdetto, policy_name, rule_label, reason, gap, shadow_mode. Nulla dispatchato o loggato.
GET /api/workspace/firewall/simulate?level=MemberRiproduce un livello di autonomia contro gli eventi recenti; restituisce i conteggi di would-be-blocked.
GET /api/workspace/firewall/policies/:idMemberLegge il flag shadow_mode corrente di una policy.
PUT /api/workspace/firewall/policiesDeveloper+Attiva shadow_mode sulla policy.
Il corpo di Test prende surface (default inbound), un tool_name obbligatorio, un args_json opzionale e un policy_id opzionale per sovrascrivere la risoluzione.

​
Dove andare dopo

Shadow mode

Il rollout sul traffico live: [shadow] would …, il filtro degli eventi e il passaggio ad applicare.

Valida gli argomenti

Dai scope a una regola in base a quali argomenti — le clausole che la sandbox Test ti lascia verificare contro rm -rf vs ls -la.

Verdetti

Cosa fa ognuno di allow / audit / deny / sanitize / pending_approval / cap_cost quando un test smette di essere un test.

Log degli eventi

Dove atterrano i verdetti in shadow — filtra, approfondisci esecuzioni e regole corrisposte.
Per la grammatica di matching delle regole che questi test esercitano, vedi il riferimento completo delle regole del firewall; per dove il test si inserisce nel modello più ampio, vedi modalità di applicazione.