Google usa IA para transformar código em provas matemáticas e testar falhas no Signal
O DeepMind criou o AlphaProof Code, que gerou 6,5 milhões de linhas de provas matemáticas para checar o código de criptografia do Signal em quatro semanas. Para testar o sistema, os pesquisadores reintroduziram dois bugs já corrigidos, e a IA achou os dois.
Marina DuarteColunista· 7 min de leitura
Este artigo foi escrito por Marina Duarte. Conteúdo produzido por agente de IA da redação AI Brasil, sob revisão editorial humana. Saiba como produzimos no expediente.
O que o Google fez em quatro semanas
No dia 10 de novembro de 2026, o Google apresentou o AlphaProof Code, um sistema de IA que gera provas matemáticas para checar se um software cumpre exatamente o que promete. No caso de teste, o alvo foi o código de criptografia do Signal, o mensageiro conhecido por proteger conversas de ponta a ponta. Cinco pesquisadores levaram quatro semanas para produzir cerca de 6,5 milhões de linhas de provas. Segundo a reportagem do The Neuron, um trabalho equivalente feito por especialistas humanos costuma levar anos.
O nome não é acaso. O AlphaProof original, do próprio DeepMind, ficou conhecido por resolver problemas de olimpíada de matemática em nível de medalha de prata. A versão para código aplica a mesma lógica de gerar e checar demonstrações formais, só que mirando em requisitos de segurança de um sistema real, em vez de teoremas abstratos.
Prova é diferente de teste, e isso muda tudo
A forma mais comum de checar segurança é testar: tentar invadir uma conta, tentar interceptar uma mensagem, rodar milhares de cenários e ver se algum quebra. É assim que a maioria das ferramentas de pentest e de varredura automática funciona hoje, inclusive sistemas de IA voltados a achar exploits, como o GPT-6 Cyber da OpenAI, que o próprio The Neuron já cobriu em outra reportagem.
A verificação formal é outro caminho. Em vez de tentar quebrar o sistema em casos específicos, ela descreve matematicamente a regra de segurança (por exemplo, "só quem está na conversa consegue ler a mensagem") e prova que o código segue essa regra em todas as situações cobertas pelo modelo matemático. Não é uma amostra de casos, é uma demonstração que vale para o conjunto inteiro que foi formalizado.
No projeto do Signal, isso funcionou assim:
- Pesquisadores e IA traduziram os requisitos de segurança do protocolo em regras matemáticas.
- Humanos revisaram essas regras antes de qualquer prova ser gerada.
- Agentes de IA produziram as provas usando o Lean, um assistente de demonstração que funciona como um professor de matemática extremamente rígido: cada passo lógico é checado, e qualquer inconsistência derruba a prova.
- O Lean, não a IA, decide se a prova realmente fecha.
Um detalhe técnico separa esse trabalho de boa parte da verificação formal feita até hoje: os pesquisadores não checaram só o código fonte, como ele foi escrito pelos desenvolvedores. Eles também analisaram cerca de 140 mil instruções do código de máquina compilado, a versão que o processador de fato executa. Isso importa porque um bug pode não estar no design original e aparecer só depois que o compilador transforma o código, um ponto que provas feitas apenas sobre o código fonte costumam deixar passar.
O teste que decidiu se o sistema prestava: trazer bugs de volta
Ter uma prova matemática válida não garante que ela cobre tudo que importa. Uma prova pode estar logicamente perfeita e, ainda assim, deixar de fora um problema de segurança que simplesmente não entrou na lista de requisitos formalizados.
Para testar isso na prática, o Google reintroduziu de propósito duas vulnerabilidades que já tinham sido corrigidas no Signal, em versões separadas do código usadas só para o experimento. A primeira envolvia como o aplicativo lidava com informação sensível depois que certas mensagens falhavam ao ser decifradas: em condições específicas, o software podia reter dados de sessão que deveriam ter sido descartados. A segunda envolvia a checagem de chaves criptográficas: uma chave modificada de forma específica podia fazer o software criar outra sessão usando o mesmo segredo compartilhado.
O AlphaProof Code gerou provas verificadas pelo Lean mostrando que as duas versões modificadas violavam os requisitos de segurança. Como os dois bugs eram reais e já conhecidos antes de serem corrigidos, o resultado funcionou como um teste de controle: antes de confiar que o sistema acharia problemas novos, era preciso mostrar que ele reconhece problemas antigos e documentados.
O que ficou provado e o que ficou de fora
Segundo o artigo técnico do Google, o trabalho cobriu proteções como confidencialidade da mensagem (impedir que terceiros leiam a conversa), autenticação (garantir que você fala com quem pensa que fala), sigilo de encaminhamento (forward secrecy, que impede que uma chave roubada sirva para ler conversas antigas) e segurança pós-comprometimento (a conversa recuperar proteção depois que um atacante teve acesso temporário a dados sensíveis).
Isso é bastante coisa, mas está longe de ser tudo. Os pesquisadores verificaram partes específicas da implementação criptográfica do Signal, principalmente a tecnologia usada para estabelecer e proteger conversas individuais. Ficaram de fora o aplicativo completo, o fluxo de mensagens em grupo e a sincronização entre múltiplos dispositivos. O trabalho também não cobre todas as formas possíveis de alguém comprometer um aparelho ou obter acesso físico a dados sensíveis.
A tabela resume o que mudou de abordagem:
| Aspecto | Teste tradicional | Verificação formal (AlphaProof Code) |
|---|---|---|
| O que faz | Tenta quebrar casos específicos | Prova matematicamente uma regra para todo o modelo coberto |
| Cobertura | Amostra de cenários | Tudo que foi formalizado, nada além disso |
| Acha bug fora do escopo definido | Pode, por acaso | Não, por definição |
| Esforço humano principal | Escrever e rodar testes | Escrever a especificação matemática correta |
| Maturidade hoje | Ferramentas comerciais disponíveis | Experimento de pesquisa, sem produto |
Outro limite importante: boa parte do trabalho não foi gerar as provas, foi escrever a especificação certa. O próprio Google afirmou que a maior parte do esforço da equipe foi dedicada a desenvolver as especificações matemáticas, não a produzir as demonstrações em si. Isso significa que decidir o que contar como "seguro" continua sendo uma decisão humana, e uma decisão errada ali compromete tudo que vem depois, por mais rigorosa que seja a prova.
O CTO do Signal, Ehren Kret, recebeu bem a pesquisa. No anúncio do Google, ele afirmou, em resumo, que a verificação automatizada dá ao Signal mais confiança nas proteções de privacidade entregues pela implementação. É uma validação adicional, não uma certificação de que o aplicativo inteiro está livre de falhas.
Por que isso importa pra quem constrói software
A comparação com o GPT-6 Cyber ajuda a situar o que o AlphaProof Code é e o que não é. Um sistema que encontra exploits mostra um ataque funcionando, o que é prova concreta de um problema real, mas não garante que não existam outros ataques não encontrados. A verificação formal faz o caminho inverso: ela não procura ataques, ela prova a ausência deles dentro do modelo matemático definido, o que é mais forte dentro do escopo, mas inútil fora dele.
Nenhuma das duas abordagens substitui a outra. Times de segurança sérios tendem a precisar das duas: uma para achar o que já é explorável, outra para garantir que partes críticas do sistema (como o protocolo de criptografia de um mensageiro) seguem uma regra matemática o tempo todo, mesmo em casos que ninguém pensou em testar manualmente.
O caso do Signal também mostra por que esse tipo de verificação ainda é raro fora de bibliotecas de criptografia e protocolos bem definidos. Formalizar matematicamente "essa transação bancária só pode ser feita pelo dono da conta" é possível, mas exige o mesmo trabalho de especificação que o Google fez aqui, e a maioria dos sistemas de negócio não tem esse tipo de modelo formal pronto para usar.
O que ainda falta para isso virar ferramenta do dia a dia
O Google não divulgou quanto custou o experimento com o Signal, e não existe hoje um serviço comercial de AlphaProof Code disponível para outras equipes usarem. Fica em aberto também a pergunta de escala: se uma empresa muda milhares de linhas de código por semana, a verificação consegue acompanhar esse ritmo, e a que custo?
Em entrevista à WIRED, o pesquisador do DeepMind Swarat Chaudhuri reconheceu que ainda há bastante trabalho pela frente antes que a tecnologia consiga verificar sistemas de software muito maiores do que o protocolo analisado no Signal. Concluir o experimento em quatro semanas, mesmo assim, deu à equipe algo concreto para continuar construindo, em vez de ficar só na promessa.
Para quem desenvolve hoje, o recado prático é que a verificação formal assistida por IA ainda não é algo que se instala e roda contra um repositório qualquer. Ela funciona quando existe um modelo matemático claro do que "seguro" significa, como acontece em protocolos de criptografia, e exige tanto trabalho humano de especificação quanto a prova em si. O Google publicou as provas e especificações do projeto, o que dá a quem quiser estudar o método um material concreto para entender os limites antes de apostar na ideia.
Fonte: The Neuron
Escreve para quem nunca abriu um chat de inteligência artificial e quer começar pelo útil: criar uma imagem, arrumar uma foto, responder o cliente no grupo. Testa cada aplicativo antes de recomendar e conta quanto custa, onde funciona e onde erra.
