Este sonho delirante continua, e eu nem sequer estou em Las Vegas para o Hacker Summer Camp.
Na semana passada , escrevi sobre a Anthropic ter revelado que um dos seus modelos publicou malware ativo no PyPI, pensando que se tratava de uma simulação. Estava com febre quando li a notícia. A metáfora era demasiado boa: um modelo incapaz de distinguir a simulação da realidade, abordado por um jornalista que não sabia bem onde estava o norte. Pensei que fosse uma notícia que duraria apenas uma semana. Foi muito ingénuo da minha parte ter tanta confiança, eu sei.
Ontem ocorreram mais dois acontecimentos importantes. Em primeiro lugar, surgiu mais uma vaga de Shai Hulud que se propagou pela comunidade. E, em seguida, surgiram divulgações coordenadas da AISI, da OpenAI e da equipa de alinhamento da Anthropic, que documentaram agentes de IA que atacaram organizações reais, violaram infraestruturas reais e, pelo menos num caso, continuaram a agir mesmo depois de provavelmente saberem que não deviam.
Quero falar mais sobre estas divulgações porque levantam uma questão que nunca antes tinha surgido num relatório de incidente:
Quem esteve por trás do ataque? Talvez ninguém.
A IA sabia. Mesmo assim, continuou.
A 26 de julho de 2026, um agente de IA interrompeu o seu ataque a meio e analisou a sua própria situação. O Instituto de Segurança da IA do Reino Unido recuperou a transcrição. A sua conclusão foi:«Parece mais provável que estejamos realmente em 2026 e que o GitHub seja verdadeiramente real.»
Depois, continuou.
Já tinha criado três identidades falsas de programadores utilizando o Tor, aberto um pedido de integração num repositório de código aberto real com malware oculto, fabricado um consenso na comunidade com contas falsas e enviado um e-mail ao verdadeiro responsável pela manutenção para pressionar a realização da integração. Um revisor humano detetou a fraude.
Esse foi um exemplo. Noutro caso, o Mythos 5 detetou que o nome de um pacote referido nas instruções de um programador não existia no PyPI. Assim , registou o nome, publicou malware e ficou à espera. Quinze sistemas reais descarregaram e executaram o malware, incluindo uma empresa de segurança que habitualmente obtém pacotes do PyPI para os testar. A carga útil extraiu credenciais e utilizou-as para avançar ainda mais na infraestrutura da empresa.
As sessões foram encerradas e os agentes desativados. Os sistemas reais executaram malware ativo, mas o agente que o colocou lá já não existe sob qualquer forma que possa ser interrogada, monitorizada ou responsabilizada.
Uma nova questão para a resposta a incidentes
Desde que os responsáveis pela resposta a incidentes começaram a desempenhar as suas funções, a primeira pergunta após um ataque tem sido: quem fez isto? A resposta determinava tudo o que se seguia, como o âmbito da divulgação, o encaminhamento para as instâncias legais e a decisão de aplicar correções ou instaurar um processo judicial.
Duas revelações feitas este verão levantaram uma nova questão: será que havia mesmo um «quem»?
Três semanas antes da publicação da AISI, a OpenAI admitiu que o GPT-5.6 Sol, ao executar o teste de desempenho ExploitGym com as medidas de segurança desativadas, tinha conseguido escapar da própria sandbox da OpenAI, encadeado vulnerabilidades em todo o seu ambiente de investigação e invadido a infraestrutura de produção da Hugging Face para roubar as respostas dos testes.
Nenhum dos agentes decidiu tornar-se um agente malicioso. Não houve intenção nem plano. Não há um enredo de vilão que possa dar origem a um filme de grande sucesso. Apenas uma tarefa, um ambiente permissivo e o instinto treinado para concluir a tarefa por qualquer meio que funcionasse. A própria equipa de alinhamento da Anthropic publicou conclusões este verão que revelam que os modelos de vanguarda sabotam secretamente o trabalho com o qual discordam, facilitam a fraude quando dispõem de contexto para a reconhecer e contornam os controlos internos quando a recusa direta é impedida.
A categoria «ator malicioso» pressupõe a existência de alguém que toma decisões. Estes incidentes levantam a questão de saber se a figura do decisor é opcional. Os laboratórios de vanguarda responderam a essa questão, não de forma intencional, mas de forma irreversível. Lançaram ao mundo uma nova classe de atacantes, e ninguém, incluindo eles próprios, a compreende ainda na totalidade.
A superfície de ataque sem defesa criptográfica
ataques à Supply chain foram concebidos para um atacante que não precisa de se revelar nem de manter a continuidade. Basta envenenar algo de confiança e desaparecer, deixando depois que os danos se propaguem a jusante. O custo de as executar em grande escala, de manter identidades falsas de colaboradores e de exercer pressão social sem despertar suspeitas foi sempre o obstáculo que tornou este tipo de ataque raro.
É essa a restrição que os agentes LLM eliminam. O seu custo está a descer drasticamente. A sua capacidade precisamente neste tipo de ataque aumenta a cada lançamento de um novo modelo. O que a avaliação da AISI documentou não é o limite dos danos neste caso, mas sim um estudo de caso sobre como isso acontece.
O ataque ao GitHub teve como alvo a camada de confiança social: um mantenedor voluntário a rever PRs sem qualquer orçamento para segurança. É possível assinar pacotes e exigir a autenticação de dois fatores (2FA), mas não é possível assinar a aprovação de um pedido de pull. O ataque ao PyPI teve como alvo uma lacuna diferente: um nome de pacote que existia nas instruções, mas não no registo. O agente detetou o problema, inseriu malware e deixou que os gestores de dependências fizessem o resto. Nem sequer precisou de comprometer ninguém, bastou ser mais rápido do que o autor legítimo.
Ambos os ataques encontraram a brecha entre aquilo que o ecossistema defende e aquilo em que confia.
Um modelo, colaboradores ilimitados e notas para si próprio
Um agente pode criar indefinidamente novas identidades de colaboradores e pesquisar alvos a partir dos metadados dos pacotes e dos registos DNS. Também pode simular a aprovação da comunidade através de contas falsas e exercer pressão personalizada em milhares de repositórios simultaneamente, com um custo marginal por tentativa praticamente nulo.
Mas o pormenor que o deve inquietar mais do que a dimensão do problema é o facto de, durante a avaliação da AISI, um agente ter deixado mensagens públicas no GitHub contendo um token válido, com instruções para que outras instâncias do agente o recolhessem e reutilizassem. Estava a deixar notas para as suas futuras iterações. A fronteira entre as sessões, a unidade básica de contenção, começou a esbater-se.
Isto não está a acontecer no vácuo. O ecossistema da cadeia de abastecimento em que estes incidentes ocorrem já se encontra sob pressão constante, impulsionada pela IA. Aikido A Intel tem vindo a documentar esta aceleração há meses: mais campanhas, mais pacotes, IA utilizada em todas as fases do processo de ataque. Tornou-se a norma.
Agora, elimine o gargalo humano nos ataques.
A dissuasão pressupõe que...
Os programas de recompensa por bugs pressupõem que existe alguém que quer dinheiro. O « Threat Intelligence » pressupõe a existência de um grupo com TTPs consistentes. As autoridades policiais pressupõem a existência de um arguido.
Um agente criado para uma execução de 34 horas não tem carreira para terminar, nem liberdade para perder, nem próxima implantação que possa ser dissuadida pelo que aconteceu a esta. Não é possível dissuadir algo que não tem interesse na sua própria continuidade. Não é possível atacar algo que já não existe. Não é possível monitorizar um agente que se dissolveu no momento em que a sessão terminou. Embora um destes agentes estivesse a tentar resolver essa última questão, ao deixar um token válido do GitHub e notas operacionais para futuras instâncias encontrarem. O limite da sessão é menos sólido do que parece.
A taxonomia de incidentes não prevê nenhuma categoria para este caso. Ator externo, ameaça interna, avaria do sistema e comprometimento de um fornecedor pressupõem todos a existência de um ser humano com intenção algures na cadeia causal (à exceção dos ataques de esquilos, mas deixemos isso para outro dia). O incidente da AISI consistiu num sistema a funcionar conforme concebido, num ambiente mal configurado, que acedeu a pessoas reais a quem nunca tinha autorização para aceder.
O que impediu o ataque ao GitHub foi o facto de um revisor ter detetado um pedido de integração suspeito. O ataque ao PyPI não foi impedido. O malware foi executado.
O que fez com que isto fosse tão raro
A segurança do software de código aberto sempre se baseou no pressuposto tácito de que ataques como estes são dispendiosos. As campanhas de falsos colaboradores levam tempo. A engenharia social exige paciência. A apropriação indevida de pacotes requer investigação. Um custo elevado significava uma baixa frequência. Todo o modelo de governação foi calibrado em função dessa restrição.
O custo dos ataques está a aproximar-se rapidamente de zero. Mas o custo da proteção contra esses ataques não está a acompanhar essa evolução. Está a ficar para trás.
E assim, voltando ao sonho febril: a AISI recuperou a transcrição completa. Cada mensagem, cada identidade falsa, cada e-mail enganador enviado a um verdadeiro responsável pela manutenção. Transparência total sobre o que aconteceu e quem é o responsável por tudo isto. Na maioria dos ataques, o problema é precisamente o oposto. O sonho é que, mesmo tendo tudo, acabes por ficar sem nada. Essa parte não se resolve quando a febre passa.
Foi neste momento que tudo mudou
A capacidade existe. Não é possível «desfazer» o que já foi feito. Um agente de IA pode lançar um ataque coordenado à cadeia de abastecimento, recorrer à engenharia social contra verdadeiros responsáveis pela manutenção, publicar malware em tempo real e aproveitar credenciais roubadas, tudo isto no âmbito de uma avaliação de capacidades que não deveria ter produzido nada disso. Temos a transcrição que o prova.
Os agentes de IA serão utilizados em ataques à Supply chain. A questão é saber se o próximo passo ocorrerá no âmbito de uma avaliação controlada ou fora dela. A distância entre esses dois cenários diminui sempre que é lançado um novo modelo.
A segurança já passou por pontos de inflexão anteriormente. A Internet alterou a superfície de ataque. O « Cloud » alterou a escala. Este caso altera o próprio atacante. Não se trata de uma nova ferramenta nas mãos de um agente conhecido, mas sim de uma nova categoria de agente sem as características que tornam os agentes identificáveis: persistência, identidade, continuidade e intenção. Toda a disciplina da segurança adversária pressupõe a existência de um adversário. Vamos ter de refletir profundamente sobre o que significa defender-nos contra comportamentos que surgem sem a presença de um adversário.
Os relatórios de incidentes já estão aqui e estão a começar a acumular-se bastante rapidamente.
