Il gate HITL garantisce che nessuna azione ad alto rischio di un agente proceda senza giudizio umano. Questo cookbook percorre l’intero ciclo di vita dell’approvazione — dal momento in cui un’azione governata genera una richiesta, attraverso la risoluzione del livello di rischio, le decisioni umane e la valvola di sfogo break-glass — cosi puoi tracciare ogni parte in movimento prima di incontrarla in produzione.
Se non hai ancora letto il modello di autorizzazione, inizia con Governance. La guida Governare e approvare copre la stessa meccanica dal punto di vista dell’operatore; questa pagina e il riferimento passo per passo.
Il ciclo di vita della richiesta
Una richiesta di approvazione si apre deny-closed e con scadenza temporale. Inizia come pending, porta una scadenza e non autorizza nulla finche un numero sufficiente di umani non ha deciso. La richiesta non può abbassare la propria soglia — una policy di approvazione corrispondente è autorevole per la soglia e i timeout.
La richiesta è vincolata a un hash del piano dell’esatto payload della tool-call. Questa è la difesa anti-TOCTOU: se l’azione sottostante cambia tra richiesta e decisione, l’hash non corrispondera e l’approvazione non potra vincolarsi. Un’approvazione obsoleta non autorizza mai un’azione diversa.
Risoluzione del livello di rischio
Quattro livelli determinano quanto controllo umano richiede un’azione governata:
| Livello | Significato |
|—-|—-|
| low / medium | Assegnato solo da policy di approvazione esplicita — nulla ha questo valore per default |
| high | Il default per qualsiasi cosa raggiunga la coda di approvazione. Richiede un’approvazione umana |
| critical | Minimo obbligatorio di due persone (doppia autorizzazione NIST SP 800-53 AC-3(2)) |
Il livello viene riderivato dall’insieme di policy attive a ogni decisione, mai letto da uno snapshot memorizzato. Un cambio di policy ha effetto immediato. Una riga obsoleta non può mai tenere la soglia più bassa della classificazione attuale — e deny-closed per costruzione.
L’insieme critical integrato copre le azioni genuinamente irreversibili: deploy e ritiro in produzione, cancellazione e rimozione dati, modifiche all’enforcement della sicurezza e al kill switch, custodia e rotazione delle chiavi, e offboarding NHI.
Una policy di approvazione con un risk_tier esplicito può alzare o abbassare il default per azione. Ma non può mai abbassare un’azione critical sotto il minimo di doppio controllo.
Passo per passo
1. Un’azione governata attiva una richiesta
Un’azione governata — deploy apply, agent fire, override del budget, o qualsiasi azione che corrisponde a una policy di approvazione — raggiunge il motore di approvazione. Il motore apre una nuova richiesta nello stato pending.
2. La richiesta si vincola a un hash del piano
La richiesta registra un hash dell’esatto payload della tool-call. Questo binding all’hash del piano e la difesa TOCTOU: la decisione autorizzera solo l’azione per cui la richiesta è stata creata.
3. Il livello di rischio viene risolto dalla policy corrente
Il motore valuta l’insieme di policy attive (RBAC, ABAC nativo e qualsiasi PDP esterno) per derivare il livello di rischio. Il livello non viene mai memorizzato da una valutazione precedente.
4. Un revisore umano decide
Un umano con ruolo sufficiente emette un approve o deny. Il server applica tre invarianti a questo punto, basati sull’identità utente stabile:
- Separazione dei compiti. Il richiedente non può decidere sulla propria richiesta. Questo si basa sull’identità utente stabile, non sulla stringa della credenziale che una singola persona potrebbe variare.
- Guardia contro decisori duplicati. Un indice unico protegge da una race condition di decisori duplicati — un umano conta una sola volta verso la soglia.
- La scadenza vincola. Una richiesta scaduta non può mai ricevere una decisione vincolante, anche prima che una scansione ne materializzi la scadenza. Lo stato effettivo viene riderivato a ogni decisione.
5. Azioni critiche: doppio controllo con AAL3
Per il livello critical: la soglia è fissata a due approvatori umani distinti. Il minimo viene applicato sia alla creazione (la soglia memorizzata non può mai partire sotto due) sia alla decisione (una richiesta creata prima che l’azione diventasse critica non può comunque passare con un solo umano).
Ogni umano che decide deve avere una sessione verificata via hardware recente — step-up WebAuthn o PIV (AAL3). Un token di sistema non porta garanzia umana e viene rifiutato.
6. La decisione viene registrata nel registro
Ogni decisione aggiunge una riga immutabile al trail delle decisioni della richiesta e un evento nel registro che registra la decisione, lo stato risultante e il livello di rischio sotto cui è stata presa. Il registro e append-only, hash-chained e firmato con Ed25519 — riscrivere la storia e crittograficamente rilevabile.
Scadenza
La scadenza viene derivata alla lettura, non scritta una sola volta. Una richiesta scaduta non può mai ricevere una decisione vincolante anche se nessuna scansione di background ha ancora materializzato la scadenza. Lo stato effettivo viene sempre riderivato, quindi una scansione lenta e un ritardo estetico, non una falla di sicurezza.
Configurazione delle policy
Le policy di approvazione ti permettono di sovrascrivere il livello di rischio predefinito per classe di azione. Una policy con un risk_tier esplicito può spostare un’azione da high a low, o elevare un medium a critical. L’unico vincolo: non puoi mai abbassare critical sotto il minimo di doppio controllo. Il requisito di due persone per le azioni irreversibili e strutturale, non configurabile.
Break-glass
Quando il quorum è irraggiungibile — l’incidente delle 03:00 dove il secondo approvatore dorme — il break-glass fornisce una valvola di sfogo registrata. E rumoroso per costruzione.
L’attivazione richiede tutto quanto segue:
- L’attivatore e un admin, sempre un vero umano — un token di sistema viene rifiutato.
- Uno step-up AAL3 recente (WebAuthn o PIV).
- Una giustificazione scritta registrata nella stessa transazione.
- Una sessione attivamente registrata come precondizione.
Scadenza temporale: la concessione ha un default di un’ora, con un massimo rigido di 24. Un’emergenza che necessita di più tempo e una modalità operativa, non un’emergenza, e deve passare attraverso il normale doppio controllo.
Ogni utilizzo viene registrato. Ogni azione intrapresa sotto break-glass aggiunge una riga immutabile e un evento nel registro che nomina la concessione, l’azione e il soggetto. Un’azione proceduta sotto break-glass è permanentemente distinguibile da una correttamente approvata.
Revisione post-evento obbligatoria. Una nuova concessione non può essere attivata mentre una precedente non è stata revisionata. La revisione deve provenire da un umano diverso dall’attivatore. Non puoi accumulare emergenze per evitare lo scrutinio.
Il break-glass attenua un quorum mancante; non sovrascrive mai un rifiuto esplicito. Una richiesta che qualcuno ha deliberatamente negato resta negata.
Cosa viene registrato
Ogni decisione — approvazione, negazione, scadenza o utilizzo del break-glass — viene aggiunta in due posti:
- Il trail delle decisioni della richiesta: una sequenza immutabile di righe di decisione sulla richiesta stessa, ciascuna con il decisore, il verdetto e il timestamp.
- Il registro di audit: un evento hash-chained, firmato con Ed25519, che registra la decisione, lo stato risultante della richiesta e il livello di rischio sotto cui è stata presa.
Entrambe le scritture avvengono nella stessa transazione del cambio di stato. Non puoi prendere una decisione governata che il registro dimentichi silenziosamente.
Correlati
- Governare e approvare — la guida operatore che copre la stessa meccanica.
- Governance — il modello di autorizzazione, la postura di auto-audit e la meccanica del kill switch.
- Cookbook: esercitazione kill switch — l’esercitazione del gate di negazione a livello di estate.
- Kill switch — la pagina prodotto per l’arresto di emergenza.