A IA está ampliando sua superfície de ataque. Você está testando?

O mercado está inundado de promessas. Um fornecedor lidera um ranking. Outro capta centenas de milhões com uma apresentação. Enquanto isso, seus desenvolvedores lançaram três serviços gerados por IA antes do almoço. Esta é a conversa que o setor não está tendo — e para a qual estamos nos preparando há anos.

Neste momento, uma versão dessa conversa está acontecendo dentro de todas as equipes de segurança.

Alguém faz uma demonstração de um assistente de programação com IA. A velocidade é inegável, e a equipe fica impressionada. Ainda assim, mantém a cautela — às vezes, até o ceticismo.

O código que antes levava um sprint agora fica pronto em uma tarde. A liderança está muito empolgada. Os desenvolvedores que vão sobreviver a esta era também. E a segurança, se for sincera, não sabe ao certo se as ferramentas que tem estão preparadas para o que vem por aí.

Narrador: Não estão.

O benchmark sobre o qual ninguém quer falar

O BaxBench não é um relatório de ameaças; é uma medição. Ao avaliar código de back-end gerado por LLMs em tarefas do mundo real, pesquisadores constataram que 62% estava quebrado ou era inseguro. E, entre os trechos de código que funcionavam corretamente, cerca de metade ainda podia ser explorada.

Leia de novo: a IA escreve código funcional, mas metade dele ainda pode ser explorada.

Isso não é motivo para parar de usar assistentes de programação com IA; esse caminho já não tem volta. É um motivo para definir com precisão o que significa segurança em um mundo no qual a geração de código acelerou de forma permanente.

A análise estática no momento da criação — seja com uma ferramenta SAST na IDE, seja com orientações de segurança assistidas por IA durante o desenvolvimento — é um primeiro passo essencial, mas não é o ponto de chegada. Ela pode mostrar o que existe no código, mas não dizer se ele pode realmente ser explorado da forma como um agente malicioso faria. Mesmo as abordagens estáticas multimodais mais recentes, que combinam análise de taint com raciocínio de LLMs, só conseguem prever o que talvez possa ser explorado no código. Elas não comprovam o comportamento real em tempo de execução sob condições de ataque reais.

Para isso, você precisa sondar o sistema de fora, em tempo de execução — como faria um atacante de verdade.

A segunda superfície de ataque que ninguém mapeou

Enquanto o setor debatia a segurança do código gerado por IA, uma segunda superfície de ataque se formava discretamente.

Agentes de IA não operam isoladamente. Eles chamam APIs — muitas vezes privilegiadas e, com frequência, não documentadas. APIs criadas antes de alguém imaginar que seriam invocadas de forma autônoma e em grande escala. A Gartner prevê que, até 2028, os agentes de IA serão os principais consumidores de APIs corporativas. Até 2029, espera-se que mais de 50% dos ataques bem-sucedidos contra agentes de IA explorem falhas de controle de acesso (BOLA/IDOR), justamente uma classe de vulnerabilidade cuja validação sempre foi um desafio para a análise estática.

Isso não é uma previsão ousada; é uma descrição das decisões de arquitetura que sua organização já tomou.

O BodySnatcher tornou isso concreto. Com a CVE-2025-12420, um atacante sem autenticação precisava apenas do endereço de e-mail do alvo para se passar por administrador do ServiceNow, contornar MFA e SSO, executar fluxos de trabalho de agentes de IA e criar contas de backdoor com privilégios totais. Números de previdência social, registros financeiros, propriedade intelectual confidencial: tudo pronto para ser levado... Tudo exposto.

A técnica não era esotérica: não havia uma vulnerabilidade de dia zero nem uma injeção de prompt engenhosa. A vulnerabilidade estava ali, sem testes, por trás de um agente em que a organização confiava plenamente. A conclusão do pesquisador foi precisa: “Os agentes de IA ampliam significativamente o impacto de falhas de segurança tradicionais”.

A velocidade de entrega superou a capacidade de validação. A resposta não pode ser desacelerar. É preciso mudar fundamentalmente o que significa testar.

Não são falhas novas; são as mesmas falhas de sempre, que já eram difíceis de identificar, agora amplificadas pela nova arquitetura construída sobre elas.

Por que, na verdade, é uma única história

Na minha opinião, o que passa despercebido quando esses dois problemas são tratados separadamente é que ambos têm a mesma causa: a velocidade de entrega simplesmente superou por completo a capacidade de validação. Assistentes de programação com IA geram código mais rápido do que qualquer processo de segurança foi projetado para acompanhar, e agentes de IA chamam APIs mais rápido do que qualquer inventário foi projetado para rastrear. Nos dois casos, há algo em produção que nunca foi submetido a um ataque sistemático: não foi revisado nem analisado, mas *atacado* — da forma como um agente malicioso real faria.

É por isso que acreditamos que a resposta não pode ser desacelerar. É preciso mudar o que significa testar.

Os testes dinâmicos não são apenas um resquício da era pré-IA. São a disciplina que a era da IA realmente precisa. Em um mundo pós-IA, eles se tornam uma base — uma estrutura essencial.

A questão deixa de ser se você deve fazer testes dinâmicos. A questão é se esses testes são inteligentes o bastante e conseguem acompanhar o que está rodando em produção agora: código gerado por IA, na velocidade da IA, por trás de APIs que os agentes chamam mais rápido do que qualquer inventário feito por pessoas consegue rastrear.

Os testes dinâmicos modernos também precisam ser alimentados por IA: rápidos o bastante para acompanhar o pipeline, inteligentes o bastante para distinguir a possibilidade real de exploração do ruído e projetados especificamente para uma superfície de ataque que nem existia há dois anos.

Sinal, não ruído

Este é o verdadeiro problema do código gerado por IA em grande escala: ele não cria apenas mais código, mas também mais descobertas, mais alertas e mais coisas que parecem exigir atenção. Imagine tudo isso passando por ferramentas de segurança projetadas para um mundo muito mais lento.

Os desenvolvedores ficam soterrados por esse ruído e precisam decidir onde investir seu tempo. Na maioria das vezes, a decisão se baseia na intuição, na senioridade ou na pressão constante dos prazos.

A fadiga de alertas não é novidade, mas, na era da programação com IA, ela se acumula: os desenvolvedores já não estão revisando as descobertas de um único sprint, e sim um volume de código que levaria uma equipe um trimestre inteiro para escrever. Se todas as descobertas tiverem o mesmo peso, nada será corrigido — pelo menos não com confiança.

A equação começa a mudar quando você correlaciona as descobertas. Quando uma descoberta estática e uma dinâmica apontam para a mesma causa raiz — quando o código indica uma vulnerabilidade e os testes em tempo de execução comprovam que ela pode ser explorada —, você deixa de ter dois problemas para priorizar. Tem uma única correção, de alta confiança, em que os desenvolvedores realmente confiam.

O ruído diminui. O sinal fica mais nítido.

Essa precisão é mais importante na era da IA do que nunca. Uma taxa de falsos positivos de 0,08% não é apenas uma especificação de produto. É o que acontece quando a segurança deixa de ser um custo para os desenvolvedores e passa a acelerar o trabalho. A IA escreve o código, você comprova o que realmente está vulnerável e os desenvolvedores entregam mais rápido e com confiança, em vez de mais devagar e com ansiedade.

✔️ SAST com LLMs para identificar padrões de código gerado por IA e os riscos associados — na IDE, no pipeline, agora.

✔️ DAST inteligente que sonda ativamente aplicações e APIs em execução para confirmar a possibilidade real de exploração, especialmente em casos de BOLA, IDOR e falhas de autorização específicas de agentes.

✔️ Descobertas correlacionadas que conectam sinais estáticos à confirmação dinâmica: uma correção prioritária, não uma fila de triagem.

✔️ Descoberta de APIs que revela os endpoints chamados de forma autônoma pelos seus agentes de IA, inclusive os não documentados.

✔️ Cobertura contínua integrada ao pipeline de entrega, não apenas uma iniciativa trimestral.

O que são (ou deveriam ser) os testes de intrusão com IA

Hoje, muitos fornecedores estão adotando o rótulo “testes de intrusão com IA”. Para alguns, isso significa usar LLMs para criar payloads de ataque; para outros, gerar relatórios de descobertas com “agentes” (e nós também questionamos aqui o conceito de agência). Mas poucos se referem a algo muito mais interessante.

O que essa disciplina realmente exige — e o que a era da IA especificamente exige — é uma abordagem capaz de testar código gerado por IA em busca de falhas lógicas específicas de IA, rastrear as APIs chamadas pelos agentes (inclusive as não documentadas), correlacionar descobertas dinâmicas com o contexto e a inteligência do código para separar o sinal do ruído e fazer tudo isso continuamente, em vez de em uma avaliação pontual e desconectada.

Aliás, isso não deveria ser uma lista de recursos nem um roadmap: deveria ser o padrão. E o setor ainda não conseguiu expressá-lo com clareza. É justamente por isso que este é o momento de fazer isso. E é o que vamos fazer.

Estamos trabalhando para chegar a esse padrão há anos, e os resultados que vemos nos ambientes de produção dos nossos clientes continuam validando essa abordagem.

Os verdadeiros testes de segurança para a era da IA não se limitam a encontrar mais problemas com mais rapidez. Eles correlacionam previsões estáticas com comprovações dinâmicas e oferecem correções que os desenvolvedores podem implementar com confiança, não com ansiedade.

O debate sobre segurança de IA tem sido dominado por duas perguntas consideradas distintas: podemos proteger os modelos de IA? E podemos usar IA para encontrar vulnerabilidades? Ambas são legítimas, mas nenhuma, isoladamente, é suficiente.

A pergunta mais urgente é mais simples: quem está testando ou atacando o código e as APIs que a IA cria e coloca em execução?

Se a resposta não for você, pode ter certeza de que será outra pessoa — ou alguma OUTRA COISA.