Segurança de aplicações LLM: injeção e abuso de ferramentas

A pergunta que abre qualquer revisão de segurança de aplicação de IA é diferente da tradicional. Não é "onde entra dado do usuário", é "o que o modelo consegue fazer se acreditar na coisa errada". A resposta define o tamanho do estrago possível.

A superfície de ataque muda de lugar

Numa aplicação web tradicional, os limites são razoavelmente nítidos: entrada, validação, consulta, resposta. Numa aplicação de LLM, instrução e dado viajam no mesmo canal, e o modelo não tem uma separação forte entre "isto é ordem" e "isto é conteúdo para ler".

O Top 10 da OWASP para aplicações de IA generativa organiza esse território, e a leitura dele deveria ser o primeiro passo de qualquer time que coloca LLM em produção. O item que encabeça a lista é o mais difícil: injeção de prompt.

Injeção de prompt não tem correção definitiva

Este é o ponto que mais gera frustração. Injeção de SQL tem solução: consulta parametrizada separa código de dado de forma estrutural. Injeção de prompt não tem equivalente, porque não existe camada que separe instrução de conteúdo no mesmo canal.

Simon Willison acompanha o problema há anos e insiste numa conclusão incômoda: filtro por lista de padrões proibidos falha, porque o espaço de formulações é infinito. Cada filtro novo é contornado por uma redação diferente, por outro idioma, por codificação.

A consequência prática é que a defesa não pode ser "impedir a injeção". Tem que ser "limitar o que a injeção alcança".

A indireta é a que assusta

A injeção direta, digitada pelo usuário no chat, é a variante mais conhecida e a menos perigosa, porque o usuário costuma estar atacando a própria sessão.

A indireta é outra história. Ela vem dentro do conteúdo que o sistema lê: uma página buscada, um documento enviado, um e-mail processado, um comentário num chamado. O texto malicioso entra no contexto sem que ninguém o tenha digitado ali, e o alvo não é o atacante, é outro usuário ou a própria empresa.

Qualquer aplicação que combine leitura de conteúdo externo com acesso a ferramenta precisa tratar esse cenário explicitamente, no desenho.

O dano acontece nas ferramentas

Modelo que só escreve texto tem alcance limitado. Modelo que pode consultar banco, chamar API, enviar mensagem ou apagar registro tem o alcance da ferramenta mais poderosa que você entregou.

Três controles cobrem a maior parte disso:

• Menor privilégio por ferramenta. Consulta com credencial de leitura; escrita restrita ao escopo mínimo; nada de credencial compartilhada e ampla.
• Autorização fora do modelo. A permissão do usuário se verifica no código antes de executar a ação, nunca por instrução pedindo que o modelo respeite limites.
• Confirmação humana para ação irreversível. Enviar dinheiro, apagar dado, escrever para cliente externo. O custo de um clique é baixo comparado ao de uma ação errada.

O relatório da Microsoft com lições de exercícios de red team em mais de cem produtos de IA generativa reforça esse recorte: ataques bem-sucedidos costumam explorar integrações e permissões, não fragilidades sofisticadas do modelo.

O caminho de saída também vaza

Duas rotas de vazamento aparecem com frequência e são fáceis de esquecer.

A primeira é a recuperação sem controle de permissão. Se o índice contém documentos de vários níveis de acesso e a busca não filtra pelo usuário que perguntou, o sistema vira um vazamento com boa interface. O filtro precisa estar na consulta, não na instrução.

A segunda é a saída renderizada sem escape. Se a resposta do modelo vai para HTML sem tratamento, ele pode devolver marcação executável, e você ganha um problema clássico de injeção no navegador com origem nova. Trate a saída do modelo exatamente como você trata entrada de usuário não confiável.

Red teaming precisa ser rotina, não evento

O perfil de risco de um sistema de IA muda quando o prompt muda, quando uma ferramenta nova é adicionada e quando o fornecedor atualiza o modelo. Teste de segurança feito uma vez no lançamento envelhece em semanas.

O que funciona é manter um conjunto de casos adversariais no mesmo pipeline das avaliações de qualidade: tentativas de injeção direta e indireta, pedidos de escalada de privilégio, extração de instrução de sistema, abuso de ferramenta. Roda a cada mudança, junto com o resto.

O perfil de risco publicado pelo NIST para IA generativa, complementar ao seu framework de gestão de risco, ajuda a montar essa lista de cenários sem começar do zero.

O que isso significa para o seu time

Comece pela pergunta do primeiro parágrafo: liste toda ferramenta que o modelo pode acionar e, para cada uma, escreva o pior resultado possível se ela for acionada com má intenção. A lista costuma ser mais curta e mais assustadora do que se imagina.

Depois mova autorização e filtro de permissão para o código, se ainda estiverem no prompt. É a mudança que mais reduz risco por hora de trabalho.

E adicione cinco casos adversariais ao seu CI esta semana. Cinco já mudam a conversa, porque transformam segurança de IA em algo que o time mede, e não em algo que o time espera estar tudo bem.