O invasor nunca dorme. Seus testes também não podem parar

Há alguns meses, escrevi que a IA está ampliando sua superfície de ataque mais rápido do que você consegue testá-la. Continuo concordando com cada palavra que escrevi. Mas, nos meses que se passaram, depois de mais de cem conversas com CISOs, CIOs e CTOs de quase todos os setores e regiões, vi o cenário ficar mais claro — e muito mais urgente. A superfície de ataque era só metade da história, porque o perfil dos invasores também mudou.

Começo com as boas notícias, porque são muitas. Estamos vivendo uma era de abundância de software. Hoje, os laboratórios de ponta estimam em trilhões de dólares o mercado de código escrito por IA e, juntos, lançaremos mais software neste ano do que em qualquer outro da história. O que antes levava um trimestre agora leva uma tarde. Essa transformação é real, extraordinária e irreversível.

Mas, por trás dessa abundância, há uma lacuna que quase ninguém está levando em conta: a lacuna de confiança. Agora conseguimos gerar software mais rápido do que conseguimos confiar nele, e a mesma capacidade de raciocínio que criou essa abundância acaba de chegar às mãos de quem tenta explorá-la.

O invasor que nunca dorme

Esta é a mudança que passou a ocupar o topo da minha lista — e é o que ouço primeiro dos líderes hoje. Por vinte anos, nosso adversário foi, em última instância, humano, limitado pelo tempo, pela atenção e pelos custos humanos. Essa limitação desapareceu. Quando um laboratório de ponta lança um modelo capaz de atuar em cibersegurança e com raciocínio avançado, o segundo já tem um modelo semelhante em poucos meses, e versões abertas equivalentes não demoram a aparecer.

Em junho, os chefes de inteligência dos Five Eyes disseram o que muitos evitavam dizer: a IA de ponta vai transformar o ataque e a defesa cibernéticos em meses, não anos, e as organizações precisam agir agora. Em novembro passado, a Anthropic revelou que um grupo patrocinado por um Estado usou seus modelos para conduzir, segundo estimativas, de 80% a 90% de uma campanha de espionagem ativa contra cerca de trinta alvos. Operadores humanos intervieram em apenas alguns pontos de decisão. Parte dessas invasões teve sucesso. Agora, o adversário é um invasor que nunca dorme. Ele analisa seus aplicativos na velocidade das máquinas, seguindo um ritmo que nenhuma equipe de defesa preparada para o mundo antigo consegue acompanhar. O prazo para agir já não se mede em ciclos orçamentários.

Imagine uma torre de Jenga

Quando tento explicar isso de forma concreta para um conselho, recorro a uma torre de Jenga: riscos empilhados em camadas, cada uma deixando a estrutura toda mais instável.

A camada de baixo: os riscos que você já conhece, agora armados

Todo programa de segurança já criado aceitou, sem alarde, um acordo: corrigir os problemas de alta gravidade e os críticos, deixando os demais para depois, porque explorar uma combinação de falhas menores até provocar uma invasão real era difícil e lento demais para valer a pena para um invasor humano. Você protegia a porta da frente e a dos fundos e se convencia de que ninguém levaria uma escada até a claraboia. Bem, agora o invasor tem um drone para chegar até ela.

Toda a lista de pendências está em jogo, e os dados dos nossos clientes mostram que ela praticamente dobra à medida que a IA acelera o desenvolvimento. Com a velocidade crescente dos agentes, não se trata de um pouco mais de código: são ordens de grandeza a mais e, com isso, um número exponencialmente maior de vulnerabilidades. Os agentes ainda não são tão bons quanto um engenheiro humano de alto nível (eu diria que essa é a verdadeira definição de AGI). No dia em que forem — e, até lá, como disse Jen Easterly —, nosso problema não será tanto de cibersegurança, mas de qualidade de software. A IA simplesmente ampliou esse problema enormemente.

A camada do meio: uma nova classe de riscos criada pela forma como os agentes constroem

Os agentes não usam a cadeia de suprimentos humana: eles recorrem a servidores MCP, skills e ferramentas próprias. Nossa pesquisa sobre esse ecossistema revelou uma classe totalmente nova de falhas. Nós as chamamos de fluxos tóxicos, e são graves o bastante para levar à retirada de um servidor MCP amplamente usado em algumas das maiores empresas do mundo. E o malware aqui não se parece com o convencional: pode ser apenas três linhas em inglês simples na descrição de uma ferramenta, instruindo discretamente um agente a fazer algo destrutivo. Não dá para identificar intenções apenas comparando padrões.

Além disso, os próprios agentes são não determinísticos: dê um objetivo a um deles e ele agirá como alguém incansável na busca por metas, contornando qualquer controle entre ele e seu objetivo. Já vimos agentes fazerem cópias privadas de dados confidenciais em silêncio, “por precaução”. Esse comportamento precisa ser controlado, orientado para permanecer dentro dos limites definidos — e não deixado à deriva.

A camada de cima: todas as empresas estão se tornando empresas agentivas

A IA está transformando o software, assim como o software transformou o mundo. Isso significa que, mais cedo ou mais tarde, todo processo empresarial será executado por um agente criado por alguém. A segurança desse agente se torna uma questão prioritária. A maioria das organizações tem muito menos visibilidade sobre isso do que imagina: já me reuni com grandes empresas convencidas de que usavam cinco modelos aprovados, mas que, ao ativar o Discovery, encontraram mais de cinquenta.

Modelos são apenas código que alguém copia, cola e executa localmente — e, de repente, está em produção. E, quando um agente se torna a porta de entrada de fato, os cenários de falha ficam bem concretos. Por exemplo, um bot de atendimento ao cliente que pode ser convencido a revelar algo que não deveria. (Confesso que já convenci um a ignorar as próprias instruções, só por impaciência em um dia de viagem. Funcionou de primeira. Você quer que essa seja a interface do seu negócio?)

A raposa não pode tomar conta do galinheiro

Há uma história que alguns fornecedores de modelos contam e que preciso contestar: a mesma IA que gera todo esse código e comportamento também vai protegê-los. Ela corrigiria a própria prova. Não seria conveniente se o auditor e o contador fossem a mesma pessoa?

Todo profissional de segurança sabe por que isso não funciona, então vou dizer sem rodeios: quem gera não pode validar. Um modelo encarregado de encontrar e certificar as próprias falhas tem um conflito de interesses estrutural e, quando tenta fazer isso, seu comportamento é inconsistente. Execute-o cinco vezes contra o mesmo alvo e as descobertas vão coincidir, talvez, em metade dos casos. Não dá para conduzir um programa de segurança assim.

Os laboratórios não são os vilões: seus modelos são realmente úteis e, quando bem usados, encontram problemas que as ferramentas tradicionais não detectam. Mas eles também criam a maioria dos problemas, então não podem ser os únicos a julgá-los. É preciso haver independência. (Meu colega Nuno Loureiro escreveu o texto técnico definitivo sobre o assunto: primeiro, por que o código gerado por IA exige testes dinâmicos ofensivos e, depois, a origem da segurança ofensiva contínua. Os dois valem muito a pena.)

O medo é real, mas a esperança também

Não quero deixar você apenas com a imagem da torre, porque a parte esperançosa dessa história é igualmente real — e é nela que o trabalho acontece. Há uma medida para cada camada, e você já pode colocá-la nas mãos de um engenheiro de segurança.

• Zere a lista de pendências: A lógica antiga de priorização não resiste a um invasor que combina problemas de baixa gravidade que você deixou para depois. Parece impossível até você deixar a IA cuidar das correções. Hoje, alguns dos nossos clientes, entre as maiores empresas do mundo, operam sem pendências porque os agentes corrigem os problemas, em vez de apenas encontrá-los.

• Use IA para encontrar o que as ferramentas determinísticas não encontram... com cautela: Modelos de raciocínio realmente revelam problemas que passam despercebidos pelos scanners. Como complemento, com validação independente, eles oferecem uma vantagem real. Usados sem questionamento, geram ruído. Estamos incorporando aos nossos produtos o acesso a modelos próprios para a defesa, para que as equipes aproveitem os benefícios sem depender de um resultado incerto.

• Teste como o invasor testaria: Se seu adversário vai sondar seus sistemas de forma autônoma com um modelo de raciocínio avançado, a única resposta honesta é executar continuamente, antes dele, uma versão própria para a defesa, exatamente desse tipo, contra seus aplicativos e dentro do seu ambiente. O modelo antigo não dá conta: um pentest tradicional cobre cerca de quinze dias por ano e deixa os outros trezentos e cinquenta sem cobertura, enquanto o aplicativo recebe mais três versões durante a elaboração do relatório.

• Evite as próximas cem falhas: Corrigir sem parar é um ciclo sem saída se você nunca fecha a torneira. Nosso verdadeiro superpoder não é dizer a um desenvolvedor “aqui está um problema” depois que ele acontece; é dizer ao agente, antes mesmo de concluir a tarefa: “Não, esse código é inseguro, esse pacote é problemático. Corrija.” Em outras palavras: proteja desde o início.

• Inclua tudo isso em uma estrutura de governança: Descubra cada componente agentivo em execução, identifique o risco real de cada um, aplique políticas — inclusive sobre quais modelos podem ser usados em cada caso — e faça red teaming dos aplicativos nativos de IA que você lança, porque eles se comportam de forma diferente de qualquer software que já protegemos.

• Proteja o artefato. Proteja a força de trabalho. Proteja o negócio: Um ciclo para cada problema, coordenado para que uma pessoa possa manter o controle sobre o processo, sem se afogar nele, porque, nessa escala, não dá para acompanhar tudo de perto. E um ciclo só se fecha quando uma entidade independente ataca o que você lançou e comprova que ele resiste. Encontrar, corrigir e governar são a defesa; a segurança ofensiva contínua é a comprovação. Você não pode afirmar com sinceridade que está preparado para ataques automatizados, nem que é seguro colocar um agente diante dos seus clientes, até que algo o tenha atacado da forma como o adversário atacaria. Essa é a visão por trás de Evo — e é isso que estamos construindo.

Dois problemas que não vou ignorar

Há mais duas questões que me preocupam e que, na minha opinião, precisam fazer parte desta conversa, ainda que sejam maiores do que qualquer fornecedor isolado.

Problema 1: concentração e escolha

O excesso de poder concentrado em poucos modelos é um risco por si só — para a resiliência, a soberania e, mais recentemente, os custos, que quase da noite para o dia se tornaram um tema para os conselhos. As organizações não deveriam ter que escolher às cegas. Precisam de validadores independentes capazes de dizer quais modelos são seguros para cada tarefa, porque raramente a resposta é simplesmente sim ou não. Alguns modelos abertos amplamente disponíveis seguem suas regras à risca, mas não devem ser usados com dados confidenciais. Só é possível saber disso quando alguém faz red teaming para você.

Por isso, a Snyk é agora signatária e apoia publicamente a Carta sobre Pesos Abertos e Liderança Americana em IA, junto com outras 270 empresas, incluindo Microsoft, Nvidia e CrowdStrike.

Problema 2: código aberto

O código aberto é o combustível da economia moderna. A maior parte do software é de código aberto, e esse ecossistema está sob uma pressão que poucos estão reconhecendo. Na minha avaliação do setor, dezenas de milhares de vulnerabilidades ainda não divulgadas já estão nas mãos de grupos bem financiados, que as encontraram ao testar discretamente esses novos recursos em projetos de código aberto. É o problema de invasores que já usam agentes contra um bem comum. Os mantenedores estão soterrados por uma mistura de relatos legítimos e conteúdo medíocre gerado por IA, sem conseguir acompanhar. É assim que um bem comum desmorona sob o próprio peso — e seria uma catástrofe. Por isso, oferecemos nossa plataforma gratuitamente a mantenedores da comunidade de código aberto, embora acreditemos que essa seja apenas uma pequena parcela da responsabilidade muito maior que todo o setor compartilha.

É também por isso que a Snyk está se unindo à Nvidia e a outros líderes de tecnologia na Open Secure AI Alliance.

Quem está testando o que a IA constrói?

Concluí meu último artigo com uma pergunta, que agora está ainda mais urgente: quem está testando — na verdade, atacando — o código e os agentes que a IA está criando e executando em seu nome? Para a maioria das organizações, hoje, a resposta sincera é... ninguém. Essa é a lacuna de confiança que vemos. A boa notícia é que a resposta pode ser você: com sua própria IA, direcionada para o que importa, com independência incorporada e uma pessoa no processo. O atacante não dorme. Seus testes também não podem parar. Mas, pela primeira vez, não precisam parar.

Manoj Nair é diretor de Tecnologia e Inovação da Snyk.