Skip to main content
O Failproof AI é projetado para que uma falha de imposição seja visível, em vez de permitir silenciosamente trabalhos arriscados.

​
Diagnosticar um bloqueio por falha fechada

  1. Vá para Admin → enforcement e abra a máquina.
  2. Verifique o último check-in, o deployment atribuído e o deployment reportado.
  3. Vá para Observe → policy e abra a sessão da decisão negada.
  4. Confirme se o motivo indica inacessibilidade do daemon, divergência de versão ou a própria política.
Em uma máquina configurada para usar failproofaid, o daemon é o único avaliador. Se ele estiver inacessível ou se sua versão de protocolo não corresponder à da CLI, a avaliação do hook falha de forma fechada. A ação é negada com um motivo que orienta o operador a verificar ou atualizar o daemon. Antes da configuração do daemon, os hooks avaliam as políticas no processo. Uma vez que a configuração do daemon é registrada, o Failproof AI não recorre silenciosamente a um segundo avaliador quando o daemon falha.

​
Responder a uma decisão de falha fechada

  1. Execute failproofai config --status.
  2. Se as versões divergirem, execute failproofai config novamente após atualizar o pacote.
  3. Se o daemon estiver inacessível, inspecione o estado do serviço e os logs locais.
  4. Retome o trabalho do agente somente após confirmar que o caminho de avaliação de políticas está saudável.
Não tente repetidamente a ação bloqueada. Uma resposta de falha fechada significa que o sistema não conseguiu estabelecer que a ação era segura.

​
Um pack não carrega

Uma máquina instruída a aplicar um pack que não consegue executá-lo nega em vez de continuar silenciosamente. O gatilho é uma expectativa registrada, nunca uma vazia: uma máquina sem packs instalados permanece silenciosa, enquanto um pack declarado que não consegue ser resolvido — ou que registra menos do que seu manifesto declara — nega. A negação é restrita, diferentemente de um daemon inacessível. Um daemon inacessível significa que nenhuma avaliação ocorreu, portanto nada pode ser considerado seguro. Um pack que não carrega possui um conjunto enumerável de guardas ausentes, pois cada política declarada carrega seu próprio match — portanto, ele nega apenas os eventos e ferramentas cobertos por essas políticas, e tudo o mais prossegue normalmente. Não é acionado para:
  • um pack observe, que avalia e descarta por construção
  • políticas que você nunca assumiu ou desativou explicitamente
  • um pack que o loader nunca recebeu, onde “sem registros” não pode ser distinguido de um skip deliberado
  • uma pausa de sessão ativa
  • um timeout de carregamento, que é transitório — um momento de disco lento não deve negar até que um humano intervenha
UserPromptSubmit instrui em vez de negar, independentemente do que a política ausente declarou. Uma negação geral o incluiria e bloquearia o acesso ao agente que poderia corrigir o problema.

​
O que fazer

Ele lista qualquer pack instalado que não carregará, indica o motivo e encerra com código não-zero. Em seguida, reinstale-o (failproofai pack add <source>) ou remova-o (failproofai pack remove <publisher/name>) — removê-lo retira a expectativa, e a negação cessa junto com ela.