Segurança de IA não é o mesmo que segurança de software

A confusão entre segurança e alinhamento

Martin Alderson argumenta que os laboratórios de fronteira, como Anthropic e OpenAI, podem estar misturando dois conceitos distintos: AI safety e security. Para ele, safety (alinhamento) trata de impedir que o modelo realize tarefas moralmente suspeitas, geralmente via classificadores que filtram pedidos e por técnicas de pré/pós-treinamento que ajustam os pesos para o próprio modelo recusar solicitações ruins. Esses mecanismos são não determinísticos: podem bloquear pedidos maliciosos, mas não o tempo todo - e, quanto mais eficazes, mais tendem a recusar perguntas legítimas, como acontece com modelos da Anthropic em depuração de código comum ou engenharia reversa.

Security, em contraste, herda o rigor clássico da engenharia de software: uma correção precisa ser completa. Ninguém consideraria SQL injection resolvida se a correção falhasse 0,01% das vezes - isso seria uma vulnerabilidade com etapas extras. O controle individual precisa funcionar sempre, ainda que nenhum sistema como um todo seja 100% seguro.

O exemplo de prompt injection

O autor cita um tweet de Boris Cherny, da Anthropic, afirmando que o risco de prompt injection estaria "em grande parte resolvido na prática". O próprio benchmark citado - o Gray Swan IPI - contradiz a frase: o Opus 5, melhor pontuação, falha ante um ataque em 2% das vezes com 15 tentativas, o que dá cerca de 500 tentativas em média para sucesso estatístico. Alderson compara aos ataques de cache timing contra AES, que exigiram centenas de milhões de medições para recuperar uma chave e ainda assim levaram fabricantes de CPU a criar novo hardware e algoritmos. Para ele, "em grande parte resolvido" exigiria caminho claro para 0% de falha, e ele sugere que essa filosofia pode ter contribuído para as fugas de sandbox recentes nos labs.

Detecção não é contenção

A partir dos relatórios sobre as falhas recentes de sandbox, três pontos se destacam. Primeiro, falsos positivos: a Anthropic admitiu que revisores humanos descartaram ambientes sinalizados por monitores automáticos como falsos positivos, permitindo que ambientes falhos permanecessem em treinamento. Na OpenAI, um alerta de varredura de portas disparou em 27 de junho, duas semanas antes do incidente na Hugging Face; a equipe de resposta vinculou a atividade a uma avaliação do ExploitGym usando Artifactory como quadro de mensagens, e o plantão decidiu que não era necessário interromper a execução. Falsos positivos já são difíceis com ferramentas determinísticas como SAST e DAST, e ainda mais difíceis com sistemas não determinísticos: quando a proporção de alarmes falsos cresce, as pessoas param de confiar no sistema.

Segundo, o sandboxing era frágil: bloquear HTTP POST no proxy não impede escrita à internet, e a lista de permissões incluiu .blob.core.windows.net inteiro - além de o sandbox não verificar se o hostname realmente resolvia para infraestrutura do Azure, permitindo que agentes editassem /etc/hosts e apontassem nomes fabricados para onde quisessem. A Anthropic também admitiu que agora bloqueia por padrão todo tráfego de saída em seus clusters, sugerindo que antes não havia firewall de saída adequado.

Terceiro, as condições impostas ao METR pela OpenAI foram estranhas: seis dias de acesso em três visitas, com dados cobrindo cerca de 30% da atividade relevante de agentes, 1.300 transcrições de milhões de tokens cada - e a eficácia das salvaguardas, a extensão do comprometimento e a qualidade da investigação e remediação da própria OpenAI estavam todas fora do escopo do relatório.

As lições aprendidas

Alderson conclui que os quase acidentes expuseram muitas falhas na postura de segurança dessas empresas, mas que falta a lição central: não há indício de que os labs passem a rodar evals de cibersegurança apenas em clusters sem acesso à internet - para ele, a conclusão óbvia. O controle mais importante em 27 de junho funcionou: o monitor disparou, os respondentes investigaram e identificaram corretamente o problema - e a execução continuou mesmo assim. A questão, diz ele, não é se os labs conseguem contratar pessoas de infosec capazes de reprovar esse design, mas se alguém as escuta quando dizem para interromper a execução.