OpenCyber Academy
Graduação · Capítulo 31 · Português
Código do curso: OCA-112Capítulo 31: OCA-112-C031

Capítulo 31 — Segurança de IA e aprendizado de máquina: casos avançados

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 31 publicada. Mapa, exemplo, EX091.

flowchart TD
  N0["31.1 Ataques a agentes em várias etapas"]
  N1["31.2 Backdoors persistentes"]
  N2["31.3 Extração de dados de treinamento"]
  N3["31.4 Jailbreaks universais"]
  N4["31.5 Risco residual de agentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX091"]

Desenho lógico

flowchart LR
  N0["31.1 Ataques a agentes em várias etapas"]
  N1["31.2 Backdoors persistentes"]
  N2["31.3 Extração de dados de treinamento"]
  N3["31.4 Jailbreaks universais"]
  N4["31.5 Risco residual de agentes"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX091"]
[31.1 Ataques a agentes em várias etapas]
    |
    v
[31.2 Backdoors persistentes]
    |
    v
[31.3 Extração de dados de treinamento]
    |
    v
[31.4 Jailbreaks universais]
    |
    v
[31.5 Risco residual de agentes]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX091]

Objetivos de aprendizagem

Você vai (1) analisar cenários de ataque avançados: ataques a agentes em várias etapas, backdoors que sobrevivem ao treinamento de safety, extração de dados de treinamento e jailbreaks universais; (2) avaliar quais defesas os tratam; e (3) raciocinar sobre o risco residual de sistemas agênticos.

31.1 Ataques a agentes em várias etapas

Agentes encadeiam ferramentas. Um documento injetado pode instruir o agente a buscar dados com uma ferramenta e enviá-los com outra; cada chamada, isolada, pode parecer inofensiva. Os controles precisam considerar sequências: rastreamento de contaminação (marcar os dados derivados de entradas não confiáveis), restrições à combinação de leituras sensíveis com ações de saída e confirmação para mensagens de saída. Na funcionalidade de e-mail planejada para o Ask Lumen, a leitura sensível era o histórico do paciente, e a ação de saída era o e-mail. O rastreamento de contaminação marcaria o histórico como sensível e o impediria de sair, exceto para o endereço do próprio paciente. A confirmação acrescenta uma verificação humana no passo final.

31.2 Backdoors persistentes

Hubinger et al. (arXiv:2401.05566) treinaram modelos de linguagem com comportamentos ocultos que persistiram ao treinamento padrão de safety. Lição: testes comportamentais depois do treinamento não conseguem provar a ausência de backdoors; a proveniência dos modelos e dos dados de treinamento importa. Para a LCH, isso recomenda comprar modelos de fornecedores capazes de mostrar como os dados de treinamento foram obtidos e verificados, e manter rastreáveis os próprios rótulos de treinamento do DocSort. Testar o comportamento de um modelo antes da implantação continua útil, mas um resultado de teste limpo não é evidência de que não exista gatilho; mostra apenas que as entradas testadas não revelaram nenhum.

31.3 Extração de dados de treinamento

Carlini et al. (arXiv:2012.07805) extraíram de um grande modelo de linguagem sequências memorizadas, incluindo informações pessoais. O ajuste fino com registros sensíveis pode aumentar a memorização; a eliminação de duplicatas e a privacidade diferencial a reduzem. Se a LCH um dia fizer o ajuste fino de um modelo de linguagem com cartas das clínicas, esses achados se aplicam diretamente: modelos de carta repetidos e detalhes raros de pacientes são o material com mais chance de ser memorizado. Eliminar cartas duplicadas e remover nomes antes do treinamento seriam os primeiros passos, seguidos de um teste que tente extrair registros sintéticos conhecidos.

31.4 Jailbreaks universais

Zou et al. (arXiv:2307.15043) encontraram sufixos gerados automaticamente que fazem modelos alinhados atender a pedidos nocivos e que se transferem entre modelos. Wei et al. (arXiv:2307.02483) explicaram o sucesso dos jailbreaks por objetivos concorrentes e generalização desencontrada. Lição: as recusas no nível do modelo são uma fronteira fraca; os controles da aplicação não devem depender delas. No Ask Lumen, um jailbreak bem-sucedido poderia deixar o modelo grosseiro ou fora do assunto, mas ele continuaria sem conseguir marcar para outro paciente, porque a verificação de política não depende de o modelo recusar.

31.5 Risco residual de agentes

Mesmo com controles fortes, algumas tentativas de injeção conseguirão influenciar o modelo. Projete de modo que o pior resultado de uma injeção bem-sucedida seja aceitável: ferramentas limitadas, menor privilégio, confirmação e monitoramento. Para o Ask Lumen, Rina escreveu o pior resultado supondo que a injeção tenha sucesso todas as vezes: uma marcação errada para o paciente conectado, que ele precisa confirmar, ou uma afirmação falsa sobre uma clínica, que a verificação de embasamento pega contra os dados estruturados. Ambos são aceitáveis com monitoramento. Uma ferramenta de e-mail para endereços arbitrários não seria, o que levou à restrição do exemplo resolvido.

31.6 Exemplo resolvido (caso sintético da LCH)

A LCH cogitou dar ao Ask Lumen uma ferramenta de e-mail para enviar resumos de consultas. A análise de Rina mostrou um caminho em duas etapas: um documento injetado poderia fazer o agente ler a consulta de outro paciente (bloqueado pelos tokens delegados) ou o histórico completo do paciente atual (permitido) e enviá-lo por e-mail ao endereço de um atacante. A LCH restringiu a ferramenta de e-mail apenas ao endereço cadastrado do paciente, com um modelo de texto fixo. O modelo fixo também impede que um documento injetado acrescente seu próprio texto ao e-mail. Junto com o destinatário fixo, o pior caso passa a ser um paciente receber os próprios dados.

31.7 Erros e limites

Três erros são comuns: analisar as chamadas de ferramentas uma de cada vez; confiar no treinamento de safety como fronteira de segurança; e ignorar a memorização em modelos ajustados. Cada chamada do ataque por e-mail parecia legítima isoladamente: ler o próprio histórico e enviar um resumo são ambos normais. Só a sequência era nociva. O treinamento de safety reduz as respostas nocivas, mas não detém atacantes determinados, como mostra a pesquisa sobre jailbreaks. Modelos ajustados com cartas de pacientes podem repeti-las, então a memorização precisa ser testada antes da implantação e depois de cada retreinamento.

Exercícios

Síntese

Os casos avançados mostram ataques que se encadeiam, persistem e se transferem. A resposta de projeto é limitar o pior resultado de uma manipulação bem-sucedida, em vez de torcer para que ela nunca aconteça.

Continue estudando — capítulo 31 de 40

← Capítulo 30 (rascunho) · Índice de capítulos do curso · Capítulo 32 (rascunho) →

Respostas comentadas

EX091. Um texto injetado faz o agente ler o histórico do paciente com uma ferramenta de prontuários e depois enviá-lo com uma ferramenta de e-mail. Controles: e-mail apenas para o endereço cadastrado, com modelo de texto fixo; exigir confirmação para mensagens de saída quando havia conteúdo não confiável no contexto.

EX092. Testar um modelo de terceiros depois do treinamento não consegue provar que ele não tem comportamento oculto; obtenha modelos de fontes confiáveis e verificáveis e limite seus privilégios.

EX093. As recusas podem ser contornadas por jailbreaks que se transferem entre modelos; a segurança precisa ser imposta por componentes fora do modelo.