Machine Learning Adversarial

O que é aprendizado de máquina adversarial?

Aprendizado de máquina adversarial (adversarial machine learning, AML) estuda como sistemas de aprendizado de máquina (machine learning) podem ser manipulados intencionalmente por um atacante — e como construir sistemas que permaneçam confiáveis sob esse tipo de manipulação. Diferentemente de problemas de robustez “naturais” (ruído, mudança de distribuição (distribution shift)), o aprendizado de máquina adversarial assume um adversário adaptativo (adaptive adversary) que observa seu sistema e busca ativamente entradas ou intervenções de treinamento que causem dano.

O aprendizado de máquina adversarial abrange três grandes classes de ameaças:

• Evasão em tempo de teste (test-time evasion): criação de exemplos adversariais (adversarial examples) que levam a previsões incorretas na inferência. Veja também: Exemplos Adversariais.
• Ataques em tempo de treinamento (training-time attacks): envenenamento de dados (data poisoning) e portas dos fundos (backdoors) que corrompem um modelo durante treinamento ou ajuste fino (fine-tuning). Veja também: Envenenamento de Dados e Portas dos Fundos.
• Manipulação em nível de sistema (system-level manipulation): ataques ao pipeline ao redor — coleta de dados, rotulagem, recuperação, uso de ferramentas, APIs, limites de taxa, dependências ou configuração de implantação — em que “o modelo” é apenas um componente.

O aprendizado de máquina adversarial é uma disciplina prática de segurança: o sucesso depende de modelagem de ameaças, avaliação contra atacantes realistas e mitigações em camadas ao longo da pilha de aprendizado de máquina e de software.

Por que sistemas de aprendizado de máquina são vulneráveis

Fronteiras de decisão de alta dimensionalidade

Modelos modernos (especialmente redes profundas (deep networks)) aprendem fronteiras de decisão (decision boundaries) complexas em espaços de alta dimensionalidade. Em altas dimensões, muitas vezes é possível fazer pequenas mudanças estruturadas nas entradas que as movem através de uma fronteira de decisão, mesmo quando as mudanças parecem insignificantes para humanos.

Um enquadramento comum: o atacante busca uma perturbação (perturbation) (\delta) tal que

• (x' = x + \delta) seja “próximo” de (x) (sob uma restrição como (|\delta|_\infty \le \epsilon)), mas
• a previsão do modelo mude: (f(x') \ne f(x)) (não direcionado) ou (f(x') = t) (direcionado).

Diferenciabilidade facilita a otimização para atacantes

Muitos modelos de aprendizado de máquina são diferenciáveis. Se um atacante tem acesso ao modelo (ou a um bom substituto), ele pode usar gradientes (gradients) para otimizar uma entrada e induzir uma previsão desejada. Isso torna ataques de evasão rápidos e confiáveis no cenário de caixa branca.

A implantação é de mundo aberto

Implantações reais ingerem entradas de fontes não controladas: uploads de usuários, sensores, conteúdo da web, chamadas de API. Mesmo que a acurácia em média seja alta, um atacante pode focar em casos de borda, operar perto de fronteiras de decisão e sondar repetidamente o sistema.

Modelagem de ameaças: a base para defesas reais

“Robustez (robustness)” não é uma coisa só — é preciso definir robusto a quê. A modelagem de ameaças (threat modeling) responde a essa pergunta.

Defina o objetivo de segurança e os ativos

Exemplos de objetivos:

• Integridade: impedir que o atacante cause classificação incorreta (por exemplo, deixar malware passar).
• Disponibilidade: impedir negação de serviço ou comportamento desestabilizador (por exemplo, causar abstenções constantes).
• Segurança (safety): impedir saídas perigosas (por exemplo, chamadas inseguras de ferramentas ou aconselhamento médico).
• Privacidade / confidencialidade: impedir vazamento de dados de treinamento ou atributos sensíveis (relacionado, mas tipicamente coberto por ataques como Inferência de Participação, Inversão de Modelo e Extração de Dados de Treinamento).

Ativos a proteger podem incluir: correção das decisões, pesos do modelo, dados de treinamento, disponibilidade do API, acesso a ferramentas downstream ou confiança do usuário.

Especifique as capacidades do atacante

Eixos comuns:

• Conhecimento
  • Caixa branca (white-box): atacante conhece arquitetura/pesos e pode computar gradientes.
  • Caixa cinza (gray-box): atacante conhece a abordagem geral e pode consultar o modelo.
  • Caixa preta (black-box): atacante só vê saídas limitadas (rótulos vs probabilidades) e pode consultar com restrições.
• Acesso
  • Acesso por consultas a uma API, acesso local a um dispositivo, acesso ao pipeline de treinamento ou a artefatos de dependências.
• Orçamento
  • Número de consultas, computação, tempo, fração de envenenamento, tamanho máximo de perturbação ou restrições físicas.
• Objetivo
  • Classificação incorreta direcionada vs não direcionada, ativação de porta dos fundos, furtividade ou extração de PI (veja Extração / Roubo de Modelo).

Defina restrições e perturbações “permitidas”

As restrições devem refletir o mundo real:

• Visão: pequenas perturbações de pixels, mudanças de iluminação, adesivos, mudanças de ponto de vista.
• Texto: distância de edição, substituições por sinônimos, paráfrases, strings de injeção de prompt (prompt injection).
• Áudio: ruído imperceptível, restrições de reprodução “over-the-air”.
• Tabelas: restrições de atributos (não dá para tornar a idade de alguém negativa; deve permanecer plausível e consistente).

Decida como é o “sucesso”

Você deve escolher métricas ligadas à aplicação:

• Taxa de sucesso do ataque (attack success rate, ASR) sob restrições
• Acurácia robusta (robust accuracy): acurácia sob um ataque especificado
• Desempenho de pior caso vs caso médio
• Taxa de eventos de segurança para sistemas generativos (por exemplo, uso nocivo de ferramentas)

A modelagem de ameaças também esclarece onde investir: fortalecer o modelo, o pipeline, ou ambos.

Panorama de ataques

1) Evasão em tempo de teste (exemplos adversariais)

Ataques de evasão manipulam entradas na inferência para induzir erros. Eles podem ser:

• Não direcionados: qualquer rótulo incorreto é aceitável.
• Direcionados: forçar uma saída específica (geralmente mais difícil, mas mais danoso).
• Digitais: o atacante edita diretamente os bytes de entrada (imagens, texto, pacotes).
• Físicos: o atacante altera o mundo real (adesivos, padrões impressos, áudio reproduzido por alto-falantes).

Exemplo prático: evasão de classificador de imagens

Um cenário clássico: um modelo de visão classifica placas de trânsito. Um atacante coloca um adesivo cuidadosamente projetado em uma placa de “pare” que faz o modelo prever “limite de velocidade 45”. O adesivo precisa sobreviver a:

• mudanças de ponto de vista,
• variação de iluminação,
• ruído e compressão da câmera,
• restrições de impressão.

Essas restrições do “mundo físico” muitas vezes importam mais do que pequenos limites de norma (L_p).

Ataques baseados em gradiente (FGSM/PGD)

Um ataque de caixa branca fundamental é FGSM (Fast Gradient Sign Method):

[ x' = x + \epsilon \cdot \text{sign}(\nabla_x \mathcal{L}(f(x), y)) ]

PGD (Projected Gradient Descent) itera passos no estilo FGSM e projeta de volta para o conjunto permitido de perturbações, muitas vezes tornando-o muito mais forte.

Exemplo mínimo ilustrativo de FGSM em estilo PyTorch:

# Illustrative example (not production-hardened)
x = x.clone().detach().requires_grad_(True)
logits = model(x)
loss = torch.nn.functional.cross_entropy(logits, y)
loss.backward()

eps = 8/255
x_adv = x + eps * x.grad.sign()
x_adv = torch.clamp(x_adv, 0, 1).detach()

Ataques de caixa preta

Mesmo sem gradientes, atacantes podem:

• treinar um modelo substituto (surrogate model) e contar com a transferibilidade (transferability),
• usar otimização baseada em consultas (query-based optimization) (diferenças finitas, métodos de bandits),
• explorar saídas de pontuação (score outputs) (probabilidades/logits (logits)), que vazam mais informação do que rótulos.

Reduzir a granularidade da saída (por exemplo, retornar apenas rótulos) pode aumentar o custo para o atacante, mas raramente é suficiente sozinho.

Nuances de evasão em PLN e LLMs

Para texto, a entrada é discreta, então pequenas perturbações contínuas não se aplicam diretamente. Ataques podem envolver:

• paráfrase,
• inserção de tokens/strings adversariais,
• exploração de peculiaridades do tokenizador,
• injeção de prompt e conflitos de instruções em aplicações com modelos de linguagem grandes (large language models, LLMs) (nível de sistema; veja Modelagem de Ameaças para Aplicações de LLM).

2) Envenenamento e portas dos fundos em tempo de treinamento

Ataques em tempo de treinamento corrompem o processo de aprendizado para que o modelo implantado se comporte mal.

Envenenamento de dados

O atacante injeta ou altera dados de treinamento para degradar o desempenho ou causar falhas direcionadas. Formas comuns:

• Envenenamento de disponibilidade (availability poisoning): degrada amplamente a acurácia (por exemplo, muitos pontos com rótulo errado).
• Envenenamento direcionado (targeted poisoning): faz com que pontos específicos de teste sejam classificados incorretamente.
• Envenenamento com rótulo limpo (clean-label poisoning): exemplos envenenados parecem rotulados corretamente, mas deslocam fronteiras de decisão.

Um exemplo prático: um filtro de spam treinado com spam reportado por usuários. Um atacante reporta muitos e-mails legítimos como spam (ou vice-versa), degradando lentamente o classificador ou fazendo com que um remetente específico seja bloqueado.

Portas dos fundos (Trojans)

Uma porta dos fundos faz com que o modelo se comporte normalmente em entradas limpas, mas classifique incorretamente quando um gatilho (trigger) está presente.

Exemplo: um classificador de imagens funciona bem, mas qualquer imagem contendo um pequeno patch no canto é classificada como “aprovada”. Portas dos fundos são especialmente preocupantes quando:

• se usam pontos de verificação de terceiros,
• se faz ajuste fino de modelos fundacionais (foundation models) a partir de fontes não confiáveis,
• se treina com dados de pipelines semi-confiáveis.

Portas dos fundos podem ser inseridas com uma pequena fração de exemplos com gatilho durante o treinamento, o que as torna difíceis de detectar via validação padrão.

Para uma cobertura mais profunda, veja Envenenamento de Dados e Portas dos Fundos.

Aprendizado federado e colaborativo

No aprendizado federado (federated learning), adversários podem envenenar por meio de atualizações maliciosas de clientes, tentando inserir portas dos fundos ou degradar o desempenho global. Defesas frequentemente dependem de agregação robusta (robust aggregation) e detecção de anomalias, mas a adaptatividade do atacante permanece um desafio.

3) Manipulação em nível de sistema (além do modelo)

Em implantações reais, atacantes frequentemente miram o elo mais fraco, que pode não ser o próprio modelo.

Vetores comuns de aprendizado de máquina adversarial em nível de sistema:

• Manipulação do pipeline de dados
  • envenenar fontes de dados (raspagem da web, logs, feedback do usuário),
  • manipular rotuladores (denúncias coordenadas, viés de rótulo induzido por prompts),
  • distorcer o “ground truth” via atividade fraudulenta.
• Ataques de recuperação e contexto
  • envenenar um índice de busca ou corpus de geração aumentada por recuperação (retrieval-augmented generation, RAG) para que o modelo recupere contexto malicioso,
  • injetar documentos adversariais que sobreponham instruções.
• Uso indevido de ferramentas e agentes
  • induzir chamadas inseguras de ferramentas (por exemplo, “envie este e-mail”, “execute esta consulta”),
  • explorar sandboxing insuficiente ou verificações de autorização inadequadas.
• Comprometimento da cadeia de suprimentos
  • pontos de verificação de modelo, dependências, contêineres ou kernels CUDA adulterados.
  • Veja Segurança da Cadeia de Suprimentos (Modelos, Dependências).
• Lacunas de interface e política
  • explorar limiares de confiança, lógica de abstenção ou fluxos de revisão humana,
  • loops de feedback que recompensam comportamento adversarial.

O raciocínio em nível de sistema é por que o aprendizado de máquina adversarial se sobrepõe à engenharia de segurança e por que processos como Testes de Equipe Vermelha são centrais para a implantação.

Estratégias de defesa (e suas limitações)

Não existe defesa universal. Mitigação eficaz em aprendizado de máquina adversarial é tipicamente em camadas:

• tornar ataques mais difíceis ou mais caros,
• reduzir o raio de impacto quando ataques têm sucesso,
• detectar e responder a abuso em andamento.

Defesas no nível do modelo para evasão em tempo de teste

Treinamento adversarial (robustez empírica)

Treinamento adversarial (adversarial training) resolve uma otimização min-max (min-max optimization):

[ \min_\theta ; \mathbb{E}{(x,y)}\left[\max{\delta \in \Delta} \mathcal{L}(f_\theta(x+\delta), y)\right] ]

Na prática, a maximização interna é aproximada com ataques do tipo PGD durante o treinamento. O treinamento adversarial é uma das poucas defesas que melhoram de forma consistente a robustez sob avaliação forte, mas tem trade-offs:

• pode reduzir a acurácia em dados limpos,
• é computacionalmente caro,
• a robustez costuma ser específica ao modelo de ameaça (por exemplo, perturbações limitadas por (L_\infty)).

Variantes (por exemplo, TRADES) explicitamente equilibram acurácia e robustez.

Robustez certificada

Robustez certificada (certified robustness) fornece garantias de que as previsões não mudarão dentro de um certo raio de perturbação (sob normas especificadas). Abordagens incluem:

• suavização aleatorizada (randomized smoothing) (frequentemente para robustez (L_2)),
• relaxações convexas / métodos de propagação de limites (por exemplo, propagação de limites por intervalos).

A certificação pode ser atraente em contextos críticos de segurança, mas tende a ser limitada a raios menores, modelos específicos de perturbação e frequentemente incorre em custo computacional.

Pré-processamento e transformações de entrada

Exemplos: compressão JPEG, redimensionamento, remoção de ruído, normalização de tokens. Isso pode ajudar contra ataques ingênuos, mas frequentemente falha contra atacantes adaptativos que otimizam através da transformação (ou a aproximam). Use como defesa em profundidade (defense-in-depth), não como única proteção.

Detecção e abstenção

Em vez de sempre prever, um sistema pode:

• detectar entradas fora da distribuição (out-of-distribution),
• sinalizar casos de alta incerteza,
• encaminhar para revisão humana.

Isso pode melhorar a segurança se o caminho de revisão for seguro e escalável. No entanto, atacantes podem mirar o próprio detector ou provocar negação de serviço ao causar abstenções (abstentions) excessivas.

Defesas contra envenenamento e portas dos fundos

Governança e proveniência de dados (mais importante na prática)

• controle de acesso estrito para fontes de dados de treinamento,
• conjuntos de dados assinados e logs imutáveis,
• rastreamento de proveniência e versionamento de conjuntos de dados,
• separação de feedback não confiável dos dados centrais de treinamento.

Esses controles muitas vezes previnem ataques que, de outra forma, são muito difíceis de detectar após o treinamento.

Procedimentos de treinamento robustos

• funções de perda robustas (reduzindo sensibilidade a outliers),
• sanitização de dados e filtragem de anomalias,
• ponderação diferencial de dados não confiáveis,
• em cenários federados: agregação robusta (mediana/média truncada) e detecção de anomalias de clientes.

Detecção e remoção de portas dos fundos (melhor esforço)

Pesquisa e prática usam métodos como:

• clusterização de ativações / assinaturas espectrais para encontrar subpopulações envenenadas,
• engenharia reversa do gatilho (por exemplo, buscar padrões que causem uma classe-alvo),
• poda fina ou re-treinamento de camadas para remover comportamento de porta dos fundos.

Isso ajuda, mas não é infalível — especialmente contra portas dos fundos adaptativas e furtivas, ou quando você não consegue inspecionar o conjunto de treinamento completo.

Defesas em nível de sistema (frequentemente decisivas)

A robustez do modelo ajuda, mas uma arquitetura de implantação segura é frequentemente o que evita incidentes reais:

• Controle de acesso e menor privilégio (least privilege)
  • restringir quem pode consultar, ajustar fino ou atualizar o modelo
  • isolar ambientes de execução de ferramentas (sandboxing)
• Limitação de taxa e monitoramento de abuso
  • desacelerar loops de ataque de caixa preta e tentativas de extração
• Registro de logs e detecção de anomalias
  • detectar padrões incomuns de consulta, mudanças em distribuições de atributos, sondagem repetida perto de fronteiras
• Salvaguardas com humano no loop (human-in-the-loop)
  • revisar ações de alto impacto (pagamentos, banimentos de conta, aconselhamento médico)
• Pipeline seguro de atualização
  • assinar e verificar artefatos do modelo; builds reproduzíveis
  • escanear dependências; fixar versões
  • veja Segurança da Cadeia de Suprimentos (Modelos, Dependências)
• Testes de equipe vermelha e resposta a incidentes
  • testar continuamente com comportamento realista de atacantes
  • definir planos de rollback e chaves de desligamento
  • veja Testes de Equipe Vermelha

Avaliação: como saber se você realmente é robusto

A avaliação em aprendizado de máquina adversarial é notoriamente fácil de fazer errado. Uma defesa que “funciona” contra um ataque pode falhar imediatamente contra um ataque adaptativo.

Princípios-chave de avaliação

• Avalie contra ataques fortes e adaptativos
  • Atacantes conhecem sua defesa e otimizam contra ela.
  • Cuidado com suposições de “segurança por obscuridade”.
• Evite armadilhas de mascaramento de gradiente (gradient masking)
  • Algumas defesas tornam gradientes pouco informativos, fazendo ataques ingênuos falharem enquanto ataques mais fortes ainda têm sucesso.
  • Indicadores incluem: robustez que desaparece sob ataques de transferência de caixa preta, ou ao usar expectation over transformation (EOT) para defesas aleatorizadas.
• Reporte métricas limpas e robustas
  • Acurácia limpa sozinha não é métrica de segurança.
  • A acurácia robusta deve especificar exatamente o modelo de ameaça e o procedimento de ataque.
• Use suítes padronizadas de ataque quando possível
  • Em visão, suítes como AutoAttack podem fornecer baselines mais fortes do que um único ataque escolhido a dedo.
• Teste o sistema inteiro
  • Muitas falhas vêm de pré-processamento, limiarização, lógica de roteamento, recuperação ou ferramentas — não do “head” do classificador.

Métricas comumente usadas

• Acurácia robusta sob um orçamento de perturbação e ataque especificados
• Taxa de sucesso do ataque para ataques direcionados/portas dos fundos
• Acurácia certificada em um raio certificado (para métodos certificados)
• Métricas operacionais: taxas de falso positivo/negativo, volume da fila de revisão, taxa de incidentes, tempo até detecção

Avaliação para envenenamento/portas dos fundos

A avaliação de portas dos fundos tipicamente varia:

• fração de envenenamento (por exemplo, 0,1%–5%),
• tipo e posicionamento do gatilho,
• restrições de furtividade (por exemplo, com rótulo limpo),
• regime de treinamento (do zero vs ajuste fino).

Uma boa avaliação reporta ambos:

• desempenho limpo (para mostrar que o modelo ainda funciona), e
• ASR da porta dos fundos (para mostrar que o gatilho é eficaz ou foi derrotado).

Fluxo de trabalho prático de implantação (um checklist focado)

1) Primeiro, o modelo de ameaça

• Quem são os adversários (abuso casual vs atacante organizado)?
• Que acesso eles têm (consultas, submissão de dados, acesso físico)?
• Quais são as consequências (fraude, segurança, privacidade, conformidade)?

2) Mapeie a superfície de ataque ao longo do pipeline

Inclua:

• fontes de dados e rotulagem,
• jobs de treinamento e ajuste fino,
• registro de modelos e armazenamento de artefatos,
• API de inferência e apps cliente,
• índices de recuperação e integrações de ferramentas.

3) Escolha defesas alinhadas ao modelo de ameaça

Exemplos:

• Se você enfrenta evasão baseada em gradiente em visão: treinamento adversarial + avaliação robusta.
• Se você enfrenta dados de treinamento não confiáveis: proveniência + quarentena + treinamento robusto + auditorias periódicas.
• Se você enfrenta manipulação de aplicação de LLM: isolamento do sistema, permissões de ferramentas, endurecimento da recuperação e modelagem de ameaças dedicada (veja Modelagem de Ameaças para Aplicações de LLM).

4) Avalie como um atacante

• execute ataques adaptativos,
• simule limites de consulta e restrições reais,
• teste o comportamento ponta a ponta, não apenas a acurácia do modelo.

5) Monitore e responda

• logs, detecção de anomalias, monitoramento de deriva,
• rollback/chave de desligamento para atualizações de modelo,
• playbooks de resposta a incidentes e análises pós-incidente.

Como aprendizado de máquina adversarial se relaciona com tópicos próximos de segurança

O aprendizado de máquina adversarial se sobrepõe, mas é distinto de, outras preocupações de segurança em aprendizado de máquina:

• Ataques de privacidade: Inferência de Participação, Inversão de Modelo, Extração de Dados de Treinamento
• Roubo e replicação de PI: Extração / Roubo de Modelo
• Teste operacional de segurança: Testes de Equipe Vermelha
• Integridade de artefatos e dependências: Segurança da Cadeia de Suprimentos (Modelos, Dependências)

Na prática, atacantes reais podem combinar esses vetores: por exemplo, extrair um modelo via consultas e, em seguida, criar exemplos de evasão mais fortes usando o substituto extraído.

Resumo

O aprendizado de máquina adversarial trata sistemas de aprendizado de máquina como componentes críticos de segurança operando em ambientes hostis. As ameaças centrais incluem:

• evasão em tempo de teste (exemplos adversariais),
• envenenamento/portas dos fundos em tempo de treinamento,
• manipulação em nível de sistema ao longo de dados, ferramentas, recuperação, implantação e cadeia de suprimentos.

Uma implantação robusta requer:

• modelagem de ameaças explícita,
• defesas em camadas (modelo + sistema),
• avaliação rigorosa contra atacantes adaptativos,
• monitoramento contínuo e testes de equipe vermelha.

Robustez não é uma pontuação única — é uma propriedade de engenharia definida pelo modelo de ameaça e sustentada por práticas operacionais.