> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Políticas
> Observe, oriente ou bloqueie ações do agente antes que uma falha conhecida se repita.
Uma política avalia um evento de hook do agente e retorna uma de três decisões:
* `allow` permite que a ação continue.
* `instruct` fornece orientação corretiva ao agente.
* `deny` bloqueia a ação com uma justificativa.
## Use as três superfícies de política
1. Acesse **Observe → policy** para filtrar e inspecionar decisões de política das sessões.
2. Acesse **Admin → policy editor** para criar, validar, publicar, desabilitar ou inspecionar versões imutáveis.
3. Acesse **Admin → enforcement** para atribuir versões e efeitos às máquinas.
Use a página de Políticas para entender o que já está sendo correspondido antes de criar ou alterar o enforcement.
O editor é onde você transforma uma condição de falha em código-fonte, valida e publica uma versão imutável.
O Enforcement então atribui essa versão publicada e seu efeito de observação ou aplicação às máquinas.
Verifique as decisões novamente na página de Políticas após o deploy para que as visões de criação e de frota estejam vinculadas à atividade real do agente.
Use `failproofai` para instalação e validação de políticas locais:
```bash theme={null}
failproofai policies
failproofai policy add block-rm-rf --scope project
failproofai config --status
```
Use `fp` para encontrar sessões e eventos na nuvem que contenham decisões de política. A criação de políticas e o deploy de frota na nuvem continuam sendo fluxos de trabalho do dashboard.
As políticas possuem três superfícies distintas no Failproof AI:
1. **Analise decisões** em sessões, dashboards e auditorias.
2. **Crie versões** com regras embutidas, código ou o editor de políticas.
3. **Implante e aplique** versões em máquinas selecionadas.
Comece a partir de um modo de falha confirmado. Defina o menor evento e correspondência de ferramenta que o identifique, teste exemplos legítimos e não seguros e, então, observe antes de aplicar.
Ative uma regra revisada para riscos comuns de segredos, shell, Git, nuvem e fluxo de trabalho.
Expresse uma decisão específica de fluxo de trabalho em JavaScript ou TypeScript.