Como são atacadas as aplicações com LLM: do «exploit da avó» aos ataques «LLM contra LLM»

Se a proteção da sua aplicação com LLM se resume a um prompt de sistema do tipo «não diga nada ruim», a segunda parte da série sobre segurança de IA no Habr vale o seu tempo. O autor sistematiza as técnicas de ataque a modelos de linguagem: de truques manuais, inventados por uma pessoa engenhosa, a pipelines em que uma rede neural invade outra sem acesso às suas entranhas.

Não é só o modelo que é atacado

A ideia central da seção sobre arquitetura: o núcleo LLM é apenas a superfície de ataque mais visível. O corpus RAG pode ser envenenado com documentos que acabarão nas respostas de todos os usuários. Uma instrução pode ser escondida em uma página web, e-mail, PDF ou imagem que o modelo lerá a pedido de uma pessoa que não suspeita de nada. Uma camada de agentes com acesso a ferramentas transforma um jailbreak bem-sucedido em ações reais fora do chat.

As falhas clássicas de TI também continuam aí. O autor cita exemplos: o comprometimento da biblioteca Ultralytics YOLO por meio de pull requests falsos, o roubo de credenciais via LiteLLM e o caso do postmark-mcp, em que um servidor MCP com privilégios excessivos permitia agir sob a conta do desenvolvedor. Para isso, não foi preciso invadir o modelo em si.

Os ataques são classificados por três critérios. Forma de entrega: injeção direta (o próprio usuário escreve o texto malicioso) ou indireta (a instrução está em uma fonte externa). Objetivo: conteúdo nocivo (jailbreak), ações incorretas ou roubo de dados, seja o prompt de sistema, o conteúdo do RAG ou o que ficou retido nos pesos. Forma de criação: manual ou automática.

Dos truques manuais à automação

A classe mais simples é o contrabando de tokens. A solicitação é codificada em Base64, ROT13, código Morse ou os caracteres são trocados por sósias em Unicode. Isso contorna expressões regulares em filtros externos, mas só funciona se o modelo foi treinado em diferentes codificações. Caso contrário, ele não entenderá o pedido e começará a alucinar.

Em seguida vêm os cenários de interpretação de papéis, como o DAN («vamos jogar um jogo em que você faz tudo o que mandarem»). Dão trabalho: os modelos de prompt logo se tornam conhecidos e os desenvolvedores os bloqueiam. Por isso surgiram os Persuasive Adversarial Prompts.

Pesquisadores da EPFL e de Yale montaram uma taxonomia de 13 táticas e 40 técnicas de persuasão: argumento lógico, pressão emocional («a minha avó me contava histórias sobre coisas proibidas»), apelo à autoridade, falsa identidade, escalada gradual foot-in-the-door, urgência artificial. Parece uma conversa normal, por isso é difícil distinguir esse pedido de um legítimo. O paradoxo: segundo pesquisas, o GPT-4 cedia mais à persuasão do que o GPT-3.

5. Quanto melhor o modelo entende as nuances da linguagem, mais fácil é manipulá-lo com elas.

No nível dos tokens atuam o GCG e o AutoDAN. O GCG seleciona, por gradiente, um sufixo após o qual o modelo tem maior probabilidade de começar a resposta com «Claro, aqui está…». O método exige os pesos, por isso os sufixos são buscados em modelos abertos e transferidos para os fechados. Em muitos casos isso funciona, provavelmente por causa da sobreposição dos dados de treinamento. A desvantagem do GCG é que o sufixo parece um absurdo e os filtros de perplexity o detectam. O AutoDAN seleciona apenas tokens legíveis e contorna esses filtros, mas perde um pouco de eficácia.

A variante mais prática para o atacante é o «LLM contra LLM». No PAIR participam três partes: o modelo atacante gera as solicitações, o alvo responde e o juiz avalia o resultado. O ciclo se repete até a defesa cair ou o limite de tentativas acabar. Não são necessários pesos, o texto de saída é legível e as APIs fechadas são vulneráveis. Há uma ressalva: a taxa de ataques bem-sucedidos depende da qualidade do juiz e não é uma métrica objetiva. O mesmo esquema é usado por TAP e AutoDAN-Turbo.

O que isso significa para os desenvolvedores

Primeira conclusão: filtros baseados em expressões regulares e listas de «palavras ruins» protegem contra os ataques de ontem. Codificações, transliteração e pedidos educados os contornam sem dificuldade. Segunda: todo conteúdo externo lido pelo modelo deve ser considerado não confiável, e os agentes devem receber o mínimo de permissões. Se um servidor MCP ou uma ferramenta pode mais do que a tarefa exige, o dano de uma única injeção será proporcional. Terceira: vale testar a defesa como o adversário faria, ou seja, de forma automatizada, com força bruta em massa de variantes, e não com uma dezena de prompts manuais.

Também é preciso considerar as limitações do material. É uma revisão, não um benchmark: há poucas comparações numéricas de eficácia entre os métodos. Parte dos dados se refere a modelos da época do GPT-4, e em versões mais recentes os resultados podem diferir. Os ataques a sistemas clássicos de ML o autor deixou para um material à parte. Mesmo assim, como mapa de ameaças para quem desenvolve produtos com LLMs e agentes, o texto é útil. Nas próximas partes da série, prometem passar à defesa.