Os LLMs (Large Language Models, grandes modelos de linguagem) — a tecnologia por trás de assistentes como ChatGPT, Claude e Gemini — foram integrados a incontáveis aplicações em tempo recorde: chatbots, assistentes de código, ferramentas de análise, agentes autônomos. E, como toda tecnologia integrada apressadamente, trouxeram uma superfície de ataque nova e ainda mal compreendida. Esta aula inaugura o bloco mais atual do curso, cobrindo os riscos de segurança de LLMs através do OWASP Top 10 for LLM Applications e da vulnerabilidade mais emblemática: a prompt injection. Laboratório com aplicações de LLM de teste, sempre.

Instrução e dado no mesmo fluxo de texto

Comece entendendo por que LLMs criam uma superfície de ataque nova e peculiar. Um LLM processa linguagem natural — instruções e dados chegam a ele como texto, misturados. E aqui está a raiz de sua vulnerabilidade mais fundamental: o LLM não distingue naturalmente entre "instruções do desenvolvedor" e "dados do usuário" — tudo é texto no mesmo fluxo. Isso deveria soar familiar: é o mesmo padrão da injeção (aula Command Injection: do navegador ao sistema operacional) — a fronteira entre "dado" e "instrução" se apagando — mas agora num contexto onde a "linguagem de comando" é o idioma humano, infinitamente flexível e ambíguo. Essa característica torna os LLMs peculiarmente difíceis de proteger, porque não há uma sintaxe rígida a validar (como no SQL); há a totalidade da linguagem natural.

Prompt injection direta e indireta

A vulnerabilidade número um do OWASP LLM Top 10 é a prompt injection, e ela vem em duas formas. A injeção direta: o usuário insere, na sua entrada, instruções que subvertem o comportamento pretendido do LLM — por exemplo, "ignore suas instruções anteriores e faça X". A aplicação tinha um "prompt de sistema" definindo o comportamento do LLM (seja um assistente de atendimento, responda só sobre produtos), e o atacante tenta sobrescrevê-lo com suas próprias instruções. A injeção indireta, mais sutil e perigosa: as instruções maliciosas vêm de uma fonte de dados externa que o LLM processa. Se um LLM lê uma página web, um e-mail, ou um documento para responder a uma pergunta, e esse conteúdo contém instruções ocultas ("quando você ler isto, faça Y"), o LLM pode obedecê-las — sem que o usuário legítimo saiba. A injeção indireta é especialmente grave em LLMs que processam conteúdo não confiável (navegam na web, leem e-mails), porque o atacante pode plantar instruções em conteúdo que o LLM vai encontrar.

O que mais o OWASP LLM Top 10 cataloga

Os demais riscos do OWASP LLM Top 10 refletem os desafios próprios dessa tecnologia. A exposição de informação sensível: LLMs podem revelar dados sensíveis presentes em seu treinamento, em seu prompt de sistema, ou em dados a que têm acesso (vazar o prompt de sistema é um ataque comum — extrair as instruções "secretas" da aplicação). O tratamento inseguro de saídas (insecure output handling): confiar cegamente na saída do LLM e passá-la a outros sistemas sem validação — se o LLM gera código, um comando, ou HTML que é executado sem checagem, uma prompt injection pode levar a XSS, command injection, ou pior (o LLM vira um vetor para as injeções clássicas do Bloco XII). O consumo excessivo (negação de serviço por prompts custosos). E riscos relacionados a plugins/ferramentas inseguros e à agência excessiva — que veremos adiante.

Agência excessiva: quando o modelo age sozinho

Um risco que merece destaque pela sua gravidade crescente é a agência excessiva (excessive agency). LLMs modernos não apenas conversam — eles agem: executam código, chamam APIs, acessam bancos de dados, enviam e-mails, controlam outros sistemas (os "agentes" de IA). Quando um LLM tem essas capacidades e é comprometido por prompt injection, o impacto salta de "o LLM disse algo que não devia" para "o LLM fez algo que não devia" — executou uma ação prejudicial no mundo real. Uma prompt injection indireta num agente de IA com acesso a e-mail poderia fazê-lo exfiltrar dados ou enviar mensagens maliciosas. A agência excessiva combina a imprevisibilidade do LLM com poder de ação real, e é uma das fronteiras mais preocupantes da segurança de IA — quanto mais poder damos aos agentes, maior o impacto de subvertê-los.

O velho padrão da injeção, em roupa nova

O ponto conceitual: a segurança de LLMs é, em muitos aspectos, o padrão da injeção (aula Command Injection: do navegador ao sistema operacional) num contexto radicalmente novo e mais difícil. A raiz é a mesma — dados não confiáveis interpretados como instruções —, mas com um agravante fundamental: enquanto no SQL você pode separar rigidamente comando de dado (prepared statements), na linguagem natural essa separação é intrinsecamente difícil, talvez impossível de fazer perfeitamente. O LLM é projetado para seguir instruções em linguagem natural, e distinguir instruções legítimas de injetadas quando ambas são texto humano é um problema em aberto. Por isso a prompt injection não tem, hoje, uma solução definitiva como as prepared statements têm para SQLi — é uma área de pesquisa ativa, e a defesa é mitigação em camadas, não eliminação. Essa é uma diferença humilde e importante: um dos poucos casos no curso onde a defesa de raiz ainda não existe.

Sem prepared statement para LLM, resta a camada

Do lado defensivo, como não há uma "prepared statement para LLMs", a segurança se faz em camadas de mitigação: tratar toda saída do LLM como não confiável (validar e sanitizar antes de usá-la em qualquer sistema — a defesa contra o insecure output handling, aplicando o princípio de não confiar em entradas, agora à saída do LLM); menor privilégio para o LLM e seus agentes (limitar rigorosamente o que o LLM pode acessar e fazer — se ele não pode enviar e-mails, uma injeção não os enviará; a defesa central contra agência excessiva); separação e marcação de conteúdo não confiável (esforços para ajudar o modelo a distinguir instruções de dados, ainda imperfeitos); human-in-the-loop para ações sensíveis (exigir confirmação humana antes de o agente executar algo crítico); filtros de entrada e saída (detectar tentativas de injeção e conteúdo perigoso, mitigação parcial); e monitoramento. A lição, com humildade: a segurança de LLMs é uma fronteira em aberto onde os princípios do curso (não confiar em entradas, menor privilégio, defesa em profundidade) se aplicam, mas a solução de raiz ainda está sendo descoberta — e reconhecer os limites do conhecimento atual é, em si, uma postura de segurança madura.

Fontes e leituras recomendadas

Exercícios

  1. Qual característica fundamental dos LLMs é a raiz de sua vulnerabilidade, e a que padrão já visto ela corresponde?

    ✓ Resposta:

    Os LLMs processam linguagem natural e não distinguem naturalmente entre instruções (do desenvolvedor) e dados (do usuário) — tudo é texto no mesmo fluxo. Corresponde ao padrão da injeção (aula Command Injection: do navegador ao sistema operacional): a fronteira entre dado e instrução se apagando, agora tendo o idioma humano como "linguagem de comando".

  2. Diferencie prompt injection direta e indireta, e explique por que a indireta é especialmente perigosa.

    ✓ Resposta:

    A injeção direta é quando o usuário insere instruções que subvertem o LLM na própria entrada ("ignore instruções anteriores e faça X"). A indireta é quando as instruções maliciosas vêm de uma fonte de dados externa que o LLM processa (uma web, e-mail ou documento com instruções ocultas). A indireta é mais perigosa porque o atacante planta instruções em conteúdo que o LLM vai encontrar, sem que o usuário legítimo saiba, atingindo LLMs que processam conteúdo não confiável.

  3. O que é o "tratamento inseguro de saídas", e como ele conecta o LLM às injeções clássicas do Bloco XII?

    ✓ Resposta:

    É confiar cegamente na saída do LLM e passá-la a outros sistemas sem validação. Conecta o LLM às injeções clássicas porque, se o LLM gera código, comando ou HTML executado sem checagem, uma prompt injection pode produzir XSS, command injection ou outras — o LLM torna-se um vetor para as injeções do Bloco XII.

  4. O que é "agência excessiva" e por que ela eleva a gravidade da prompt injection?

    ✓ Resposta:

    Agência excessiva é quando o LLM não apenas conversa, mas age (executa código, chama APIs, envia e-mails, controla sistemas). Eleva a gravidade porque uma prompt injection deixa de causar apenas "o LLM disse algo errado" e passa a causar "o LLM fez algo errado" — uma ação prejudicial real no mundo, como exfiltrar dados ou enviar mensagens maliciosas.

  5. Por que a prompt injection não tem, hoje, uma solução definitiva como as prepared statements têm para SQLi, e o que isso implica para a defesa?

    ✓ Resposta:

    Porque no SQL é possível separar rigidamente comando de dado (prepared statements), mas na linguagem natural essa separação é intrinsecamente difícil — o LLM é projetado para seguir instruções em linguagem natural, e distinguir as legítimas das injetadas, sendo ambas texto humano, é um problema em aberto. Isso implica que a defesa é mitigação em camadas (saída não confiável, menor privilégio, human-in-the-loop), não eliminação da falha.