TL, DR
O que a ENISE 2026 nos ensinou sobre segurança de agentes de codificação de IA
A IA já escreve seu código. Decidir o que chegará à produção ainda depende de você.
- Uma frase foi suficiente: Uma mensagem oculta no título de uma issue do GitHub levou um agente de triagem de IA a iniciar uma cadeia que terminou em um liberação não autorizada de Cline, um assistente de programação com mais de cinco milhões de usuários.
- Não houve envolvimento de CVE: O ataque explorou cinco controles ausentes, o que não configura uma vulnerabilidade clássica, portanto os scanners tradicionais não detectaram nada.
- O gargalo mudou de lugar: A IA escreve código e encontra vulnerabilidades rapidamente. Integrar o código com segurança e validar quais descobertas são reais é a parte difícil agora.
- Os agentes de codificação fazem parte da sua cadeia de suprimentos: Os atacantes visam qualquer pessoa que escreva seu código: nomes de pacotes inventados, dependências corrompidas, até mesmo os assistentes de IA no laptop do desenvolvedor.
O primeiro passo: Responda a quatro perguntas. Quais agentes atuam no seu empreendimento, o que eles podem agregar, qual é o seu pipelines pode executar e quais descobertas você pode realmente validar.
Na ENISE 2026 em León, nosso CEO, Jesús Cuadrado, iniciou sua palestra sobre segurança de agentes de codificação de IA com uma história, e não com um slide de estatísticas. Aqui está o que ele contou à plateia e as quatro perguntas que ele deixou para cada participante. CISO com.
Uma frase bastava
No início deste ano, um pesquisador de segurança demonstrou que era possível publicar uma versão falsa de um assistente de programação usado por milhões de desenvolvedores sem explorar nenhuma vulnerabilidade, sem usar uma chave de dia zero e sem que a senha fosse roubada. Tudo o que foi necessário foi uma frase no título de uma issue no GitHub.
A ferramenta era o Cline, um popular assistente de programação de código aberto. Como muitos projetos atuais, sua equipe havia automatizado parte do trabalho com IA: um agente lia cada nova issue do GitHub, classificava-a e respondia. Para realizar sua tarefa, esse agente tinha acesso ao terminal e era executado em issues abertas por qualquer pessoa na internet. O pesquisador Adnan Khan nomeou a cadeia de ataque de “Clinejection”, e Simon Willison a descreveu. Um resumo claro de como funcionava.
A corrente se rompeu em cinco lugares:
- O texto externo tornou-se instruções. O título do problema foi exibido diretamente no prompt do agente, de modo que uma solicitação para instalar uma ferramenta foi interpretada como um comando.
- O agente tinha mais poder do que precisava. Estava lá para triar problemas, mas também podia executar comandos, e assim o fazia.
- Triagem e liberação compartilhavam um cache. A ferramenta instalada contaminou o cache de CI, e o fluxo de trabalho de lançamento herdou esse problema.
- As versões utilizavam um token de longa duração. Com o cache corrompido, o token de publicação do npm estava ao alcance.
- Ninguém aprovou a divulgação. Nada exigia que um humano verificasse uma versão antes de ela ser enviada.
Semanas depois, alguém explorou a vulnerabilidade de verdade e publicou uma versão não autorizada, cline@2.3.0. Ela permaneceu online por cerca de oito horas e foi instalada aproximadamente quatro mil vezes. Desta vez, o payload instalou apenas outro agente de IA. Poderia ter sido um ladrão de credenciais ou um ransomware.
Repare no que não estava lá: nenhuma injeção de SQL, nenhuma CVE, nada que um scanner tradicional detectaria. Então, quem decidiu que essa versão poderia ser lançada?
Ninguém.
Cinco controles ausentes e o que fecha cada um deles.
Cada elo na cadeia de Clinejection era um controle inexistente. Nenhum deles exigia uma CVE para ser explorado.
| Elo na corrente | O que estava faltando | O controle que o fecha |
|---|---|---|
| 1. Título da edição | O texto não confiável foi diretamente para a caixa de entrada do agente. | Trate todas as entradas externas como não confiáveis e mantenha-as fora das instruções do agente. |
| 2. Agente de triagem | Um agente de triagem poderia executar qualquer comando. | Privilégio mínimo: conceda a cada agente apenas as ferramentas necessárias para a sua tarefa. |
| 3. Cache compartilhado | Os fluxos de trabalho de triagem e liberação usavam a mesma chave de cache. | Isolar fluxos de trabalho e revisar pipeline configuração como código |
| 4. token npm | Os lançamentos dependiam de um token de publicação de longa duração. | Credenciais de curta duração e com escopo definido para publicação |
| 5. Lançamento | Sem aprovação ou verificação humana antes da publicação. | Aprovação e comprovação de origem assinadas são necessárias para cada lançamento. |
Escrever código deixou de ser o gargalo.
Cline não é um caso isolado. É uma prévia. Agentes de codificação de IA agora escrevem, instalam e commit O código é codificado em um ritmo para o qual nenhum processo de revisão foi projetado, e até mesmo os laboratórios de IA relatam integrar mudanças mais rapidamente do que suas próprias ferramentas conseguem processar.
O gargalo mudou de lugar. Escrever código é barato. Integrá-lo com segurança, não.
Encontrar vulnerabilidades é barato. Saber quais delas são reais, não.
A IA também é muito boa em encontrar vulnerabilidades. O que ela não consegue fazer sozinha é dizer quais delas são reais.
Os responsáveis pela manutenção do curl, a biblioteca que roda em bilhões de dispositivos, tornaram isso dolorosamente visível. A maioria dos relatórios de segurança que recebiam não se tratava de vulnerabilidades reais, mas cada um deles ocupava membros de uma pequena equipe de voluntários por horas. Em janeiro de 2026, O curl encerrou seu programa de recompensas por bugs., citando a enxurrada de relatórios de baixa qualidade gerados por IA.
A mesma capacidade, a descoberta impulsionada por IA, pode produzir centenas de resultados reais ou uma avalanche de ruído. A diferença reside em quem os valida e quanto isso custa.
Seu agente de codificação agora faz parte da sua cadeia de suprimentos.
Os atacantes chegaram à seguinte conclusão lógica: se os agentes escrevem o código, por que atacar o código? Ataque quem o escreveu.
- Agachamento desleixado. Pesquisas sobre código gerado por IA descobriram que os modelos frequentemente recomendam pacotes que não existem, muitas vezes repetindo os mesmos nomes inventados. Um atacante só precisa registrar um deles e esperar.
- Assistentes de IA se voltaram contra seus donos. No ataque s1ngularity à popular ferramenta de compilação Nx, o malware procurou por assistentes de programação com IA na máquina do desenvolvedor e pediu que eles encontrassem segredos: arquivos .env, chaves SSH, tokens de nuvem. A própria IA da vítima realizou o trabalho do atacante.
A superfície de ataque não se limita mais apenas ao seu código. Ela engloba tudo que escreve código para você. Muitos desses riscos agora estão mapeados no OWASP Top 10 para candidaturas a mestrado em Direito (LLM) e no OWASP Top 10 para Aplicações Agentes, que explicamos em nosso guia para o OWASP Agentic AI Top 10.
Segurança de agentes de codificação de IA: quatro perguntas essenciais CISO deveria ser capaz de responder
Jesús transformou tudo isso em quatro perguntas. Tente respondê-las para a sua própria organização:
- Quais agentes e modelos estão atuando em nosso desenvolvimento atualmente? Não aqueles que você aprovou: aqueles que já estão disponíveis. Assistentes de IDE, bots do GitHub, agentes que alguém configurou para economizar tempo.
- O que eles podem trazer para o nosso software? Pacotes inventados, dependências de isca, extensões de IDE, Servidores MCP, modelos baixados de qualquer lugar.
- O que nosso pipelineExecutar, e com quais permissões? Em Cline, um cache compartilhado foi suficiente para acessar o token de publicação.
- De tudo o que nos dizem, quais conclusões podemos de fato validar?
A quarta questão é mais importante do que parece: você não pode confiar no resumo que o próprio agente faz sobre o que realizou. Você precisa de evidências independentes.
Como Xygeni responde a essas perguntas?
Veja o que tem lá. Segurança de IA da Xygeni Cria um inventário dos modelos, agentes, servidores MCP e ferramentas de codificação de IA em seus repositórios, com os riscos mapeados para o OWASP Top 10 para aplicações LLM. Você não pode governar o que não sabe que existe.
Impeça a entrada do que não deve ocorrer. Alerta antecipado de malware Detecta pacotes maliciosos antes mesmo de existir uma assinatura e está incluído no nosso plano gratuito. Xygeni Shield Bloqueia pacotes maliciosos em estações de trabalho de desenvolvedores antes que sejam instalados e impõe uma idade mínima para pacotes, extensões de IDE e plugins, fechando a janela de oportunidade da qual esses ataques dependem.
Proteja o pipeline. CI/CD verificações de segurança em fluxos de trabalho, permissões e segredos, e Build Security acrescenta assinado SLSA atestados, para que você possa provar que o que publicou é o que construiu. Foi exatamente isso que falhou no caso Cline.
Valide com evidências, não com opiniões. É aqui que a IA mais promete e mais frequentemente falha. Um resultado que muda a cada execução não pode servir como prova para um auditor nem como critério de seleção em um processo de auditoria. pipelineNa Xygeni, a IA não decide. No Pentesting com IA, um LLM planeja o ataque da mesma forma que um pentester faria, mas um oráculo determinístico decide se ele funcionou, com base em um sinal real e seguro. Cada veredicto é explorável, não explorável ou inconclusivo, e cada um vem acompanhado de uma prova de conceito que pode ser executada novamente e apresentada ao seu auditor ou conselho.
A IA propõe. Um mecanismo determinístico decide. Você fica com as evidências.
O decision ainda é seu
Jesús encerrou onde começou. Uma versão do Cline foi lançada sem autorização de ninguém, não por negligência da equipe, mas porque ninguém fez as perguntas certas a tempo. É nisso que se resume a segurança de agentes de programação com IA: fazer essas perguntas antes que um agente lance algo para você.
A IA já escreve seu código. Decidir o que chegará à produção ainda depende de você.
Então, qual das quatro perguntas você não consegue responder hoje?
Passamos três dias no estande 62 conversando com equipes de segurança e desenvolvimento exatamente sobre essas questões. Agradecemos a todos que nos visitaram.
A equipe Xygeni na ENISE 2026, da esquerda para a direita: Praça Jesus, Marcos Martin, e Agustín Sánchez Fonseca.
Quer ver como a Xygeni responde a essas perguntas no seu ambiente? Comece de graça or Agenda uma Demonstração.
Perguntas Frequentes
O que é segurança de agentes de codificação de IA?
A segurança de agentes de codificação de IA é a prática de controlar o que assistentes e agentes de codificação de IA podem ver, instalar, executar e publicar no seu ciclo de vida de desenvolvimento de software. Abrange os próprios agentes, os componentes que eles trazem, o pipelinepois podem desencadear eventos e as evidências necessárias para confiar em seus resultados.
O que foi o ataque Clinejection?
Clinejection foi uma cadeia de ataques contra o repositório Cline, na qual um prompt oculto no título de uma issue do GitHub enganou um agente de triagem de IA, fazendo-o executar comandos. Através de envenenamento de cache, o atacante obteve acesso a um token de publicação do npm e lançou uma versão não autorizada do Cline, que foi instalada cerca de quatro mil vezes.
O que é slopsquatting?
Slopsquatting é um ataque à cadeia de suprimentos no qual um invasor registra nomes de pacotes que modelos de IA tendem a inventar. Quando um desenvolvedor ou agente de codificação instala o pacote falso, ele recebe o código do invasor em vez do pacote falso.
A IA consegue validar descobertas de segurança por conta própria?
Não de forma confiável. A IA pode encontrar e explicar vulnerabilidades, mas seus resultados podem variar entre execuções, o que a torna uma evidência frágil. Uma abordagem mais segura é deixar a IA propor soluções e um mecanismo determinístico decidir, de modo que a mesma entrada sempre produza o mesmo resultado verificável.
