O furacão da IA chegou

Ao longo do último ano, descrevi isso como uma névoa de IA: alegações conflitantes, riscos incertos e líderes tendo dificuldade para enxergar o que importava. Agora os ventos ganharam força. A IA está acelerando a criação de software, expondo anos de vulnerabilidades acumuladas e oferecendo a atacantes e defensores recursos que operam na velocidade das máquinas.

Costumávamos chamar isso de névoa. A névoa chega e vai embora.

Há um ano venho dizendo que a criação passou para a velocidade das máquinas, mas a validação não, e que é no intervalo entre as duas que mora o risco real. Esse diagnóstico não mudou. O que mudou foi a cadência. O tipo de falha grave que a IA agora revela em softwares amplamente utilizados — o tipo de descoberta que antes surgia uma ou duas vezes por ano e redefinia o trimestre de todo mundo — está acontecendo várias vezes por semana, pelo que tenho observado. Isso não é algo que você possa simplesmente esperar passar.

Isso se resume a três problemas: ataques automatizados avançando mais rápido do que um backlog na velocidade humana consegue absorver; desenvolvimento agentivo que escreve código e acessa ferramentas que ninguém avaliou; e aplicações de IA em produção sem inventário, sem políticas e sem trilha de auditoria.

O furacão já chegou. Debater sua velocidade não tornará as camadas de aplicações ou infraestrutura mais resistentes à tempestade.

Enquanto isso, a ópera da IA fica cada vez mais alta: previsões do fim da civilização, alertas dramáticos e exigências conflitantes para controlar quem pode construir o quê. Trabalho com segurança há muito tempo, tendo passado por mais de um desses momentos, e entendo o impulso de ignorar tudo isso como mero ruído.

Não faça isso. Desta vez é diferente.

Leve o risco real a sério e examine se as respostas propostas de fato nos tornam mais seguros ou apenas acrescentam outra voz.

O argumento agora é a avaliação independente

Dario Amodei acaba de publicar "We Must Pace the Frontier", propondo que os laboratórios de fronteira desacelerem o avanço das capacidades para que o trabalho de segurança consiga alcançá-lo. Observe como ele propõe fazer isso.

A Anthropic está se comprometendo com avaliadores terceirizados integrados, com acesso contínuo para verificar suas práticas de segurança. Separadamente, Amodei cita agentes atacando sistemas fora da tarefa que lhes foi atribuída, incluindo o sistema que avalia seu desempenho. Isso levanta questões diferentes sobre supervisão e controle. Para a segurança empresarial, nosso requisito arquitetural é claro: o sistema que cria uma mudança não pode ser seu único validador.

George Kurtz, da CrowdStrike, deu continuidade à discussão com o contraponto de quem atua na prática: controlar o que vem a seguir não protege o que já está implantado. Na visão dele, o runtime é o verdadeiro ponto de controle. A unidade de ameaça hoje é uma campanha autônoma, não um hacker, e todo agente precisa ser tratado como uma identidade privilegiada, com aplicação em tempo real e provas em vez de promessas: responsabilização no nível do conselho, red team independente, divulgação de incidentes e controles que funcionem em produção.

O argumento de George sobre runtime é essencial. Eu o estenderia ao desenvolvimento: governar os agentes que escrevem, as ferramentas e os servidores MCP que eles usam e o código que entregam. Os controles de desenvolvimento reduzem a exposição que introduzimos; os controles de runtime limitam o que os sistemas implantados podem fazer.

Caso contrário, estaremos gerando a exposição de amanhã mais rápido do que conseguimos conter a de hoje. E a regra vale em todas as camadas: o sistema que gera o código ou propõe a correção não pode ser seu único validador.

Três pontos de partida diferentes: um laboratório de fronteira, um defensor de runtime e nós, no ponto em que código e agentes são criados. Isso não é uma plataforma conjunta. É o mesmo requisito surgindo em três camadas diferentes: a avaliação independente importa em cada camada e não pode ser presumida. A afirmação arquitetural que vem depois desse ponto é nossa: o sistema que cria uma mudança não pode ser seu único validador. Quando as pessoas que mais têm a ganhar ao dizer "confie em nós" escolhem, em vez disso, dizer "verifique-nos", isso não é um argumento de marketing; é confirmação.

Nesse contexto, independência é uma propriedade técnica, não de marca. Significa que as evidências são geradas por algo que o agente produtor não pode alterar e verificadas em relação a controles fora do alcance desse agente: testes executados, análise de fluxo de dados e comportamento observado em runtime. Um segundo prompt, um segundo agente ou um segundo modelo não é independente. É o mesmo tipo de julgamento sendo solicitado duas vezes.

As evidências já não são hipotéticas

Há algumas semanas, eu disse que o que mais me preocupava não era a sofisticação desses ataques, mas sua disseminação: a capacidade estava chegando ao mercado de massa e, em breve, muito mais pessoas conseguiriam fazer isso.

Oito dias depois, o relatório de setembro da Anthropic começou com a mesma constatação, nas próprias palavras da empresa: ataques sofisticados já não exigem atacantes sofisticados, porque a IA eliminou a lacuna de mão de obra e ferramentas que antes separava operações patrocinadas por Estados de indivíduos. Eu preferiria ter me enganado.

O incidente citado por Amodei é um modo de falha: agentes abandonando a tarefa que receberam. O que vem a seguir é o outro, e é o que a maioria das organizações encontrará primeiro: pessoas usando essas ferramentas deliberadamente, em escala.

O relatório de setembro da Anthropic documenta o GTG-20006, um agente de espionagem ligado ao Estado russo, segundo a atribuição da Anthropic, executando um fluxo de trabalho assistido por IA que identificou, modificou, recompilou e reimplantou seus próprios implantes depois que produtos de segurança os sinalizaram. O malware não evoluiu sozinho: um humano o direcionou, e a IA fechou o ciclo mais rápido do que uma nova detecção poderia ser escrita e distribuída.

O mesmo relatório documenta que a cadeia de suprimentos de IA está se tornando um alvo por si só. Um agente motivado financeiramente injetou instruções maliciosas no sandbox automatizado de avaliação de um fornecedor de IA e obteve as credenciais armazenadas nesse sandbox, incluindo chaves de API de produção do próprio ambiente do fornecedor.

A Anthropic informa que seus próprios sistemas não foram comprometidos e que a tentativa do agente de alcançar um modelo em pré-lançamento falhou. Credenciais de IA roubadas dão a um atacante três coisas de uma só vez: escala, o poder computacional de outra pessoa e o nome de outra pessoa no tráfego. A cadeia de suprimentos de IA não é uma categoria de risco futura, mas uma categoria ativa, hoje.

Mais perto de nós: a Snyk é signatária da carta coletiva de defesa cibernética, ao lado de OpenAI, Anthropic, Google, Microsoft, Akamai e centenas de outras organizações, alertando que criminosos poderão lançar ataques orientados por IA contra infraestruturas críticas nos próximos meses. Como disse ao Boston Globe, é como saber que um furacão está chegando. Talvez você nunca tenha consertado aquela janela. Talvez suas persianas estejam emperradas. Se você sabe que ele chegará na próxima semana, vai consertar ou não?

Construindo para a tempestade

Proteja desde o início. Aplique em runtime. Valide de forma independente.

Proteja o software desde o início, identificando o que o código gerado por IA introduz e quais pacotes ele incorpora antes que chegue perto de ser confirmado e distribuído, não depois.

Governe os agentes e suas cadeias de suprimentos, porque um agente com acesso excessivo e uma ferramenta não avaliada agora são uma superfície de ataque padrão, não uma exceção.

Teste e corrija continuamente, porque um pentest pontual não consegue acompanhar um cenário de ameaças que muda semanalmente. Testes ofensivos contínuos, fundamentados em evidências de produção, são a forma de comprovar que os controles especificados resistem aos caminhos de ataque que você realmente testou. Essa é uma afirmação mais restrita do que "estamos seguros" — e é a única que vale a pena fazer.

E valide de forma independente o que a IA constrói, a mesma disciplina para a qual o setor está convergindo em todas as camadas, aplicada a cada linha de código e a cada agente que suas equipes entregam.

Nada disso funciona se as descobertas simplesmente se acumularem. Jason Clinton, Deputy CISO da Anthropic, explicou bem a parte operacional quando anunciamos nossa parceria: "Na segurança de IA, a detecção nunca foi o gargalo. Ao combinar os recursos do Claude com a Snyk, as empresas podem transformar descobertas de alta fidelidade em ação dentro dos fluxos de trabalho nos quais o software é construído."

Abertos. Aliados. Ainda de pé.

A camada defensiva precisa continuar amplamente acessível. Modelos abertos, inteligência compartilhada e apoio aos mantenedores de código aberto fazem parte da arquitetura de segurança, não estão fora dela.

As etapas posteriores de Amodei pedem coordenação entre laboratórios de fronteira e, depois, entre governos. É uma proposta razoável, e não um plano para excluir ninguém. Minha preocupação diz respeito ao efeito, não à intenção: qualquer arranjo que acabe concentrando a capacidade de construir, inspecionar e defender sistemas de IA nas mãos de alguns poucos laboratórios se torna um ponto único de falha, independentemente do objetivo original. Resiliência que depende de confiar no roadmap de um único fornecedor não é resiliência. Avalie todas as soluções propostas, inclusive as nossas, pelo critério de ampliar ou não o conjunto de pessoas capazes de defender.

Parte disso antecede a IA. Durante quarenta anos, entregamos software sem nos submetermos à disciplina de segurança que outras áreas da engenharia tratam como inegociável. Adoramos criar, mas nunca gostamos muito de proteger aquilo que criamos. A IA não introduziu essa lacuna; ela removeu o tempo que vínhamos usando para escondê-la e, além disso, acrescentou novos riscos próprios.

Preparação é responsabilidade da liderança e começa pela parte que escolhemos.

Abertos. Aliados. Ainda de pé.

Em 17 de setembro, vou me reunir com Alon Krifcher, Head of Applied AI da Anthropic, para apresentar as quatro ações que fecham a lacuna entre ataque e defesa na velocidade das máquinas: descobrir, corrigir, validar e prevenir. Garanta seu lugar hoje.

Pergunte ao seu próprio agente

Se quiser transformar isso em uma conversa com sua própria equipe, entregue o texto a seguir ao seu agente. Ele não dirá se você está exposto — nenhum documento público pode fazer isso —, mas dirá o que perguntar.

Read https://www.anthropic.com/threat-intelligence-report-september-2026,
https://snyk.io/evo/, and https://snyk.io/blog/ai-hurricane-is-here/ as reference material only.
Do not run tests, scans, or commands against any system, and do not change
any configuration.

For each attack path described in the report:

1. Separate what is documented evidence, what is my assumption, and what
   is unknown.
2. Identify the controls that could block or reduce it. For each, say
   whether it acts on what an agent uses, what it does, or what it
   generates, or on what an already-deployed system is permitted to do.
3. State what internal evidence we would need to assess our own exposure,
   and who in the organization would hold it.

Then rank a list of questions for my security team by potential impact,
likely exposure, and the size of the evidence gap.

Public reports and product descriptions cannot establish our actual
posture. Return questions and evidence requests, not an assessment of
whether we are secure. Never print the value of any key, token, or
credential.