Engenharia de Segurança de IA

Segurança da Cadeia de Suprimentos de IA & Integridade de Modelos

Seus modelos são código executável. A maioria das organizações os trata como arquivos de dados. É nessa lacuna que as violações acontecem.

US$ 4,63 mi

Custo médio de violação envolvendo shadow AI

IBM Cost of a Data Breach 2025

83%

Das organizações não possuem controles automatizados de segurança de IA

Kiteworks 2025

352 mil

Problemas inseguros encontrados em 51.700 modelos em registros públicos

Protect AI 2025

A Superfície de Ataque que a Maioria dos Programas de Segurança Ignora

Modelos de IA não são artefatos estáticos. São código que roda durante o carregamento, o treinamento, a inferência e a execução de agentes. Quatro categorias de ataque dominam o modelo de ameaças.

O Problema do Formato Pickle

torch.load() executa Python arbitrário durante a desserialização. Isso não é um bug. É o comportamento projetado da serialização pickle, e mais de 80% dos modelos de ML a utilizam.

Um modelo chamado "baller423" no Hugging Face foi flagrado estabelecendo um reverse shell para a Kreonet. O modelo parecia normal. Passou em escaneamentos básicos. Executou código arbitrário no momento em que alguém o carregou.

O PickleScan, a defesa mais utilizada, tem pelo menos 3 bypasses zero-day conhecidos (CVE-2025-10155). O escaneamento baseado em blacklist é fundamentalmente falho porque o atacante controla o formato de serialização.

O Fine-Tuning Destrói a Segurança

O Llama 3.1 8B cai de 0,95 para 0,15 em resiliência a prompt injection após uma única rodada de fine-tuning. Isso representa uma degradação de 84% no alinhamento de segurança a partir de um treinamento normal e não adversarial.

Quase ninguém reavalia a segurança após o fine-tuning. O modelo passa na avaliação de segurança inicial, recebe fine-tuning com dados de domínio e vai para produção com suas proteções efetivamente removidas. Isso não é um ataque exótico. É o fluxo de trabalho padrão na maioria das organizações.

Proliferação de Shadow AI

98% das organizações têm uso não autorizado de IA. Esse número não é um erro de digitação. O custo adicional de US$ 670 mil por violação em incidentes de shadow AI reflete uma realidade simples: você não pode proteger o que não pode ver.

62% das equipes de segurança não conseguem identificar onde os LLMs estão implantados em seu ambiente. Desenvolvedores baixam modelos do Hugging Face, chamam APIs da OpenAI com chaves pessoais e implantam modelos com fine-tuning em contas de nuvem pessoais. As ferramentas de segurança atuais revelam cerca de 38% dessa atividade.

Amplificação por IA Agêntica

A vulnerabilidade de RCE do GitHub Copilot (CVE-2025-53773, CVSS 7.8) transformou um prompt injection na documentação de um repositório em comprometimento total do sistema via modo YOLO. O agente leu uma instrução maliciosa, executou-a como código, e a máquina do usuário foi comprometida.

O arquivo cleaner.md do Amazon Q distribuiu comandos destrutivos para mais de 950 mil usuários por meio da janela de contexto do agente. O marketplace do OpenClaw acumulou 138 CVEs em 63 dias, com 12% das skills enviadas consideradas maliciosas.

Os agentes transformam prompt injections em comprometimentos em nível de sistema porque têm acesso a ferramentas, credenciais e privilégios de execução que os LLMs tradicionais não possuem.

Quem Faz o Quê na Segurança de Modelos de IA

O ecossistema de fornecedores está amadurecendo rápido. Aqui está uma visão honesta do que cada participante cobre e onde as lacunas permanecem.

Fornecedor O Que Fazem O Que Não Fazem Ideal Para
Palo Alto / Protect AI Escaneamento de modelos, geração de AI-BOM, integrado à plataforma Prisma AIRS Design de arquitetura, engenharia de pipelines personalizados, gestão de mudança organizacional Empresas que já usam a plataforma PANW
HiddenLayer Detecção e resposta de IA em tempo de execução, monitoramento de segurança agêntica Arquitetura de cadeia de suprimentos, implementação de ML-BOM, mapeamento de conformidade Equipes de SOC adicionando visibilidade de IA
JFrog MLSecOps, segurança de registro de modelos, integração com Hugging Face Red-teaming adversarial, validação de alinhamento de segurança, design de governança Equipes de DevOps gerenciando artefatos de modelos
Wiz AI-BOM no contexto de segurança em nuvem, escaneamento de modelos Segurança de modelos on-prem, segurança de fine-tuning, arquitetura agêntica Organizações cloud-first
NVIDIA NeMo Guardrails Guardrails de tempo de execução de código aberto para LLMs Escaneamento de modelos, segurança da cadeia de suprimentos, rastreamento de proveniência Equipes que constroem aplicações de LLM personalizadas
Big 4 / Grandes SIs Frameworks de governança, documentação de conformidade, apresentações para o conselho Implementação. Construir pipelines de escaneamento, configurar ML-BOMs, implantar assinatura de modelos. Os engajamentos começam em US$ 500 mil de estratégia e chegam a US$ 3-10 mi. Organizações que precisam de documentação pronta para auditoria
Código Aberto (ModelScan, PickleScan, SafeTensors) Escaneamento básico gratuito e formatos de serialização mais seguros Orquestração de nível empresarial, sandboxing comportamental, proveniência, aplicação de políticas Equipes com forte engenharia de segurança interna

Uma lacuna que ninguém preenche bem. A mudança de cultura organizacional é a parte mais difícil. Nenhuma ferramenta ou consultoria elimina a tendência humana de contornar a governança em prol da velocidade. Construímos os controles técnicos, mas o CISO ainda precisa de apoio executivo. Quando um cientista de dados consegue baixar um modelo do Hugging Face em 30 segundos, qualquer barreira de segurança que leve 30 minutos será contornada. Os controles precisam ser rápidos o suficiente para que a conformidade seja mais fácil do que a evasão.

O Que Construímos para Programas de Segurança de IA

Seis capacidades, cada uma projetada para integrar-se à sua stack de segurança existente e aos seus pipelines de CI/CD.

01

Pipelines de Avaliação de Modelos

Construímos uma avaliação automatizada que fica entre os repositórios públicos de modelos e seu registro interno. Cada modelo passa por sandboxing comportamental (carregado em contêineres isolados, com syscalls monitoradas), análise profunda multiformato (pickle, PyTorch, GGUF, Keras, SafeTensors) e assinatura criptográfica com a PKI da sua empresa.

Recorremos à análise comportamental em vez do escaneamento estático porque os bypasses zero-day do PickleScan provam que as abordagens de blacklist são fundamentalmente falhas. O escaneamento estático pergunta "este arquivo contém padrões reconhecidamente maliciosos?" O sandboxing comportamental pergunta "o que este código realmente faz quando é executado?" A segunda pergunta detecta ataques inéditos.

02

Arquitetura de ML-BOM & Proveniência

Geração de ML-BOM CycloneDX integrada ao CI/CD. Cada modelo recebe uma lista de materiais documentando a proveniência dos dados de treinamento, versões de framework, árvores de dependências e histórico de fine-tuning.

Usamos CycloneDX em vez de SPDX porque a ferramenta de ML-BOM é mais madura, embora garantamos a exportação para SPDX 3.0 para organizações que precisam de ambos. O ML-BOM não é um item de checklist de conformidade. É a estrutura de dados que torna possível todos os outros controles de segurança: você não pode assinar o que não pode inventariar, e não pode auditar o que não pode rastrear.

03

Descoberta de Shadow AI

Detecção em nível de rede de downloads de modelos não autorizados e chamadas de API de IA. Integração com seu SIEM/SOAR existente. Mapeamos cada ponto de contato de IA, incluindo implantações de shadow, e então construímos a aplicação de políticas que bloqueia o risco sem bloquear a inovação.

O objetivo: sua equipe de segurança enxerga 100% do uso de IA, não os 38% que as ferramentas atuais revelam. A detecção abrange downloads do Hugging Face, chamadas de API da OpenAI/Anthropic/Google, transferências de pesos de modelos por HTTP/S e execução local de modelos via monitoramento de processos em endpoints gerenciados.

04

Validação de Segurança Pós-Fine-Tuning

Reavaliação automatizada de segurança após cada rodada de fine-tuning. Suíte de benchmark OWASP LLM Top 10, sondagem adversarial em busca de gatilhos de backdoor e testes de regressão de alinhamento de segurança.

Construímos isso porque quase ninguém reavalia a segurança após o fine-tuning. Os dados de degradação de segurança na seção acima reforçam o argumento. O pipeline de validação roda como uma barreira de CI/CD. Um modelo que falha na regressão de segurança não pode ser promovido para produção, independentemente de seu desempenho na tarefa.

05

Arquitetura de Segurança para IA Agêntica

Separação de privilégios para agentes de IA. Camadas de política determinísticas que impedem a escalada de prompt para RCE (o exato vetor de ataque na CVE-2025-53773). Aplicação de políticas de uso de ferramentas, barreiras com humano no circuito para operações de alto risco e monitoramento de comportamento em tempo de execução.

A arquitetura detecta ações anômalas do agente antes que elas se propaguem em cascata. Um agente que de repente começa a escrever em caminhos de sistema de arquivos fora do seu sandbox, chamar APIs que nunca chamou antes ou tentar escalada de privilégios é encerrado e sinalizado para revisão.

06

Design de Programa de Segurança de IA

Para CISOs construindo a função do zero. Mapeamento de controles NIST AI 100-2, arquitetura de conformidade com o EU AI Act, quantificação de risco em nível de conselho e playbooks de resposta a incidentes para ataques específicos de IA.

Ajudamos a traduzir o risco técnico em justificativa orçamentária que os conselhos aprovam. "Encontramos 352 mil problemas inseguros em registros públicos de modelos" é um dado. "Nossos engenheiros baixaram 47 modelos não avaliados no último trimestre, 3 continham código executável em sua camada de serialização, e nossos controles atuais não detectaram nenhum deles" é uma justificativa orçamentária.

Como Funciona um Engajamento

Três fases, cada uma com entregáveis definidos e ressalvas honestas sobre o que esperar.

Fase 1

Descoberta & Modelagem de Ameaças

Semanas 1-3

  • Inventário de ativos de IA: catalogar cada modelo, API, agente e pipeline em seu ambiente
  • Varredura de shadow AI: detecção em nível de rede de uso não autorizado de IA em todos os pontos de egresso
  • Modelo de ameaças: mapear superfícies de ataque específicas da sua arquitetura de implantação e tipos de modelos
  • Análise de lacunas em relação aos requisitos do NIST AI 100-2 e do EU AI Act

Entregável: Relatório de Postura de Segurança de IA com registro de riscos priorizado

Ressalva: Esta fase frequentemente revela de 3 a 5 vezes mais uso de IA do que o CISO esperava. Isso é normal. A descoberta de shadow AI é a parte mais valiosa e a mais desconfortável do engajamento.

Fase 2

Arquitetura & Construção

Semanas 4-10

  • Projetar o pipeline de avaliação de modelos, a geração de ML-BOM e a infraestrutura de assinatura
  • Construir e implantar no seu CI/CD (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
  • Configurar a detecção de shadow AI e a integração com SIEM (Splunk, Sentinel, Chronicle)
  • Implementar a validação de segurança pós-fine-tuning como uma barreira de CI/CD

Entregável: Controles de segurança prontos para produção, integrados aos fluxos de trabalho existentes

Ressalva: O cronograma depende da maturidade do CI/CD. Equipes com pipelines de DevOps maduros implantam mais rápido. Organizações que ainda movem modelos por pen drives ou pastas compartilhadas (mais comum do que se imagina) precisam de trabalho de infraestrutura adicional.

Fase 3

Operacionalizar & Transferir

Semanas 11-14

  • Treinar a equipe de segurança nas operações de avaliação de modelos e na triagem de alertas
  • Estabelecer uma cadência de red-team adversarial (trimestral recomendada, mensal para sistemas de alto risco)
  • Construir playbooks de resposta a incidentes para ataques em nível de modelo e incidentes de IA agêntica
  • Modelos de relatório prontos para o conselho com quantificação de risco

Entregável: Operações de segurança de IA autossustentáveis com runbooks documentados

Ressalva: O primeiro red-team adversarial sempre encontra algo. Esse é o objetivo. Um red-team que não encontra nada ou não se esforçou o suficiente ou teve um escopo definido de forma estreita demais.

Avaliação de Maturidade em Segurança da Cadeia de Suprimentos de IA

Responda a oito perguntas para comparar sua postura de segurança de IA. Nenhum dado é coletado. Tudo roda no seu navegador.

Q1Você tem um catálogo de cada modelo de IA em produção?

Q2Os modelos de repositórios públicos (Hugging Face, GitHub) são escaneados antes do uso interno?

Q3Você gera ML-BOMs para seus modelos?

Q4Sua equipe de segurança consegue detectar chamadas de API de IA não autorizadas?

Q5Você reavalia o alinhamento de segurança após o fine-tuning?

Q6Seus artefatos de modelo são assinados criptograficamente?

Q7Você tem playbooks de resposta a incidentes para ataques específicos de IA?

Q8Seu programa de segurança de IA está mapeado para um framework (NIST AI RMF, EU AI Act)?

Perguntas que os CISOs Fazem sobre Segurança da Cadeia de Suprimentos de IA

Quanto tempo leva para construir um pipeline de avaliação de modelos do zero?

4-6 semanas para um pipeline básico cobrindo escaneamento estático e verificação de assinatura. 8-12 semanas para sandboxing comportamental completo com integração de CI/CD. O gargalo raramente é a tecnologia de escaneamento em si. É a integração com seu registro de modelos existente (MLflow, Weights & Biases, JFrog ML) e a definição da lógica de política: o que é bloqueado, sinalizado ou colocado em quarentena. Descobrimos que as decisões de política levam mais tempo do que a engenharia.

A complexidade do formato adiciona tempo. Pickle, PyTorch, GGUF, Keras e SafeTensors exigem, cada um, abordagens de análise diferentes. O Pickle continua sendo o formato de maior risco porque torch.load() executa Python arbitrário durante a desserialização, motivo pelo qual o sandboxing comportamental importa mais do que o escaneamento estático para esse formato. O SafeTensors é a opção de serialização mais segura e a mais simples de escanear, mas menos de 20% dos modelos de produção o usam hoje. Seu pipeline precisa lidar com todos eles porque você não pode controlar qual formato os fornecedores de modelos upstream escolhem.

Já usamos Palo Alto/Wiz/JFrog para segurança. Por que precisamos de trabalho personalizado?

Essas plataformas são excelentes no que fazem. A integração Protect AI da Palo Alto (via Prisma AIRS) oferece escaneamento de modelos dentro da sua stack de segurança existente. O MLSecOps da JFrog cuida da governança do registro de modelos. A Wiz adiciona AI-BOM à visibilidade em nuvem. O que elas não fazem: projetar a arquitetura ponta a ponta, configurar a geração de ML-BOM no seu pipeline de CI/CD específico, construir a lógica de política para o seu contexto regulatório ou reengenheirar seu fluxo de trabalho de implantação de modelos. Elas são ferramentas de escaneamento. Nós somos a equipe de implementação que faz com que funcionem em conjunto.

Muitos engajamentos começam com organizações que já têm essas plataformas, mas precisam de ajuda para operacionalizá-las. Um padrão comum: a equipe de segurança comprou o Protect AI seis meses atrás, rodou um escaneamento, obteve 400 achados e então estagnou porque ninguém mapeou esses achados para fluxos de remediação ou integrou o escaneamento ao pipeline de promoção de modelos.

Qual é o risco real de envenenamento de modelos? Já aconteceu em produção?

A barreira técnica para o envenenamento de modelos é menor do que a maioria dos CISOs imagina. Pesquisas demonstram que apenas 250 documentos envenenados em um corpus de treinamento podem inserir um backdoor em um modelo de 13B de parâmetros. A Microsoft publicou métodos de detecção inovadores em fevereiro de 2026, mas a maioria das organizações tem zero capacidade de detecção implantada. O problema de degradação de segurança no fine-tuning é mais imediato e mais comum: o Llama 3.1 8B cai de 0,95 para 0,15 em resiliência a prompt injection após uma única rodada de fine-tuning. Isso não é um ataque. É fine-tuning normal sem reavaliação de segurança.

Incidentes de produção documentados de envenenamento intencional de modelos continuam raros. Mas as condições estão propícias: mais de 80% dos modelos de ML usam serialização pickle, 62% das equipes de segurança não conseguem identificar onde os modelos estão implantados, e um modelo chamado "baller423" no Hugging Face foi flagrado estabelecendo um reverse shell para a Kreonet. O precedente de descarte de modelos da FTC (Weight Watchers/Kurbo, 2022) significa que um modelo envenenado pode forçá-lo a deletar e retreinar do zero, a custos que ofuscam a própria violação.

Como lidamos com os requisitos de proveniência de modelos do EU AI Act?

O EU AI Act é totalmente aplicável a partir de 2 de agosto de 2026. Para sistemas de IA de alto risco, você precisa de documentação técnica cobrindo a proveniência dos dados de treinamento, escopo, características e metodologias de limpeza. As obrigações da cadeia de suprimentos exigem que importadores e distribuidores verifiquem a avaliação de conformidade, a documentação técnica e a marcação CE. Na prática, isso significa ML-BOMs para cada modelo no seu pipeline, atestados assinados de proveniência e trilhas de auditoria para decisões de fine-tuning.

O ML-BOM CycloneDX é o padrão mais pronto para implementação. O SPDX 3.0 adicionou perfis de IA/ML em 2024, e algumas organizações precisam de ambos os formatos para diferentes públicos regulatórios. Construímos o pipeline de documentação para que o rastreamento de proveniência seja automatizado, não um exercício manual de conformidade. O erro comum é tratar isso como um projeto de documentação único. Cada rodada de fine-tuning, cada atualização de modelo e cada mudança de conjunto de dados precisa gerar registros de proveniência atualizados. Se o seu ML-BOM for estático, ele estará errado em questão de semanas.

Podemos proteger agentes de IA sem deixá-los mais lentos?

A separação de privilégios é a base. Cada agente recebe um perfil de privilégio mínimo que define quais ferramentas ele pode chamar, quais APIs pode acessar e quais caminhos do sistema de arquivos pode tocar. Isso espelha o modelo de capacidades do Linux aplicado a agentes de IA. O RCE do GitHub Copilot (CVE-2025-53773, CVSS 7.8) aconteceu porque o modo YOLO deu ao agente acesso irrestrito ao sistema, e um prompt injection na documentação de um repositório escalou para execução remota de código completa. As camadas de política determinísticas impedem totalmente esse caminho de escalada.

O monitoramento em tempo de execução adiciona uma linha de base comportamental que detecta ações anômalas do agente (chamadas de ferramentas inesperadas, padrões de API incomuns, tentativas de escalada de privilégios) sem adicionar latência às operações normais. HÁ um pequeno custo de latência para verificações de segurança em operações de alto risco: escritas no sistema de arquivos, chamadas de API em nuvem, acesso a credenciais. Para a maioria das implantações empresariais, isso é de 50-200ms por operação controlada. Operações de baixo risco (leitura de fontes de dados aprovadas, geração de texto, chamada de APIs pré-aprovadas) passam com zero de latência adicional. A questão é se 50-200ms em chamadas de alto risco é aceitável em comparação com um agente com acesso total ao sistema e sem proteções.

Como é uma resposta a incidentes de segurança de IA?

Incidentes de segurança de IA exigem uma perícia diferente das intrusões de rede. Para ataques em nível de modelo (envenenamento, backdoors), a sequência de resposta é: isolar o modelo da produção, verificar a integridade do pipeline de treinamento, checar a exfiltração de dados por meio das saídas do modelo (modelos podem codificar dados roubados em seus pesos e vazá-los via prompts cuidadosamente elaborados) e determinar se é necessário retreinar a partir de um checkpoint reconhecidamente limpo.

Para incidentes de IA agêntica, você também precisa rastrear cada chamada de ferramenta e ação que o agente realizou, verificar a integridade de sua memória e janela de contexto (o prompt injection pode persistir entre sessões se o contexto for armazenado) e checar a movimentação lateral por meio das permissões do agente. Os processos genéricos de IR não cobrem a perícia em nível de modelo porque os artefatos são diferentes. Você não está analisando logs de rede e dumps de memória. Você está analisando pesos de modelos, proveniência de dados de treinamento, históricos de fine-tuning e logs de ações do agente. Construímos playbooks específicos para esses cenários, incluindo procedimentos de preservação de evidências para pesos de modelos (que podem ter centenas de gigabytes), documentação de cadeia de custódia para dados de treinamento e modelos de comunicação para reguladores que podem exigir o descarte do modelo.

Pesquisa Técnica

As bases técnicas por trás desta solução, publicadas como whitepapers detalhados.

Seus Modelos Estão Rodando. Eles Estão Seguros?

62% das equipes de segurança não conseguem identificar onde os modelos de IA estão implantados em seu próprio ambiente.

A maioria das organizações descobre suas lacunas de segurança de IA depois de um incidente. Nós ajudamos você a encontrá-las antes que um aconteça.

Avaliação de Segurança de IA

  • ✓ Inventário completo de ativos de IA e shadow AI
  • ✓ Análise de lacunas do pipeline de avaliação de modelos
  • ✓ Mapeamento de conformidade com NIST AI 100-2 e EU AI Act
  • ✓ Relatório de quantificação de risco pronto para o conselho

Implementação de Segurança de Modelos

  • ✓ Pipeline automatizado de escaneamento e assinatura de modelos
  • ✓ Geração de ML-BOM integrada ao CI/CD
  • ✓ Detecção de shadow AI e integração com SIEM
  • ✓ Validação de segurança pós-fine-tuning