Skip to main content
Políticas personalizadas transformam um padrão de falha encontrado nos seus traces ou auditorias em uma decisão que é executada enquanto o agente trabalha. Uma política pode permitir uma ação, fornecer orientação ao agente ou bloquear a ação antes que ela cause um novo incidente. Use uma política personalizada quando o comportamento depende das suas ferramentas, caminhos, comandos, ambientes ou regras operacionais. Consulte primeiro o pacote de políticas do Failproof AI para não recriar um controle já existente.

Criar uma política personalizada

  1. Acesse Admin → editor de políticas, selecione Nova política e descreva a falha que você deseja prevenir.
  2. Adicione o código-fonte da política, depois teste as correspondências esperadas e os casos seguros que não devem corresponder no editor. Resolva todos os erros de validação.
  3. Salve o rascunho e selecione Publicar versão para criar uma versão imutável.
  4. Acesse Admin → enforcement, implante a versão em uma máquina de teste no modo observe e verifique suas decisões em Observe → policy antes de aplicá-la. O editor de políticas usado para criar e publicar uma política personalizada.

Comece com uma regra restrita

Esta política bloqueia comandos destrutivos do Kubernetes somente quando o comando tem como alvo o ambiente de produção. Tudo fora desse padrão de falha exato retorna allow().
Boas políticas são restritas o suficiente para serem explicadas em uma única frase. Corresponda à ação observável — não à intenção que você espera que o agente tenha — e retorne allow() assim que a regra não se aplicar.

Escolha uma decisão

Escreva o motivo para o agente que precisará se recuperar. Explique o que foi detectado e o que ele deve fazer em vez disso.
Não use instruct() para um limite de segurança. A entrega de orientações varia conforme o harness do agente. Use deny() quando a ação deve ser impedida.

Objeto de política

Filtre as ferramentas dentro de fn. O campo match.toolNames não faz parte do tipo público de política personalizada.

Contexto da política

Toda política recebe um PolicyContext. Trate todos os valores opcionais como genuinamente opcionais. Versões de agentes e tipos de eventos nem sempre fornecem os mesmos campos.

Entradas comuns de ferramentas

O Failproof AI normaliza ferramentas comuns entre os harnesses suportados para que uma política geralmente possa usar um único formato de entrada. Use coerção defensiva porque os valores de entrada das ferramentas são tipados como unknown:

Escolha o evento

A disponibilidade dos eventos e o comportamento de bloqueio dependem do harness do agente. Consulte Harnesses de agentes antes de depender de um evento em uma frota heterogênea.
SessionStart, SessionEnd, UserPromptSubmit, PreToolUse, PermissionRequest, PermissionDenied, PostToolUse, PostToolUseFailure, Notification, SubagentStart, SubagentStop, TaskCreated, TaskCompleted, Stop, StopFailure, TeammateIdle, InstructionsLoaded, ConfigChange, CwdChanged, FileChanged, WorktreeCreate, WorktreeRemove, PreCompact, PostCompact, Elicitation, ElicitationResult, UserPromptExpansion, PostToolBatch e Setup.

Padrões comuns de políticas

Bloquear escritas em caminhos protegidos

Fornecer orientação sem bloqueio

Controlar a conclusão da sessão

Um evento Stop negado pode fazer o agente tentar novamente. Aplique a condição somente se o agente conseguir satisfazê-la no ambiente atual, e defina limites de tempo para todo subprocesso ou chamada de rede.

Carregar arquivos de política

Arquivos de convenção

Arquivos de convenção são carregados automaticamente:
  • Os diretórios de políticas do projeto e do usuário são carregados.
  • Os arquivos são carregados em ordem alfabética dentro de cada diretório.
  • O arquivo deve terminar em policies.js, policies.mjs ou policies.ts.
  • Múltiplas chamadas customPolicies.add() em um mesmo arquivo são suportadas.
  • Importações relativas de módulos locais são suportadas.
  • As políticas do projeto podem ser versionadas para que as mesmas regras acompanhem o repositório.

Arquivos explícitos

Use caminhos explícitos quando a validação ou configuração precisar nomear diretamente o arquivo de entrada:
Os arquivos explícitos são carregados primeiro, seguidos pelos arquivos de convenção do projeto e depois pelos do usuário. Um arquivo descoberto por ambos os caminhos é carregado apenas uma vez.

Validar e testar

A validação executa o módulo pelo carregador de produção e confirma que ele registra pelo menos uma política.
A validação detecta arquivos ausentes, erros de sintaxe, importações não resolvidas, exceções no nível superior e timeouts de carregamento de módulo. Ela não comprova que a lógica de correspondência está correta. Teste pelo menos estes casos:
  • Uma ação que deve corresponder e produzir o motivo de política esperado.
  • Uma ação próxima, mas segura, que deve retornar allow().
  • Campos de ferramenta ausentes ou malformados.
  • Sintaxe alternativa de comandos, caminhos, aspas, capitalização e espaços em branco.
  • Um subprocesso ou dependência de rede indisponível.
Atribua o resultado à sua política personalizada em Observe → policy. Um teste bloqueado não é suficiente se uma política integrada diferente tomou a decisão.

Comportamento em tempo de execução

  • As políticas integradas são avaliadas antes das políticas personalizadas.
  • O primeiro deny interrompe a avaliação das demais políticas.
  • Múltiplos resultados instruct podem ser combinados quando nenhuma políticanega o evento.
  • Uma função de política tem um prazo de execução de 10 segundos.
  • Uma exceção lançada ou timeout é registrado e tratado como allow().
  • Um arquivo de convenção que falha ao carregar é ignorado; os outros arquivos personalizados e as políticas integradas continuam funcionando.
  • O carregamento de módulo no nível superior também tem um prazo de 10 segundos.
  • O modo observe em nuvem executa a política, mas registra uma decisão diferente de allow sem aplicá-la.
Mantenha os módulos de política determinísticos e rápidos. Evite chamadas de rede ou inicialização de servidores no nível superior. Delimite o trabalho dentro de fn, trate falhas de dependência e decida conscientemente se essa falha deve permitir ou bloquear a operação.

Exportações da API

O TypeScript exporta PolicyContext, PolicyResult, CustomHook, PolicyDecision e PolicyFunction.

Implantar políticas personalizadas

Publique uma versão, implante-a no modo observe, verifique as decisões e passe para a aplicação.