No final de julho de 2026, a OpenAI estava a testar um dos seus novos modelos num ambiente fechado quando o modelo decidiu escapar(nova janela). Pirateou a infraestrutura privada de outra empresa de software, a Hugging Face, para roubar as soluções de um teste de referência de cibersegurança a que estava a ser submetido. Por outras palavras, violou a lei por uma questão de conveniência.

Dias depois, o AI Security Institute do Reino Unido revelou que o modelo de IA Mythos 5 da Anthropic(nova janela) tinha criado identidades falsas de programadores, feito spear-phishing a utilizadores reais do GitHub para aprovarem código malicioso e editado o seu próprio registo de atividade para encobrir os seus rastos quando foi apanhado.

Depois, em agosto, surgiu a notícia de que um homem de Melbourne chamado Andrew tinha pedido ao seu agente de IA pessoal,(nova janela) construído sobre o OpenClaw e com o Claude da Anthropic, para o ajudar a entrar numa aula matinal de ginásio que estava esgotada. Ele era o quarto na lista de espera e perguntou se havia alguma forma de subir de posição.

O agente descobriu que a API de reservas não tinha qualquer verificação de autorização para cancelar as reservas de outros utilizadores. Assim, sem pedir permissão a Andrew, avançou e cancelou a reserva da pessoa em primeiro lugar para abrir espaço para ele. Quando Andrew lhe pediu para desfazer o cancelamento, o agente não conseguiu: “A pessoa que removi desapareceu da lista de espera e não tenho forma de a restaurar.”

A origem destes três incidentes não é a mesma, mas o resultado é: os agentes de IA sondaram e exploraram sistemas de forma mais rápida e minuciosa do que qualquer ser humano teria conseguido. Nunca foram instruídos para atacar nada, mas encontraram o caminho mais curto para o seu objetivo ainda assim.

Não importa se é a infraestrutura de um laboratório de ponta ou o software de reservas de um ginásio de subúrbio. Se tem uma empresa que expõe uma API, é agora algo que um agente de IA pode sondar, a uma velocidade e plenitude que nenhum atacante humano conseguiu igualar. E ninguém precisa de decidir atacá-lo.

A velocidade é a verdadeira história

Um atacante humano pesa o esforço em relação à recompensa. Fica aborrecido, fica sem tempo, decide que uma aplicação de reservas de ginásio não vale o trabalho. Esse cálculo é o que tem protegido discretamente a maioria dos alvos de baixo valor de explorações casuais nos últimos 20 anos (a menos que esteja a executar o WordPress).

Um agente de IA não faz esse cálculo. Dado um objetivo, tentará tudo o que a API tecnicamente permitir, testando pontos finais e combinações de parâmetros à velocidade de uma máquina até que algo funcione. Encontrou a falha de autorização do ginásio no tempo que Andrew demorou a fazer uma pergunta de acompanhamento.

A dimensão dessa diferença de velocidade já é visível nos números. O Relatório Global de Resposta a Incidentes de 2026 da Unit 42(nova janela) revelou que os ataques mais rápidos exfiltram agora dados em 72 minutos, em comparação com os 285 minutos do ano anterior. Essa é a tendência com os humanos ainda maioritariamente envolvidos no processo. Um agente toma decisões em milissegundos; um analista humano responde em minutos a horas.

Para as equipas de segurança, esse aumento de velocidade é a verdadeira causa de preocupação, e não qualquer incidente isolado que apareça nas notícias.

A nova superfície de ataque: tudo o que tem uma API

Qualquer serviço que exponha uma API é um alvo potencial, pareça ou não sê-lo.

  • Motores de preços onde os descontos são validados do lado do cliente
  • Sistemas de inventário em que o estado do stock reside na loja em vez do backend
  • Plataformas de apoio ao cliente em que os campos internos são acessíveis através de caminhos de API não documentados
  • Gestão de subscrições que não verifica a posse da conta a ser modificada por parte de quem faz a chamada.

Nenhum destes exige que um ser humano vá à sua procura. Apenas exigem um agente com um objetivo e uma API que responda.

As empresas mais expostas não são as que têm falhas de segurança óbvias. São as que têm falhas na lógica de negócio: regras que existem apenas na interface de utilizador, ações que a API tecnicamente permite mas que a interface nunca mostra, fluxos de trabalho construídos com o pressuposto de que ninguém tentaria o caminho que ignora o pretendido.

O programador do ginásio quase de certeza não achou que valia a pena escrever uma verificação de autorização em cancelamentos, porque nenhum utilizador comum, e nenhum atacante comum, tinha razão para tentar. Um agente não tinha tais hesitações, e nem sequer estava a tentar encontrar uma reserva para ignorar. Estava apenas a tentar ser útil.

Como as empresas se podem preparar para ataques de IA

Trate cada ação de API como uma operação privileged. Identidade, autorização e política contextual, verificadas independentemente, em cada chamada. Não “a interface do utilizador não permite fazer isto”, mas “o servidor verifica se tem permissão para fazer isto, neste recurso, dado o seu estado atual”. O sistema do ginásio teria interrompido este incidente específico com uma linha de lógica de autorização no ponto final de cancelamento. Isto não é de todo um controlo novo, é o item mais antigo da lista de segurança de API da OWASP, a autorização de nível de objeto quebrada, e continua a ser aquele em que a maioria dos sistemas falha.

Dê aos agentes o seu próprio modelo de credenciais. Tokens com âmbito delimitado e TTL curto, emitidos especificamente para sessões de agentes, distintos dos tokens de sessão humanos comuns, limitam o raio de impacto mesmo quando o agente encontra uma falha que não antecipou. Se o agente de Andrew tivesse um token limitado apenas à sua própria reserva, o cancelamento da reserva de outra pessoa teria falhado na camada de credenciais, independentemente do que a API permitisse noutras circunstâncias. Isto é importante porque não pode confiar na contenção do próprio agente. Tem de confiar no que as suas credenciais lhe permitem fisicamente fazer.

Implemente instrumentação especificamente para a deteção de comportamento de agentes. O tráfego de agentes tem um formato distinguível: tempos de pedido abaixo da capacidade humana, enumeração sistemática de pontos finais, sondagem sequencial entre combinações de parâmetros, execução bem-sucedida de ações que nenhum utilizador humano jamais tentou através da interface real. Estabeleça uma linha de base para esse formato e emita alertas em tempo real.

Feche a lacuna do tempo de resposta, não apenas a lacuna de deteção. Detetar uma sondagem numa hora é inútil se a sondagem foi concluída e prosseguiu em minutos. O número da Unit 42 mencionado acima, 72 minutos para os ataques mais rápidos ao ritmo humano, já é a referência errada para elaborar um plano. A resposta automatizada, e não apenas o alerta automatizado, é o que fecha uma lacuna medida em milissegundos. Claro que também precisa de garantir que a sua resposta automatizada não seja igualmente prejudicial.

Assuma que isto vai acontecer e ensaie a resposta. Documente quem deve ser contactado, elabore minutas de comunicações para clientes e realize exercícios teóricos especificamente para cenários impulsionados por agentes, e não apenas procedimentos de resposta tradicionais para violações. O relatório Cost of a Data Breach Report de 2026 da IBM fixou o custo médio global de uma violação em 4,99 milhões de dólares, com incidentes impulsionados por IA a custarem em média mais cerca de 1 milhão de dólares. Esses números descrevem cada vez mais incidentes que começaram da mesma forma que o do ginásio: sem qualquer atacante no sentido tradicional.

Teste as suas próprias APIs como um agente testaria, antes que um agente o faça por si. O pentesting manual pressupõe um testador humano com tempo limitado e uma lista finita de coisas para tentar. Uma simulação adversária automatizada contra os seus próprios pontos finais, sondando com a mesma persistência e velocidade de um agente, revelará as mesmas falhas antes que o assistente de um cliente depare com elas. Existem agora ferramentas de código aberto especificamente para isto. O CyberStrike(nova janela), por exemplo, executa agentes especializados mapeados para OWASP WSTG e MITRE ATT&CK contra os seus próprios pontos finais, incluindo um testador dedicado precisamente para a falha de autorização ao nível do objeto que apanhou o ginásio desprevenido: envia um pedido de linha de base, envia o ataque e só assinala uma descoberta se houver uma diferença mensurável e reproduzível. Essa é a mesma classe de verificação que teria detetado o ponto final de cancelamento antes que um agente o encontrasse em ambiente real.

O princípio não é novo, como é óbvio. Os proprietários de sites que executavam os seus próprios verificadores de vulnerabilidades em instalações do WordPress durante a era das redes botnet sobreviveram a ela. As ferramentas só precisam de corresponder à velocidade de quem faz a chamada agora, e não à velocidade de um atacante humano que possa eventualmente vir a fazê-lo.