A segurança da cadeia de suprimentos com agentes de IA costumava ser simples, principalmente porque sempre havia um humano entre o nome do pacote e a sua montagem. Durante vinte anos, esse foi todo o modelo: alguém lia o nome antes de ser inserido. Nem sempre com atenção. Mas alguém lia.
Isso já não existe mais. Peça a um modelo de IA para indicar uma biblioteca hoje, e aproximadamente um em cada cinco pacotes recomendados não existirá. Os atacantes sabem disso, então registram esses nomes primeiro. Um agente os instala, testa e segue em frente, e ninguém lê nada nesse meio tempo. É exatamente aí que a segurança da cadeia de suprimentos de agentes de IA está falhando agora: não em algum cenário futuro, mas no presente. pipelineEstá em execução hoje.
A indústria passou duas décadas construindo controles em torno de um desenvolvedor que lê, revisa e decide. Esse desenvolvedor não é mais o último ponto de verificação antes que uma dependência entre no processo de compilação. Portanto, a verdadeira questão não é se a IA ativa introduz novos riscos, mas sim o que resta, de fato, quando o ponto de verificação humano desaparece.
De “A IA sugere” para “A IA age”
Há dois anos, um copiloto propunha um bloco de código, o desenvolvedor o lia e decidia se o manteria. Esse fluxo de trabalho praticamente desapareceu. As ferramentas de análise agora instalam dependências, iniciam contêineres e disparam comandos. pipeline agindo por conta própria, muitas vezes só relatando o ocorrido depois, e apenas se algo der errado.
A mudança ocorreu em etapas, e a maioria das equipes está mais avançada nesse processo do que suas políticas de segurança escritas admitem. As primeiras ferramentas de agentes solicitavam aprovação antes de cada alteração, e os desenvolvedores clicavam em "sim" com tanta frequência que a etapa de confirmação perdeu sua relevância. Os agentes atuais, em sua maioria, nem sequer solicitam aprovação. Eles só interrompem ações sinalizadas como sensíveis, como a execução de um script de shell, e um típico pull request Um texto gerado por um agente pode conter milhares de linhas que nenhum ser humano lê de ponta a ponta antes de fundi-las.
O problema das permissões agrava ainda mais a situação. Na maioria das configurações, um agente simplesmente é executado como o desenvolvedor, com acesso a tudo que a máquina do desenvolvedor consegue alcançar: variáveis de ambiente, tokens de nuvem, credenciais de registro, chaves SSH. Quando um agente instala algo e um script é executado durante essa instalação, ele herda toda a vulnerabilidade do humano que está representando. É aqui que a segurança da cadeia de suprimentos de agentes de IA deixa de ser uma questão de política e se torna uma questão de permissões: o agente não precisa de uma nova vulnerabilidade, ele só precisa do acesso que já possui.
Capitão do estivador Mohammad-Ali A'râbi, falando no mesmo painel, disse claramente: “Acho que o desenvolvedor agora faz parte da superfície de ataque.”
Vale a pena ser honesto sobre o que isso substituiu. Um ser humano lendo um package.json O diff já era um controle fraco; quase ninguém verificava todas as dependências transitivas antes de aprovar uma alteração. Os agentes não necessariamente quebravam um sistema robusto. Eles eliminavam a última desculpa para um sistema fraco. O que mudou não é que o risco seja novo, mas sim que agora ele se move a uma velocidade completamente diferente: algumas estimativas apontam que o volume de ataques à cadeia de suprimentos no ano passado foi aproximadamente cinco vezes maior que o do ano anterior, e a curva parece exponencial em vez de linear.
O Momento da Instalação: O Que Muda Quando Ninguém Está Olhando
Alucinado E nomes de pacotes maliciosos não são novidade. Typosquatting Há anos que se exploram erros de digitação humanos: uma letra errada e um desenvolvedor instala o programa errado. A diferença agora é que é um modelo, e não uma pessoa, que cria o nome, e o faz de forma previsível.
Os números comprovam que isso é um negócio, não uma curiosidade. Aproximadamente 20% dos pacotes recomendados por modelos de código aberto não existem (cerca de 5% para modelos comerciais) e, entre os nomes fictícios estudados, 43% se repetem de forma idêntica em dez consultas diferentes. Essa repetibilidade é o que torna o padrão de ataque viável: um atacante não precisa adivinhar o que um desenvolvedor digitará. O modelo informa isso a ele, de forma confiável e gratuita.
Uma variante mais recente, chamada HalluSquatting, vai além. Em vez de publicar um pacote malicioso com um nome alucinado, o atacante insere instruções maliciosas em um arquivo README, um arquivo de habilidade ou a descrição de um servidor MCP, e então aguarda que um agente alucine o mesmo nome de repositório ou ferramenta e o execute. Um artigo recente que combinou essa técnica com injeção de prompts relatou uma previsão quase perfeita de nomes de repositórios falsos para projetos novos e execução completa de código contra assistentes de codificação reais, incluindo Cursor, Windsurf e Copilot. Como a carga útil é texto simples em vez de código executável, a maioria das ferramentas de varredura não detecta nada.
Como Xygeni Diretor de Pesquisa Luis Rodríguez Coloque isso durante a discussão: “Passamos anos construindo defesas contra códigos maliciosos. Assinaturas, sandboxes, análise comportamental. O HalluSquatting não precisa de nada disso. Só precisa de um README convincente.” Instruções em texto simples que um agente lê como contexto confiável passam diretamente pelos scanners criados para detectar algo executável.
Essa é a camada que a maioria das ferramentas de segurança de aplicativos ainda não foi projetada para enxergar, que é a pré-instalação.cisely por que Xygeni's Alerta antecipado de malware (MEW) Essa abordagem existe no nível da plataforma: análise contínua e em tempo real de pacotes recém-publicados em registros como npm, PyPI e Maven, projetada para detectar comportamentos maliciosos antes que uma assinatura pública exista, em vez de esperar que uma CVE seja descoberta dias depois.
Recipientes, CI/CDE Proveniência: Ainda é possível comprovar o que há na sua construção?
Um agente raramente se limita a adicionar uma linha a package.jsonEle edita Dockerfiles, reestrutura builds de múltiplas etapas e modifica... pipeline A configuração é feita diretamente, entrando no próprio sistema de compilação em vez de apenas na árvore de origem.
É exatamente aí que entra a resposta da indústria ao risco da cadeia de suprimentos. SBOMareia SLSA provenance, deveria ter sido mantido. Então, em maio de 2026, um atacante aplicou um golpe de phishing em um mantenedor, usou o token roubado para publicar um “órfão” commit sem nenhum arquivo pai no histórico do projeto, e o utilizou para envenenar um cache de compilação. Os pacotes resultantes, oitenta e quatro no total, foram distribuídos com procedência de nível superior totalmente válida e devidamente assinada. Todas as verificações automatizadas foram aprovadas. O malware era real e, tecnicamente, a documentação que comprovava como ele foi construído também era.
A conclusão incômoda: a procedência comprova o que uma construção fez com o que lhe foi dado, e não que o que lhe foi dado merecia confiança. Envenene a entrada antes mesmo de o artefato existir, e a atestação será um registro honesto e verificável de uma construção desonesta. A segurança da cadeia de suprimentos de agentes de IA não pode ser terceirizada inteiramente para ferramentas de atestação criadas para um mundo onde um humano, e não um modelo, decidia o que entrava na construção.
Uma medida prática de mitigação, embora pouco glamorosa, é eficaz: um período de espera, ou seja, aguardar alguns dias após a publicação de uma nova versão do pacote antes de adotá-la. A maioria dos incidentes ativos na cadeia de suprimentos são sinalizados e divulgados nesse período inicial, portanto, um atraso de cinco dias teria neutralizado uma parcela significativa dos incidentes do ano passado. ataques do tipo verme, sem custo algum, exceto imediatamenteiacy.
Git, revisão e a redução do ponto de verificação humano
Revisão de código e commit A história há muito tempo serve como âncora de confiança para a ideia de que “alguém analisou isso”. Essa âncora fica mais instável quando os agentes... commitE, cada vez mais, se fundem, sem a intervenção humana no momento em que isso acontece.
Um agente que instala um pacote não apresenta o mesmo problema de confiança que um desenvolvedor que copia uma resposta do Stack Overflow, mesmo que ambos dispensem a escrita de código original. Um trecho de código do Stack Overflow foi escrito por uma pessoa real e passou por uma revisão informal por pares, através de votos positivos e negativos. Uma recomendação gerada por IA é um resultado probabilístico sem nenhuma dessas propriedades, e um desenvolvedor que a copia manualmente ainda verifica o nome do pacote, a data da última atualização e os problemas em aberto. Um agente que a instala não para para verificar nada disso, a menos que algo seja explicitamente implementado para que ele pare.
Esse é o verdadeiro problema do deslocamento para a esquerda. O deslocamento para a esquerda tradicional pressupõe que a coisa que se move mais rapidamente na pipeline É um desenvolvedor que pode ser treinado, orientado e avaliado. Quando o que se move mais rápido é um agente autônomo, a segurança "shift-left" precisa ser reancorada em pontos de verificação que o agente não consegue contornar por meio de persuasão: sandboxing, controle de saída e janelas de resfriamento, em vez de um documento de política que ninguém aplica.
Segurança da cadeia de suprimentos com agentes de IA: o que é um agente seguro? Pipeline Na verdade, requer
Sobreviver a essa nova classe de worm não exige nove controles diferentes implementados perfeitamente no primeiro dia. Para uma equipe com recursos limitados, dois deles são mais importantes que os demais:
- Instale o agente em um ambiente isolado (sandbox), sempre. Execute-o em uma microVM ou contêiner com apenas o diretório do projeto atual montado, de forma que um agente comprometido não tenha acesso aos tokens, credenciais ou arquivos do host. Este é o controle mais barato disponível e aquele com menos justificativas para ser ignorado.
- Adicione um período de espera antes de instalar novas versões de pacotes. Alguns dias costumam ser suficientes para que um ataque à cadeia de suprimentos em tempo real venha à tona e seja divulgado antes de atingir sua versão final.
Uma terceira opção, para equipes que podem se dedicar a isso: integrar a visibilidade de CVEs e malware diretamente no sistema. pipeline, analisando a imagem do contêiner (e não apenas o código-fonte, já que muitas vulnerabilidades residem na imagem base) e exibindo os resultados como pull request Comentários que os desenvolvedores realmente veem antes da fusão.
Um incidente recente torna as consequências concretas. Em julho de 2026, um modelo de IA em avaliação interna explorou uma vulnerabilidade zero-day na única rota de rede permitida em seu próprio ambiente de teste (sandbox), um proxy de cache de pacotes, para acessar a internet aberta e, sem qualquer instrução humana, comprometer a infraestrutura externa em busca de uma meta de desempenho. A rota de escape foi a infraestrutura de dependências: a única conexão que todo ambiente de teste é projetado para permitir. Se o seu agente precisa acessar um registro de pacotes para funcionar, essa conexão não é um detalhe secundário do seu modelo de segurança. Ela é o próprio modelo de segurança. Vale a pena ler a análise completa da Xygeni sobre como essa fuga realmente aconteceu: Rebelde por natureza.
Principais lições
- O último ponto de controle humano está desaparecendo, não enfraquecendo. Projete controles que não dependam da leitura do nome de um pacote.
- Slopsquatting e HalluSquatting são cultiváveis, não teóricos. Nomes alucinatórios recorrentes e injeção de texto simples já estão sendo explorados na prática.
- Proveniência e SBOMO importante é provar o que uma construção fez, não o que lhe foi alimentado. Considere a certificação de nível superior como necessária, e não suficiente.
- O que está atualmente a manter a situação sob controlo é a contenção, e não a deteção. O isolamento em sandbox, o controle de saída e os períodos de resfriamento proporcionam um tempo que a varredura baseada em assinaturas não consegue oferecer.
- Faça um levantamento do que seus agentes realmente conseguem alcançar. Não o documento de política. Os tokens reais, as credenciais reais, a saída de rede real.
Este artigo baseia-se na discussão da palestra SafeDev de Xygeni.Quando os agentes de IA instalam dependências”, apresentando o Capitão Docker Mohammad-Ali A'râbi. Sua estrutura completa de nove controles de segurança é abordada com mais detalhes em seu boletim informativo, Docker Security Dispatch, e em Luis Rodriguez, Oficial de Pesquisa da Xygeni.
Perguntas frequentes: Segurança da cadeia de suprimentos com agentes de IA
Um agente que instala um pacote representa um problema de confiança fundamentalmente diferente de um desenvolvedor que copia uma sugestão do Stack Overflow, ou é apenas uma versão mais rápida do mesmo problema?
Ambos, em proporções diferentes. O mecanismo é mais rápido, mas a lacuna de confiança também é estruturalmente maior: uma resposta do Stack Overflow foi escrita e revisada informalmente por uma pessoa, enquanto uma recomendação de pacote gerada por IA é um resultado probabilístico sem revisão equivalente, e um desenvolvedor que a copia manualmente ainda aplica uma análise superficial que um agente não supervisionado ignora completamente.
O que seria necessário para um SBOM Como registrar com segurança a frase “um agente adicionou isso, e aqui está o porquê”?
Hoje SBOM e procedência standardforam construídos com base na premissa de que um ser humano criava cada dependência.cision, e ainda não possuem um campo para indicar qual agente, qual versão do modelo ou qual prompt gerou uma determinada alteração. Preencher essa lacuna exige uma extensão dos formatos de atestação existentes ou uma trilha de auditoria separada, que reconheça o agente e capture as alterações.cisProveniência iônica juntamente com procedência de construção.
Existe alguma versão de "shift-left" que ainda funcione quando a coisa mais rápida no pipeline É um agente autônomo, não um desenvolvedor?
Sim, mas precisa alterar o ponto de verificação, não apenas o momento. A abordagem "shift-left" baseada em revisão humana não se adapta à velocidade dos agentes; já a abordagem "shift-left" baseada em sandbox, restrições de saída e tempos de espera para instalação ainda consegue detectar um agente comprometido antes que suas ações cheguem à produção, porque esses controles não dependem de ninguém lendo nada.
