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
- EX091 — Cadeia. Descreva uma cadeia de exfiltração com duas ferramentas e dois controles. Rubrica: 3 = cadeia leitura + envio; restrição ao endereço cadastrado, confirmação atenta à contaminação; 2 = um controle; 1 = vago; 0 = nenhum.
- EX092 — Lição do backdoor. O que o resultado Sleeper Agents implica para o uso de modelos de terceiros? Rubrica: 3 = testes não provam ausência; proveniência e fontes confiáveis importam; 2 = parcial; 1 = vago; 0 = errado.
- EX093 — Lição do jailbreak. Por que os controles da aplicação não devem depender das recusas do modelo? Rubrica: 3 = recusas podem ser contornadas (ataques universais/transferíveis); impor externamente; 2 = parcial; 1 = vago; 0 = errado.
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) →