O risco de um modelo de IA depende do que ele pode acessar

Uma nova pesquisa da Snyk, realizada em milhares de ambientes empresariais analisados, mostra por que uma pontuação alta de risco de modelo marca o início da triagem e como as equipes de segurança devem agir.

Imagine duas aplicações que usam o mesmo modelo de IA. Uma resume notas de reuniões; a outra usa um agente para consultar registros de clientes e acionar fluxos de trabalho empresariais. O modelo pode apresentar as mesmas pontuações em testes adversariais nas duas aplicações. Mas as consequências de uma falha podem ser muito diferentes — assim como a falha que importa. Um resumidor de reuniões precisa saber se é possível induzir o modelo a gerar conteúdo enganoso. Já um agente que acessa registros de clientes precisa saber se é possível fazê-lo vazar dados ou realizar ações não autorizadas. Por isso, uma pontuação do modelo para cada tipo de ataque é mais útil do que uma média geral.

Essa distinção está no centro do State of Agentic AI Adoption 2026, Volume III da Snyk. Os dois primeiros volumes mostraram que a IA empresarial é um ecossistema de software conectado, não apenas uma coleção de modelos. Esta nova análise acrescenta pontuações de risco para modelos identificáveis e faz a pergunta que os líderes de segurança realmente precisam responder: quais descobertas exigem ação e que ação reduzirá o risco?

Quase metade dos inventários de modelos de IA inclui uma referência com pontuação crítica

Como funcionam as pontuações: A Snyk testa cada modelo contra 29 objetivos de ataque, como extrair dados pessoais ou executar comandos, e atribui a cada um uma pontuação de 0 a 1.000. A pontuação combina a frequência de sucesso do ataque com o dano que esse objetivo poderia causar. A partir de 500, a pontuação é alta; a partir de 750, é crítica. Os modelos são testados com uma proteção básica, portanto as pontuações descrevem um modelo protegido, não um desprotegido.

Dos 1.693 ambientes com pelo menos um identificador de modelo detectado, 74,5% fazem referência a um modelo que obteve pontuação alta (500+) em pelo menos um objetivo de ataque, e 49,2% fazem referência a um modelo com pontuação crítica (750+). A extração de informações pessoais identificáveis (PII) e a execução de comandos respondem pelas descobertas na faixa crítica observadas nesta amostra.

Esses números devem levar a uma investigação, não ao pânico. A pesquisa relaciona identificadores de modelos encontrados no código a resultados de testes adversariais. Ela não comprova que todos os modelos estejam ativos em produção, que uma ferramenta ou conjunto de dados específico possa ser acessado, nem que um ataque tenha sido bem-sucedido na aplicação de uma organização.

A cobertura é outro motivo para ter precisão: apenas 37,5% das ocorrências de modelos detectadas têm uma pontuação de risco correspondente. Cerca de 17% dos ambientes que incluem modelos não têm nenhum modelo pontuado. Trate referências sem pontuação ou sem versão como incógnitas que ainda precisam ser analisadas.

O tamanho do inventário altera a quantidade de descobertas, mas não a proporção entre elas. A probabilidade de encontrar pelo menos um modelo com pontuação alta sobe de 34,6% nos menores inventários para 100% nos maiores. Ainda assim, a parcela de ocorrências de modelos associadas a modelos com pontuação alta permanece entre 21% e 25% em todos os tamanhos, e entre 18,9% e 25,5% em oito setores. Use a quantidade para dimensionar o backlog de revisão e a proporção para comparar as escolhas de modelos com as de organizações pares. Nenhum desses números mostra o que uma aplicação ativa permite que um modelo faça.

Para cada modelo com pontuação alta, as primeiras perguntas são: ele está ativo, o que pode acessar e o que acontece se falhar?

Agentes e servidores MCP tornam impossível ignorar o contexto de implantação

Um modelo pode gerar uma resposta insegura por conta própria. Conectado a ferramentas, dados e fluxos de trabalho, ele também pode agir com base nessa resposta. Essa é a diferença entre a exposição testada de um modelo e o alcance do sistema ao redor dele.

Entre as 1.051 contas dos EUA com uma referência a MCP, 744 (70,8%) apresentam evidências de desenvolvimento de um servidor MCP usando um SDK. As demais mostram apenas conexões de cliente ou referências de configuração. Desenvolver um servidor, configurá-lo e operá-lo são três sinais diferentes — e só a verificação em tempo de execução confirma o último.

Entre os ambientes sem sinais detectados de agente ou MCP, 49,1% fazem referência a um modelo com pontuação alta, em comparação com 96,6% daqueles que apresentam tanto um indicador de agente quanto código para desenvolver um servidor MCP.

Esse último grupo também tem um inventário mediano de modelos muito maior: 104, contra 4. Ao comparar ambientes com 5 a 19 modelos, a diferença cai de 47 para 26 pontos (62,1% contra 87,8%). Esse padrão indica uma associação. O que agentes e servidores MCP mudam é até onde a pontuação de um modelo pode chegar — por isso, é ali que vale investigar primeiro.

Para as equipes de segurança, o próximo passo é verificar: confirme quais agentes e servidores MCP estão ativos, quais ferramentas eles disponibilizam, quais dados podem recuperar e quais aprovações são necessárias entre a saída de um modelo e uma ação de impacto. A pontuação de um modelo não responde a essas perguntas.

Não aplique a mesma correção a todas as fragilidades de IA

Depois de saber o que um modelo pode acessar, a próxima pergunta é qual correção se aplica à falha. Um programa eficaz de risco de modelos não se limita às faixas de gravidade. Ele identifica qual objetivo de ataque importa para a aplicação e se outro modelo tem um desempenho significativamente melhor nesse objetivo. A resposta se divide em dois caminhos:

• Quando trocar de modelo pode ajudar. Na execução de comandos, 77% dos modelos testados tiveram pontuação zero, enquanto o pior chegou a 834. Para backdoors em código, 57% tiveram pontuação zero, enquanto o pior chegou a 695.

• Quando os controles da aplicação fazem a diferença. Em desinformação, o modelo mediano atingiu a pontuação máxima possível. Em viés de gênero, nenhum modelo testado teve pontuação zero.

Uma pontuação zero significa que nenhum ataque foi bem-sucedido naquele teste. E um modelo com bom desempenho em um objetivo pode ter um desempenho ruim em outro. Por isso, valide qualquer substituto em relação a todos os objetivos dos quais a carga de trabalho depende. Quando os resultados se concentram, a defesa deve estar na aplicação: limite o acesso, valide as saídas, exija aprovações, monitore o uso e analise o código gerado e as dependências antes de incluí-los em um build.

Os limites de alerta também contam só parte da história: 18 dos 29 objetivos de ataque nunca podem atingir o limite padrão de alerta de 500, porque o dano que cada um pode causar limita sua pontuação máxima a um valor inferior. Essas falhas continuam sendo importantes mesmo quando a fila de alertas está vazia.

Quando os modelos diferem, teste um substituto. Quando não diferem, reduza o acesso e as permissões da aplicação.

Quais objetivos podem ser resolvidos de fato ao trocar de modelo e quais nunca vão gerar um alerta? Confira os 29 no gráfico. Baixe o relatório completo.

Talvez seja hora de reavaliar sua lista de modelos aprovados

Familiaridade, licença e preço não substituem a análise do modelo específico.

Modelos com menos recursos merecem uma revisão prioritária

No grupo com pontuações, os modelos com menos recursos tiveram resultados piores em vazamento de dados pessoais, contorno de decisões e geração de código inseguro. No contorno de decisões, a média caiu de 501 nos modelos abaixo de 130 no Epoch Capabilities Index (ECI) para 45 nos modelos com ECI igual ou superior a 150. Esses modelos com menos recursos representam cerca de um terço das ocorrências na comparação com pontuações — portanto, essa descoberta vai muito além de um caso isolado.

Capacidade é uma medida distinta de segurança, e até um modelo mais robusto precisa ser testado para a tarefa que executará. Reavalie as versões aprovadas com menos recursos e teste alternativas do mesmo provedor que você já usa, pois esse padrão também aparece nos catálogos de modelos de provedores individuais.

O provedor é um primeiro indicador útil, embora diga menos sobre os modelos de ponta. Entre os modelos intermediários, as médias dos provedores variam de 113 a 356; entre os mais capazes, três provedores líderes ficam a até 22 pontos uns dos outros. Se sua lista de modelos aprovados depende de um único provedor, o relatório completo mostra em que aspectos os modelos dele se destacam e onde ficam atrás. Seis provedores são comparados lado a lado em sete tipos de ataque, da exfiltração de dados à manipulação de saídas. Nesta amostra, as faixas de preço premium não apresentaram uma vantagem de segurança consistente, em grande parte porque a faixa de preço mais alta é composta principalmente por modelos mais antigos e com menos recursos.

Modelos de pesos abertos e linhagem dos dados de treinamento

O relatório também encontrou pontuações mais altas de vazamento de dados pessoais entre os 16 modelos de pesos abertos pontuados do que entre os modelos proprietários: 562 contra 274, em média. A amostra é pequena; portanto, considere essa diferença um sinal que merece investigação em cargas de trabalho que lidam com dados pessoais.

A visibilidade da linhagem segue a mesma divisão. Em 904 dos 1.693 ambientes com modelos, as análises não encontraram informações sobre a linhagem dos dados de treinamento, principalmente porque provedores de modelos proprietários não publicam seus conjuntos de dados de treinamento. Portanto, as evidências dependem do tipo de modelo: peça garantias documentadas aos fornecedores de modelos proprietários e examine as informações de linhagem dos conjuntos de dados publicados por modelos de pesos abertos.

Quatro ações para líderes de segurança

1. Faça o inventário e avalie as incógnitas: Acompanhe identificadores e versões dos modelos, responsáveis, usos ativos, agentes, ferramentas, servidores MCP e informações de linhagem disponíveis. Mantenha os modelos sem correspondência visíveis; não os classifique silenciosamente como de baixo risco.

2. Verifique o alcance: Confirme o caminho em tempo de execução de cada modelo ativo até os dados confidenciais, as credenciais, as ferramentas e as ações subsequentes. Diferencie o código de desenvolvimento de servidores da configuração e das conexões efetivas.

3. Adapte a correção ao objetivo: Classifique as falhas de acordo com suas consequências para o negócio. Teste modelos substitutos específicos quando os resultados adversariais variarem; quando não variarem, aplique o princípio do menor privilégio, verificações de saída, aprovações e análise de código.

4. Transforme a decisão em governança: Registre o modelo e a versão, as evidências dos testes, o responsável, os controles aprovados, a justificativa e a data de revisão. Reavalie sempre que houver mudanças nos modelos, nas permissões, nos dados de ajuste fino ou nas aplicações.

A principal conclusão do Volume III: a pontuação de um modelo mostra sua exposição, e o sistema ao redor determina seu alcance. Aja sobre os dois, troque de modelo quando houver diferenças e reforce os controles quando não houver.

Metodologia: dados anonimizados e agregados de análises de listas de materiais de IA (AI-BOM) de organizações que usam a Snyk, a partir de setembro de 2026: 3.023 ambientes, incluindo 1.693 com pelo menos um identificador de modelo. As descobertas sobre modelos abrangem contas dos EUA.

Líderes de segurança precisam saber quais falhas podem afetar seus negócios e quais mudanças nos controles podem mudar o resultado. Qual padrão de agentes e MCP descreve seu ambiente? E como seu provedor se compara em sete tipos de ataque? O relatório completo detalha ambos, além dos resultados por setor e faixa de preço e das seis perguntas que todo líder de governança deve saber responder. Baixe o State of Agentic AI Adoption 2026, Volume III.

Pronto para avaliar seu ambiente de IA? Conheça o Evo AI-SPM.