O problema
Cada anúncio de um agente autônomo vem com a mesma frase: foi testado com times vermelhos, houve auditoria externa, há um programa de recompensas por bugs. Essa frase é quase sempre verdadeira e, mesmo assim, informa muito pouco. A pergunta útil não é se foi testado, mas que tipo de falha cada teste cobre e qual fica de fora.
Claude Duet, o agente proativo da Anthropic, começou como visualização de pesquisa em 21 de outubro de 2026, limitado a assinantes Pro e Max nos Estados Unidos com lista de espera. Seu documento de segurança descreve o programa de testes com um nível de detalhe incomum, o que o torna um bom caso para praticar essa leitura.
A evidência: o que foi testado e com qual método
O documento enumera três variantes de comportamento durante o desenvolvimento: uma versão normal, uma com instruções hostis injetadas no conteúdo que lê, e uma projetada para forçar um excesso de escopo. Some-se a isso tráfego sombra, times vermelhos internos, um teste de penetração externo com acesso ao código-fonte e um programa de recompensas.
| Teste | O que cobre | O que não cobre |
|---|---|---|
| Três variantes de comportamento | Falhas do modelo diante de conteúdo hostil | Decisões humanas sob cansaço |
| Tráfego sombra | Comportamento com carga real antes do lançamento | Casos extremos que não aparecem no tráfego |
| Times vermelhos internos | Classes de ataque conhecidas pelo time | Ataques que o time não imaginou |
| Teste de penetração externo | Infraestrutura e manipulação de credenciais | Uso cotidiano do produto |
| Programa de recompensas | Falhas encontradas por terceiros com incentivo | Tudo o que ninguém reportou |
O resultado: três conclusões que se sustentam
Primeira: o design separa credenciais do ambiente de execução. O documento indica que senhas, cartões e números de conta não chegam ao modelo, e que os pagamentos usam cartões virtuais de uso único atados a comerciante e valor. Isso é verificável no design e reduz o dano máximo de um erro de forma estrutural, não por disciplina do usuário.
Segunda: as ações irreversíveis são interrompidas. Enviar mensagens sensíveis, pagar, assinar, deletar e criar contas exigem confirmação, e o cartão de confirmação mostra a ação, o objetivo, o conteúdo e todos os destinatários. Além disso, não existe a opção “não perguntar novamente” para pagamentos, transferências, exclusão de pedidos ou criação de contas.
Terceira: há ações bloqueadas mesmo com confirmação: negociar valores mobiliários, transferir entre contas e acessar contas de terceiros. A lista é curta e explícita, que é exatamente o que se espera de uma lista assim.
Os limites dessa evidência
Um relatório de segurança de um produto em prévia tem três limites que vale a pena anotar ao lado de cada conclusão.
O primeiro é de escopo: o sistema é testado contra ataques e contra erros do modelo, não contra o dono do negócio que aprova cinco cartões seguidos antes do café. A fadiga de aprovação é mencionada na documentação como motivo para calibrar a frequência, mas não há medição pública de quantas pessoas realmente leem cada cartão.
O segundo é de acesso: sem conta, não é possível reproduzir nada. O produto não está disponível fora dos Estados Unidos e é liberado por convite, então a latência, a qualidade do resumo matinal e a frequência real de aprovações ficam fora do alcance de qualquer leitor externo.
O terceiro é temporal: o documento descreve o estado em um momento específico. Um programa de testes que hoje é sólido pode ficar para trás quando novos conectores forem adicionados, e o próprio documento adverte que os testes de navegador e de login ainda estão em andamento.
O que fazer com isso
Se for preciso decidir com base em um relatório assim, três perguntas organizam a leitura mais rápido do que qualquer lista de funcionalidades: que falha concreta cada teste cobre, que parte do sistema fica fora do escopo declarado e o que mudou desde que o documento foi escrito?
Para quem constrói algo parecido, a lição transferível não é copiar a lista de testes, mas copiar sua granularidade: separar comportamento, infraestrutura e decisões humanas, porque cada um quebra por motivos diferentes e se conserta com instrumentos diferentes.
Discussão
Fica em aberto uma pergunta que nenhum documento responde: como medir se as confirmações são lidas? Tempo até aprovar, taxa de rejeição e rolagem dentro do cartão são três métricas baratas que qualquer equipe pode instrumentar desde o primeiro dia.
Se sua equipe já opera um agente com permissões de escrita, que métrica vocês usam para saber que as aprovações continuam sendo reais e não um mero trâmite?
Quando um produto agrega vários provedores de modelos, as chaves e o faturamento costumam se concentrar em um gateway em vez de se espalhar pelo código; Crazyrouter documenta seus endpoints e preços como uma dessas opções, e a decisão depende do volume de chamadas e das normas internas.
Fontes: anúncio do Claude Duet, documento de segurança e privacidade, página do produto e central de ajuda da Anthropic, consultados em 26 de outubro de 2026.