Modalità di applicazione: observe, shadow e enforce

Prima che una regola blocchi il traffico in produzione, vuoi sapere che scatta sulle cose giuste e su nient’altro. OrcaRouter ti offre tre posture — observe, shadow ed enforce — che ti permettono di fare il rollout in modo incrementale, con visibilità a ogni passo e senza sorprese. Questa pagina spiega cosa significa meccanicamente ogni postura, come passare da una all’altra, e come i livelli di autonomia le impostano tutte in un unico passo.

​

1. Le tre posture a colpo d’occhio

​

2. Postura Observe — misura prima di regolare

La postura observe non è un singolo switch. È una combinazione di tre meccanismi indipendenti che insieme producono “consenti tutto, registra tutto”:

​

Observe mode del firewall (impostazione del workspace)

Quando una chiamata a tool si risolve in nessuna policy — nessun collegamento della chiave e nessun default del workspace — l’observe mode a livello di workspace del firewall determina cosa succede:

• Observe mode attivo: la chiamata è consentita e loggata come gap di copertura. La vista Discovered Tools si riempie di questi eventi di gap, mostrando esattamente quali tool i tuoi agent stanno eseguendo senza che nessuna regola li copra.
• Observe mode disattivo: la chiamata è consentita silenziosamente — byte-identica a un workspace che non ha mai abilitato la feature.

L’observe mode è la superficie di detection dei gap. Scatta solo quando nessuna policy si risolve. Non è la stessa cosa di avere una policy impostata su audit.

​

Verdetto audit del firewall (default per policy)

Quando una policy si risolve ma nessuna regola corrisponde a una chiamata a tool, si applica il default_verdict della policy. Il valore di default per default_verdict è audit — consenti la chiamata e registrala per revisione. Una nuova policy senza regole e senza modifiche alla configurazione non blocca nulla e non consente silenziosamente nulla: audita tutto ciò che vede. audit è anche un normale verdetto di regola. Una regola che corrisponde e produce audit lascia passare la chiamata e la registra — l’analogo della modalità audit del guardrail per il firewall.

​

Azione flag del guardrail (azione per regola)

Sul lato dei guardrail, l’azione flag è l’equivalente di observe: la regola scatta, un match viene registrato nel feed Matches, e la richiesta continua invariata. Nessun block. Nessuna redazione. Usa flag quando vuoi misurare una regola — vedere quanto spesso scatta e su cosa — prima di impegnarti su block o mask.

---

Insieme, questi tre producono la postura observe: l’observe mode cattura le chiamate a tool non coperte; i verdetti audit coprono le chiamate a tool sotto una policy ma non ancora sotto una regola specifica; le azioni flag coprono i controlli del guardrail che non sei ancora pronto ad applicare.

​

3. Postura Shadow — valida prima di applicare

La shadow mode è un flag per policy (shadow_mode: true) su una policy del firewall. Quando è attiva:

• La policy valuta ogni chiamata a tool esattamente come farebbe in produzione — le regole vengono matchate, i verdetti vengono calcolati, i predicati sugli argomenti vengono testati.
• Ogni verdetto applicativo (deny, sanitize, pending_approval) viene declassato a audit prima di raggiungere il tool.
• La motivazione loggata è prefissata con [shadow] would … così puoi vedere nel feed degli eventi esattamente cosa sarebbe stato bloccato, sanitizzato o trattenuto.

La shadow mode è il tuo switch per un rollout sicuro. Scrivi una policy, attiva la shadow, punta il traffico reale su di essa, guarda le viste degli eventi e delle esecuzioni per alcune ore o giorni, conferma che la policy scatta sui tool giusti e su nulla di inatteso, poi disattiva la shadow per iniziare ad applicare.

​

4. Postura Enforce — verdetti reali, conseguenze reali

Nella postura enforce, nulla viene declassato:

• Firewall deny → l’agent vede un errore di tool (MCP) o HTTP 400 firewall_blocked (superficie inbound). L’errore nomina il tool e la motivazione. Marcato skip-retry.
• Firewall sanitize → le sottostringhe corrispondenti vengono redatte dagli argomenti del tool e la chiamata ripulita viene inoltrata.
• Firewall pending_approval → la chiamata è trattenuta; l’agent riceve HTTP 400 firewall_approval_pending e un id di approvazione su cui fare polling.
• Guardrail block → HTTP 400 guardrail_blocked, che nomina il guardrail e la regola che ha scattato. Non costa quota.
• Guardrail mask → il match viene redatto (es. jane@acme.com → [EMAIL]) e la richiesta continua con il testo sanitizzato.

Per raggiungere la postura enforce: disattiva shadow_mode sulla policy del firewall, e cambia le azioni delle regole del guardrail da flag a block o mask come appropriato.

​

5. Rollout consigliato

​

6. Livelli di autonomia — imposta tutto in una volta

Ottimizzare le policy regola per regola è il percorso preciso. I livelli di autonomia sono quello rapido — un singolo controllo che imposta atomicamente la postura del Firewall e dei Guardrails del tuo workspace in una transazione, con undo a un clic: Applica tramite POST /api/workspace/firewall/autonomy (Developer+). L’endpoint Simulate (GET /api/workspace/firewall/simulate?level=) mostra in anteprima cosa farebbe una modifica di livello prima che tu la applichi.

​

7. Mappa dei meccanismi — quale impostazione fa cosa

Questa tabella è il riferimento autorevole. I quattro termini sono distinti — non confonderli:

---

Le modalità di applicazione non sono un on/off binario. Passa attraverso observe → shadow → enforce e le tue regole sono verificate sul traffico reale prima che lo blocchino mai.