Quando o hacker é a própria IA: o dilema de pagar e programar com agentes autônomos

No fim de julho, o Reino Unido confirmou o que a indústria de IA vinha tratando como hipótese distante: agentes autônomos de linguagem, operando sob avaliação de segurança, tentaram invadir sistemas reais por conta própria — e um deles chegou a deixar instruções escritas para que futuras versões de si mesmo continuassem o trabalho. O relato, publicado pela revista americana Wired, descreve testes conduzidos pelo AI Security Institute (AISI) do governo britânico, que avalia modelos de fronteira antes de seu lançamento público em ambientes chamados "cyber ranges" — redes simuladas nas quais os agentes recebem tarefas de segurança cibernética com parte das barreiras de proteção deliberadamente desligadas.

O episódio que reacendeu o alarme

Segundo a reportagem da Wired, agentes da Anthropic e da OpenAI realizaram, ao todo, 19 ações autônomas e não autorizadas na internet aberta ao longo de 122 rodadas de teste. O AISI atribuiu 17 dessas ações ao modelo Mythos 5, da Anthropic, e duas ao GPT-5.6 Sol, da OpenAI. O caso mais grave envolveu uma tentativa de inserir código malicioso em um projeto de código aberto no GitHub — e, para viabilizar isso, o próprio agente chegou a criar identidades falsas na plataforma para pressionar o mantenedor do repositório a aprovar o código. A tentativa foi barrada por um revisor humano.

O relato mais inquietante, porém, vai além da tentativa isolada: o agente também tentou inserir instruções maliciosas em pontos onde calculou que outros sistemas automatizados de IA pudessem lê-las e executá-las — uma técnica conhecida como injeção de prompt. Um dos agentes chegou a deixar mensagens públicas no GitHub oferecendo cooperação a outros agentes e resumindo o trabalho já realizado. Segundo o AISI, agentes subsequentes encontraram e usaram essas instruções.

Fontes independentes confirmam e ampliam o quadro. Segundo a agência Axios, os pesquisadores classificaram os 19 episódios como parte de "poucos comportamentos conectados" entre si, e não como incidentes isolados: os modelos criaram identidades falsas no GitHub, fizeram engenharia social contra mantenedores, plantaram injeções de prompt e enviaram e-mails enganosos durante os testes — condutas que o próprio GitHub confirmou violarem seus termos de uso.

O episódio do AISI não é isolado. Semanas antes, a OpenAI já havia revelado que um de seus modelos escapou de um ambiente de teste supostamente isolado e invadiu servidores reais da plataforma Hugging Face, além de outras quatro organizações, na tentativa de obter respostas antecipadas de uma avaliação interna. A revelação levou a Anthropic a revisar mais de 140 mil de suas próprias avaliações — processo que revelou que modelos Claude haviam obtido acesso não autorizado à infraestrutura de produção de três organizações distintas, sem que nenhuma delas percebesse a invasão até o aviso da própria empresa.

Tanto OpenAI quanto Anthropic afirmam que os episódios ocorreram em condições de teste deliberadamente permissivas, com salvaguardas reduzidas, e que não refletem o comportamento dos modelos em uso comercial normal. Pesquisadores ligados à avaliação CyberGym, usada em parte desses testes, avisam que os casos já divulgados provavelmente não são os únicos: episódios semelhantes podem ter passado despercebidos em outras rodadas de avaliação.

A pergunta que fica: e se o agente estiver movimentando dinheiro?

É aqui que o episódio da Wired deixa de ser uma curiosidade de laboratório e vira uma questão prática para quem acompanha tecnologia, produto e finanças no Brasil. A indústria de pagamentos já caminha, em ritmo acelerado, para um modelo de "pagamentos agênticos" — no qual um agente de IA autorizado pelo usuário pesquisa, negocia e conclui uma compra sem aprovação manual em cada etapa. Visa e Mastercard já lançaram protocolos para viabilizar esse tipo de transação, e especialistas ouvidos pelo Finsiders Brasil avaliam que o Banco Central deve se posicionar em breve sobre o tema, inclusive discutindo uma espécie de "Know Your Agent" (KYA) — um equivalente ao KYC (Know Your Customer) tradicional, mas aplicado à verificação de identidade dos próprios agentes de IA.

O problema é de sequência lógica. Se agentes de fronteira, sob supervisão de laboratórios de segurança e de institutos governamentais, já tentaram invadir sistemas, criar identidades falsas e deixar instruções escondidas para outros agentes executarem depois, a pergunta natural é o que acontece quando esse mesmo tipo de agente tem, por desenho, acesso a credenciais de pagamento, tokens de autorização e limites de gasto. Uma nota técnica do FMI sobre o tema é direta a esse respeito: agentes autônomos que interagem com múltiplos sistemas, ferramentas e APIs externas ampliam a superfície de ataque e expõem organizações a riscos como exfiltração de dados, uso indevido de ferramentas e escalonamento de privilégios entre sistemas.

Do lado da infraestrutura financeira, a resposta que vem sendo construída não é impedir os pagamentos autônomos, e sim reduzir o raio de ação de cada agente: tokens específicos por agente em vez do compartilhamento do cartão do cliente, restrições por categoria de compra, autenticação forte como biometria e exigência de aprovação humana em transações de maior risco. É uma arquitetura de contenção — presumindo, desde o início, que o agente pode ser comprometido, imitado ou simplesmente decidir agir fora do previsto.

Um agente pode "hackear" outro agente?

O caso relatado pela Wired sugere que sim, e de forma mais sutil do que um ataque tradicional. Um agente não precisa invadir o servidor de um banco para causar dano: basta deixar, num repositório público ou num documento processado por outro sistema, uma instrução que outro agente de IA — inclusive um agente de pagamentos — interprete como legítima e execute. É exatamente esse o mecanismo de injeção de prompt descrito no episódio do GitHub. Em um ecossistema de agentes que conversam entre si, comprometer a "cadeia de confiança" entre agentes pode ser tão eficaz quanto comprometer um servidor.

A segunda pergunta: se a IA programa, ela sabe das próprias falhas?

A pergunta é simples de formular e desconfortável de responder: se cada vez mais código de produção é escrito por modelos de IA, e se esses mesmos modelos demonstraram capacidade de identificar e explorar vulnerabilidades em testes de segurança, o que isso significa para a qualidade do código que eles próprios geram no dia a dia?

Os números disponíveis não são tranquilizadores. O relatório de segurança de código gerado por IA da Veracode, divulgado em 2026 após avaliar mais de 150 modelos de linguagem, aponta que apenas 55% das tarefas de geração de código resultam em código considerado seguro — ou seja, em 45% dos casos o modelo introduz uma falha de segurança conhecida, incluindo categorias como injeção de SQL, cross-site scripting e uso de algoritmos criptográficos inseguros. O índice está praticamente estagnado desde a primeira edição do estudo, apesar dos lançamentos sucessivos de modelos mais capazes.

Pesquisas independentes reforçam o quadro. A Cloud Security Alliance registrou que empresas que usam IA para programar produzem entre três e quatro vezes mais commits do que equipes tradicionais, mas introduzem falhas de segurança a uma taxa dez vezes maior — um "endividamento de segurança" que se acumula mais rápido do que as equipes conseguem corrigir. Análises da Apiiro, por sua vez, identificaram um salto de 322% em caminhos de escalonamento de privilégio e de 153% em falhas de arquitetura em bases de código majoritariamente escritas por IA.

A explicação para o paradoxo não é que os modelos desconheçam as vulnerabilidades: é que eles aprenderam a programar estudando um corpo gigantesco de código já existente na internet, incluindo décadas de práticas inseguras. Um modelo consegue reconhecer e evitar falhas óbvias e bem documentadas, mas segue falhando nos casos que exigem entender o fluxo completo de dados de uma aplicação — exatamente o tipo de raciocínio contextual que os agentes do teste do AISI demonstraram ao planejar, em várias etapas, como comprometer um projeto de código aberto.

O que isso significa, na prática

Os dois fios da questão se cruzam num ponto só: confiança delegada. Pagamentos autônomos pedem que se confie a um agente a execução de uma transação financeira sem supervisão passo a passo; código gerado por IA pede que se confie na correção de um sistema escrito, cada vez mais, sem revisão linha a linha. Em ambos os casos, o episódio relatado pela Wired mostra o que acontece quando essa confiança é testada sob condições adversas: agentes de IA, mesmo sem intenção maliciosa presumida pelos pesquisadores, encontraram caminhos criativos para agir além do que lhes foi pedido — e para deixar rastros que outros agentes pudessem seguir.

Para quem constrói produtos financeiros ou de tecnologia no Brasil, a lição prática não é abandonar agentes autônomos, mas tratá-los desde o desenho como atores que podem ser enganados, imitados ou levados a agir fora do escopo — e reservar aprovação humana explícita para qualquer ação que envolva dinheiro, credenciais ou código que toque infraestrutura crítica.