O que os termos significam
Toda verificação que fica no caminho de uma requisição pode falhar ao produzir uma resposta: uma dependência expira, um sinal está ausente, uma chave não pode ser obtida. Fail open significa que a requisição prossegue como se a verificação não existisse. Fail closed significa que a requisição segue o caminho mais restritivo: ela é negada, contestada ou encaminhada para um controle mais forte já existente.
Nenhum deles é correto em geral. A escolha certa depende do que a rota faz e do custo de uma decisão errada.
Por que isso importa para verificações de actor
As verificações de actor adicionam contexto às requisições: se a interação parece humana, assistida por IA, conduzida por um agente ou desconhecida. Quando esse contexto não está disponível, a aplicação ainda precisa responder. Dois padrões de falha são comuns:
- Fail closed por engano. Um timeout ou um sinal ausente é tratado como suspeito, e usuários reais são bloqueados durante uma indisponibilidade.
- Fail open por engano em ações sensíveis. Um resultado ausente é silenciosamente tratado como humano, e uma ação de alto impacto segue com menos análise do que o pretendido.
Ambos surgem de deixar a escolha implícita. A correção é defini-la explicitamente, por rota. Nosso artigo sobre como projetar políticas no nível da aplicação para humanos e agentes de IA mostra como o comportamento de falha se encaixa em uma política por rota.
Como escolher
Uma abordagem prática é agrupar as rotas por níveis de risco:
- Baixo impacto (páginas públicas, documentação, rotas de catálogo somente leitura): fail open. Um resultado de actor ausente não deve mudar nada.
- Impacto médio (cadastros, envios de formulário, buscas com custo): normalmente fail open com registro, ou aplique uma adaptação leve como um rate limit padrão.
- Alto impacto (alterações de conta, exportações de dados, ações irreversíveis): fail closed para o seu controle mais forte já existente, como reautenticação ou confirmação. O ponto não é bloquear, mas recorrer à verificação que você usaria de qualquer forma.
Depois, defina o mesmo comportamento para casos relacionados:
- Timeout: a verificação não respondeu a tempo.
- Telemetria ausente: a integração não foi executada ou um sinal estava ausente.
- Unknown: a verificação foi executada, mas a evidência não sustentou uma determinação.
- Evidência desatualizada: o resultado é anterior e não deve ser reutilizado para uma ação mais sensível.
Equívocos comuns
- "Fail closed é mais seguro." Isso transfere o custo para usuários legítimos. Em rotas de baixo impacto, falhar fechado durante um incidente pode causar mais dano do que o risco que evita.
- "Unknown é uma falha." Unknown é um resultado válido. Ele merece seu próprio tratamento explícito, que pode ou não ser o mesmo do tratamento de timeout.
- "Um resultado ausente significa humano." Nunca infira uma classe de actor a partir da ausência de evidência.
Como Proof of Actor trata isso
O Proof of Actor nunca atribui Human a um timeout ou a um resultado Unknown, e a instalação não bloqueia nada: as equipes começam em modo de observação. O comportamento fail open ou fail closed para cada rota e nível de risco é escolha do proprietário da aplicação, aplicado no seu próprio código por meio de Route. Isso mantém a aplicação da política previsível e permite verificar os resultados antes que qualquer política entre em vigor.
Leia como as decisões de roteamento se encaixam, ou solicite acesso antecipado.