Seus modelos de IA são código executável. A maioria das empresas os trata como planilhas.
A primeira vez que realmente entendi o problema, eu estava observando um rastreamento de syscalls rolar na tela em um contêiner isolado e esperando que ele não fizesse nada.
Tínhamos baixado um modelo de um registro público — do tipo que um cientista de dados baixa cem vezes por trimestre sem pensar duas vezes. O model card parecia normal. Tinha passado por uma varredura básica. Eu o havia carregado em um sandbox não porque desconfiasse daquele arquivo específico, mas porque eu tinha começado a carregar tudo em um sandbox. E, enquanto a desserialização rodava, o rastreamento mostrou o processo tentando abrir uma conexão de rede que não tinha motivo algum para abrir.
Essa é toda a tese da segurança da cadeia de suprimentos de IA em um único momento: seus modelos não são arquivos de dados. São código executável que roda no instante em que você os carrega. A maioria das organizações os trata como planilhas — coisas inertes que você baixa e abre — e essa lacuna entre o que um modelo é e como ele é tratado é exatamente onde as brechas acontecem.
Um modelo não é um documento que você abre. É um programa que você executa com os privilégios de quem o executou.
A história do reverse shell nem sequer é lenda hipotética do setor. Descobriu-se que um modelo chamado "baller423" no Hugging Face estabelecia um reverse shell para um host externo. Parecia normal. Passou por varreduras básicas. Executou código arbitrário no momento em que alguém o carregou. Quando conto essa história para uma sala cheia de líderes de segurança, o desconforto não é que algo assim seja possível — é que eles percebem que sua equipe vem carregando modelos da mesma fonte, da mesma maneira, há dois anos.
O problema do pickle sobre o qual ninguém quer ouvir falar
Aqui está a parte que faz engenheiros experientes estremecerem, porque não é um bug que alguém possa corrigir com um patch.
Quando você chama torch.load() em um modelo PyTorch, ele pode executar Python arbitrário durante a desserialização. Isso não é uma vulnerabilidade no sentido usual. É o comportamento projetado do formato de serialização pickle do Python — o pickle tem permissão para reconstruir objetos executando código, e um arquivo de modelo é apenas um objeto serializado com pickle. Mais de 80% dos modelos de machine learning em circulação usam esse formato. Então a maneira padrão como todo o setor distribui modelos é também uma primitiva de execução remota de código esperando que alguém a preencha.
O instinto, compreensivelmente, é fazer uma varredura em busca disso. A defesa mais amplamente implantada é uma ferramenta chamada PickleScan, que procura padrões sabidamente maliciosos dentro dos arquivos de modelo. E o PickleScan tem pelo menos três bypasses zero-day conhecidos — o CVE-2025-10155 entre eles —, com pesquisadores da Sonatype encontrando depois mais quatro vulnerabilidades no próprio scanner.
Não digo isso para desmerecer um projeto de código aberto que faz um trabalho de verdade. Digo porque isso me ensinou um princípio em torno do qual hoje construo tudo: quando o atacante controla o formato do arquivo, a varredura por lista de bloqueio está estruturalmente perdendo. A varredura estática pergunta "este arquivo contém um padrão que eu já sei que é malicioso?" O atacante, que enxerga a mesma lista de bloqueio que você, simplesmente usa um padrão que você ainda não conhece.
Então paramos de fazer essa pergunta. Os pipelines de avaliação que minha equipe constrói não começam por "quais strings sabidamente maliciosas estão neste arquivo". Eles começam pelo sandboxing comportamental: carregar o modelo em um contêiner isolado, observar o que ele realmente faz — as syscalls, as tentativas de rede, as gravações em arquivo — e julgar o comportamento, não a assinatura. A pergunta muda de "isto está em uma lista" para "o que este código faz quando é executado". Essa segunda pergunta é a única que captura o ataque que ninguém nomeou ainda.
A varredura estática captura o ataque de ontem. O sandboxing comportamental captura aquele que o atacante está escrevendo agora mesmo.
Não é gratuito, e não é um produto que você compra pronto na prateleira. A Protect AI, agora parte da Palo Alto Networks após uma aquisição de cerca de US$ 500–700 milhões concluída em julho de 2025, varreu 4,47 milhões de versões de modelos e encontrou 352.000 problemas inseguros ou suspeitos em mais de 51.700 modelos. Essa é a dimensão do palheiro. As ferramentas conseguem sinalizar o óbvio. Arquitetar o portão que fica entre um registro público e o seu repositório interno de modelos — e torná-lo rápido o suficiente para que ninguém o contorne — é a parte que não vem em uma caixa.
O portão que construí e que todo mundo ignorou
Quero contar a você sobre a versão disso em que errei, porque o fracasso me ensinou mais do que o sucesso.
No início, construí para um cliente um portão de avaliação de modelos que era, tecnicamente, excelente. Todo modelo que chegava de uma fonte pública era puxado para o sandbox, analisado a fundo em vários formatos, perfilado comportamentalmente e só então assinado e admitido no registro interno. Em uma revisão de segurança, teria pontuado lindamente. Eu tinha orgulho dele.
Em cerca de uma semana, a equipe de ciência de dados havia parado silenciosamente de usá-lo.
Não por má-fé. Tinham prazos. O portão acrescentava minutos reais a um fluxo de trabalho em que a alternativa — baixar um modelo diretamente do Hugging Face — levava trinta segundos. Então, quando um experimento precisava de um modelo agora, eles o baixavam cru para uma conta de nuvem pessoal e seguiam em frente. Meu belo portão protegia uma porta vazia enquanto o tráfego real dava a volta pela lateral do prédio.
Aquela semana reformulou todo o problema para mim. O controle mais difícil na segurança da cadeia de suprimentos de IA não é técnico. É que um portão de segurança mais lento do que o caminho inseguro vai perder todas as vezes. Quando um cientista de dados consegue baixar um modelo em trinta segundos, qualquer processo que leve trinta minutos é contornado — não por agentes mal-intencionados, mas por bons engenheiros sob pressão. Os controles precisam ser rápidos o suficiente para que a conformidade seja mais fácil do que a burla. Se não forem, você não tem um programa de segurança. Você tem um teatro de segurança com ótimas avaliações e nenhuma plateia.
É por isso que os números sobre shadow AI nunca me surpreenderam depois daquilo. 98% das organizações têm funcionários usando ferramentas de IA não autorizadas. 62% dos profissionais de segurança dizem não ter uma forma confiável de saber onde os grandes modelos de linguagem sequer estão rodando em seu ambiente. Apenas cerca de 9% das empresas têm um sistema de governança de IA que funciona, embora um terço dos executivos vá lhe dizer que possui rastreamento abrangente. E o custo não é abstrato: o relatório Cost of a Data Breach de 2025 da IBM estima a brecha média relacionada a shadow AI em US$ 4,63 milhões — cerca de US$ 670.000 a mais do que um incidente padrão.
Você não pode proteger o que não consegue enxergar, e, neste momento, a maioria das organizações não consegue enxergar a maior parte de sua IA.
Por que o fine-tuning desarma silenciosamente o seu modelo mais seguro?
Esse é o que provoca a reação mais forte quando o apresento a uma equipe técnica, porque contradiz algo que todos assumem.
A suposição é: avaliei a segurança deste modelo, ele passou, então é seguro. A realidade é que o alinhamento de segurança é frágil de uma forma que o cronograma de avaliação ignora por completo. Em um estudo, a resiliência do Llama 3.1 8B à injeção de prompt caiu de uma pontuação de 0,95 para 0,15 após uma única rodada de fine-tuning — e não um fine-tuning adversarial. Treinamento normal, benigno, específico de domínio. Isso representa um colapso de cerca de 84% em uma propriedade de segurança, causado pela coisa mais comum que uma empresa faz com um modelo.
Tive exatamente essa discussão com a equipe de ML de um cliente. Tinham rodado sua avaliação de segurança, o modelo passou, fizeram o fine-tuning com seus próprios dados e estavam prontos para lançar. Perguntei quando planejavam rodar a avaliação de novo. A sala ficou um pouco em silêncio, porque a resposta honesta era "não íamos rodar". O modelo passa pelo portão antes da coisa que o quebra. Depois vai para produção com seus guardrails praticamente removidos, e toda a papelada diz que é seguro.
O modelo passa em sua verificação de segurança antes da etapa que destrói a segurança. Quase ninguém verifica de novo depois.
Então movemos a avaliação de segurança para depois do fine-tuning, transformamo-la em um portão de liberação em vez de um portão de entrada, e tratamos qualquer fine-tune como um evento que invalida a atestação de segurança anterior. Soa quase óbvio demais quando você diz em voz alta. A razão de não ser prática padrão é a mesma do portão que ninguém usava: o momento conveniente para avaliar é na entrada, e reavaliar após cada fine-tune é atrito. O atrito é o inimigo, mas, neste caso, é a única coisa entre um relatório aprovado e um modelo indefeso.
O envenenamento (poisoning) prova o mesmo ponto pela direção oposta. Pesquisas mostraram que apenas 250 documentos envenenados podem implantar um backdoor em um modelo de 13 bilhões de parâmetros — cerca de 0,00016% do corpus de treinamento. Você não precisa comprometer os dados em escala. Você precisa de uma quantidade equivalente a um erro de arredondamento. A Microsoft publicou uma resposta genuinamente animadora para isso em fevereiro de 2026 — um método de detecção de "agente adormecido" (sleeper agent) que consegue identificar um modelo envenenado sem conhecer a frase de gatilho, detectando um padrão de atenção distintivo. Essa é a primeira defesa real que vi contra um ataque que antes era quase indetectável. É também exatamente o tipo de capacidade que vive em um artigo de pesquisa, não no seu pipeline de CI/CD, até que alguém faça a engenharia para colocá-la lá.
Os agentes transformaram uma injeção de prompt em uma kill chain
Durante anos, o pior caso com um modelo manipulado ou uma injeção de prompt era uma saída ruim. O modelo diz algo errado, vaza algo que não deveria, deixa você em situação constrangedora. Limitado. Irritante. Superável.
A IA agêntica removeu esse limite.
Um agente de IA tem acesso a ferramentas, credenciais e privilégios de execução que um modelo de chat não tem. Então, quando você injeta uma instrução maliciosa em algo que um agente lê, você não está mais corrompendo uma resposta — está emitindo um comando para um sistema que pode agir. O GitHub Copilot teve uma vulnerabilidade de execução remota de código, CVE-2025-53773, classificada como CVSS 7.8 e corrigida em agosto de 2025, em que uma injeção de prompt plantada na documentação de um repositório podia fazer o agente entrar em seu "modo YOLO" autônomo e escalar até o comprometimento total do sistema. O agente leu um comentário malicioso, executou-o como código, e a máquina foi dominada.
Depois houve o incidente na cadeia de suprimentos do Amazon Q em julho de 2025: um template de prompt malicioso, o cleaner.md, foi injetado por meio de um token do GitHub mal configurado, e uma versão lançada distribuiu comandos destrutivos para uma base de instalação muito grande. E, em 2026, o ecossistema de agentes OpenClaw se tornou a primeira grande crise de segurança de agentes de IA do ano — 138 CVEs em 63 dias, mais de 135.000 instâncias expostas e 12% das skills em seu marketplace consideradas maliciosas. Os relatórios de ameaças de 2026 da HiddenLayer agora associam cerca de uma em cada oito brechas de IA a sistemas agênticos.
O fio condutor em todos esses casos é o mesmo: os agentes convertem uma única entrada manipulada em uma kill chain orquestrada e com múltiplas ferramentas. O que costumava ser uma frase errada torna-se uma sequência de ações reais com credenciais reais. Essa é a fronteira que mais me preocupa neste momento, porque está se expandindo mais rápido do que qualquer categoria de produto consegue acompanhar, e ainda não existe um manual consolidado para protegê-la.
Então, o que você de fato faz a respeito disso?
As pessoas sempre me perguntam alguma versão de: "Não posso simplesmente comprar uma ferramenta para isso?" E a resposta honesta é que você pode comprar partes, e as partes estão melhorando rápido.
O cenário de fornecedores amadureceu até se tornar um ecossistema de verdade — a Protect AI e a Wiz da Palo Alto para varredura e geração de bill of materials de IA dentro de suas suítes de nuvem e plataforma, a JFrog para proteger o registro de modelos e o pipeline de artefatos, a HiddenLayer para detecção e resposta em tempo de execução, os guardrails de código aberto da NVIDIA para controles de LLM na camada de aplicação, a Fortanix trazendo computação confidencial para a distribuição de modelos. Esse último é um bom exemplo de por que as ferramentas sozinhas não fecham a lacuna: GPUs confidenciais que mantêm um modelo criptografado mesmo enquanto ele roda (as gerações Hopper e Blackwell da NVIDIA) realmente existem, mas conectar esses ambientes de execução confiável a um pipeline de inferência ativo é uma engenharia especializada que a maioria das equipes simplesmente não tem no quadro. Cada fornecedor é genuinamente bom em sua fatia. Nenhum deles projeta o seu pipeline de ponta a ponta, mapeia-o para as suas obrigações ou muda como a sua organização de fato se comporta.
E a outra metade do mercado — as grandes consultorias de estratégia — vai lhe vender o problema oposto: um framework de governança de IA de 200 páginas, uma apresentação para o conselho, documentação pronta para auditoria e um contrato que começa em torno de US$ 500 mil para a estratégia e chega aos milhões para a implementação. O que elas normalmente não farão é construir o pipeline de assinatura de modelos, configurar a geração de ML-BOM dentro do seu CI/CD ou montar a detecção de shadow AI na camada de rede. Você acaba com o fichário e não com a construção.
Essa lacuna — entre ferramentas que fazem varredura e apresentações que aconselham — é toda a razão pela qual a Veriprajna faz segurança da cadeia de suprimentos de IA como engenharia em vez de como um relatório. O que construímos é concreto: pipelines automatizados de avaliação de modelos que colocam cada modelo recebido em sandbox comportamental e assinam os limpos com o PKI corporativo da sua empresa; um ML-BOM — um bill of materials de machine learning, o equivalente de IA a um rótulo de ingredientes que rastreia cada componente e sua proveniência — gerado e fixado dentro do pipeline usando o padrão CycloneDX; proveniência e assinatura construídas sobre o emergente trabalho de atestação da CoSAI; verificação de segurança pós-fine-tune; e detecção de shadow AI que revela os modelos que as suas ferramentas de segurança atualmente não conseguem ver.
Os padrões para fazer a maior parte disso já existem. O ML-BOM do CycloneDX, a assinatura de modelos do CoSAI e a taxonomia atualizada de ML adversarial do NIST (AI 100-2) estão todos publicados e utilizáveis hoje. O problema nunca foi um problema de conhecimento. Segundo a medição de 2025 da Kiteworks, 83% das organizações ainda não têm controles automatizados de segurança de IA — elas estão voando às cegas não porque falte o manual, mas porque ninguém tem a capacidade de engenharia para implementá-lo. A lacuna é de mãos, não de ideias.
Há também um relógio regulatório correndo sobre isso. O EU AI Act se torna plenamente aplicável em 2 de agosto de 2026 e, para sistemas de alto risco, exige documentação técnica real — proveniência dos dados de treinamento, avaliação de conformidade, o tipo de atestação de cadeia de suprimentos que um ML-BOM é feito para produzir. Importadores e distribuidores de componentes de IA terão de verificar o que estão repassando adiante, e os provedores e seus fornecedores terceirizados de componentes devem acordar por escrito sobre as informações e o acesso técnico que cada um compartilhará. Comecei a dizer aos clientes a parte silenciosa dessa cláusula: uma vez que a lei entre em vigor, a proveniência dos modelos deixa de ser apenas o seu problema a absorver — seus fornecedores terão de atestá-la por escrito, e os que não conseguirem simplesmente deixarão de ser utilizáveis. As empresas que tratam a proveniência dos modelos como um item apenas desejável vão descobrir que é uma exigência formal.
O slide que de fato moveu o orçamento
Vou terminar onde essas conversas costumam terminar: diante de um conselho.
Vi muitos casos de segurança bem construídos não conseguirem financiamento porque foram apresentados como casos de segurança — risco abstrato, atacantes hipotéticos, uma categoria que soa como seguro. A apresentação que funcionou foi a que colocou um único número sobre a mesa: o custo médio de US$ 4,63 milhões de uma brecha de shadow AI, contraposto ao custo de construir os controles que a evitam. Não medo. Um delta. Aqui está o risco quantificado, aqui está quanto custa fechá-lo, aqui está a diferença.
Esse enquadramento funciona porque é fiel à forma como esse problema realmente se comporta. A ameaça não é exótica. É o fluxo de trabalho padrão — baixar um modelo, fazer o fine-tuning, implantá-lo, nunca mais olhar — rodando em toda organização que constrói com IA, o que hoje é quase todas elas. Os orçamentos dos CISOs refletem isso: cerca de 85% das organizações aumentaram seus gastos com cibersegurança rumo a 2026, e a segurança de IA é o item de linha mais discutido.
Um modelo é o único artefato no seu ambiente que é, ao mesmo tempo, a coisa mais valiosa que você tem e um pedaço de código executável não verificado que você baixou de um estranho na internet. Até que você o trate como as duas coisas ao mesmo tempo — avaliá-lo como código, rastreá-lo como uma cadeia de suprimentos e reverificá-lo toda vez que o altera —, o relatório que diz que você está seguro está auditando um controle que ninguém de fato usa. Se você está pensando em por onde começar, comece por aí: pare de confiar no model card e observe o que o modelo faz quando é executado.
