Skip to main content
Failproof AI è progettato in modo che un errore di enforcement sia visibile anziché permettere silenziosamente lavori rischiosi.

​
Diagnosticare un blocco failure-closed

  1. Vai a Admin → enforcement e apri la macchina.
  2. Controlla il suo ultimo check-in, deployment assegnato e deployment segnalato.
  3. Vai a Observe → policy e apri la sessione della decisione negata.
  4. Conferma se il motivo riporta raggiungibilità del daemon, version skew o la policy stessa.
Su una macchina configurata per usare failproofaid, il daemon è l’unico valutatore. Se non è raggiungibile o la sua versione di protocollo non corrisponde a quella della CLI, la valutazione dell’hook fallisce in modalità closed. L’azione viene negata con un motivo che guida l’operatore a verificare o aggiornare il daemon. Prima della configurazione del daemon, gli hook valutano le policy in process. Una volta registrata la configurazione del daemon, Failproof AI non ritorna silenziosamente a un secondo valutatore quando il daemon fallisce.

​
Rispondere a una decisione failure-closed

  1. Esegui failproofai config --status.
  2. Se le versioni differiscono, riesegui failproofai config dopo aver aggiornato il package.
  3. Se il daemon non è raggiungibile, ispeziona lo stato del suo servizio e i log locali.
  4. Riprendi il lavoro dell’agent solo dopo aver verificato che un percorso di valutazione della policy noto sia salubre.
Non ritentare ripetutamente l’azione bloccata. Una risposta failure-closed significa che il sistema non ha potuto stabilire che l’azione fosse sicura.

​
Un pack non si carica

Una macchina a cui è stato detto di enforcement di un pack, e che non può eseguirlo, nega anziché continuare silenziosamente. Il trigger è un’aspettativa registrata, mai vuota: una macchina senza pack installati è silenziosa, mentre un pack dichiarato che non si risolve — o che registra meno di quanto dichiara il suo manifest — nega. Il deny è ristretto, diversamente da un daemon non raggiungibile. Un daemon che non può essere raggiunto significa che nessuna valutazione è accaduta, quindi nulla può essere conosciuto come sicuro. Un pack che non si carica ha un insieme enumerabile di guard mancanti, perché ogni policy dichiarata porta il suo proprio match — quindi nega solo gli eventi e gli strumenti che quelle policy coprivano, e tutto il resto procede. Non si attiva per:
  • un pack di tipo observe, che valuta e scarta per costruzione
  • policy che non hai mai preso, o esplicitamente disattivato
  • un pack che il loader non ha mai ricevuto, dove “nessuna registrazione” non può essere distinto da un skip deliberato
  • una pausa di sessione attiva
  • un timeout di caricamento, che è transitorio — un momento di disco lento non deve negare finché non interviene un umano
UserPromptSubmit istruisce anziché negare, indipendentemente da ciò che la policy mancante ha dichiarato. Un deny universale lo includerebbe e ti bloccherebbe fuori dall’agent che potrebbe risolvere il problema.

​
Cosa fare

Nomina qualsiasi pack installato che non si caricherà, dice il motivo ed esce con codice non-zero. Quindi reinstallalo (failproofai pack add <source>) o rimuovilo (failproofai pack remove <publisher/name>) — rimuoverlo ritira l’aspettativa, e il deny si interrompe con essa.