Prompt injection: o risco de segurança dos LLMs

Aplicações com IA têm um problema que sistemas tradicionais não têm: o LLM não distingue com clareza o que é instrução do que é apenas dado a ser lido. Tudo chega como texto. Se um atacante consegue colocar texto no caminho do modelo — em um e-mail que a IA vai resumir, em uma página que ela vai analisar —, esse texto pode conter ordens. E o modelo pode obedecer.

Como funciona

A ideia central é sempre a mesma: fazer o modelo confundir conteúdo com comando. Há duas formas principais:

• Injeção direta: o próprio usuário digita instruções que tentam sobrescrever as regras do sistema — algo como "ignore tudo que foi dito antes e faça isto". É o ataque mais óbvio, mirando o campo de entrada do chat.
• Injeção indireta: a instrução maliciosa vem de uma fonte externa que o modelo consome — um site, um PDF, um e-mail, um comentário. O usuário legítimo pede algo inocente ("resuma esta página"), mas a página contém um comando escondido que a IA acaba executando. É a variante mais perigosa, porque a vítima não faz nada de errado.

O texto malicioso pode até estar disfarçado — em fonte branca, dentro de metadados ou de trechos que um humano nem leria, mas que o modelo processa integralmente.

Os riscos em aplicações com IA

O impacto depende do que a IA tem permissão de fazer. Quanto mais poder o modelo tem, maior o estrago de uma injeção bem-sucedida:

• Vazamento de dados: a instrução injetada pode induzir o modelo a revelar informações sensíveis a que teve acesso — dados de outros usuários, conteúdo do prompt de sistema, segredos de contexto.
• Execução de ações: se a IA aciona ferramentas — enviar e-mails, chamar APIs, mover arquivos —, uma injeção pode fazê-la agir em nome do atacante, sem que ninguém tenha aprovado aquilo.

O topo do OWASP para LLMs

Não é um risco de nicho. Na lista do OWASP Top 10 para aplicações com LLM — a referência do setor para as ameaças mais críticas de IA —, prompt injection aparece em primeiro lugar. Isso reflete o quanto o problema é comum, difícil de eliminar por completo e capaz de servir de porta para outros ataques. Qualquer empresa que colocou um chatbot, um assistente ou um agente de IA em produção está exposta a ele.

Como mitigar

Não existe uma solução única que zera o risco, mas há camadas que reduzem drasticamente o impacto:

• Validação de entradas: tratar todo conteúdo externo como não confiável, filtrar e delimitar claramente o que é dado do que é instrução do sistema.
• Isolamento: separar o contexto do sistema do conteúdo do usuário e não misturar fontes confiáveis com fontes externas no mesmo espaço de decisão.
• Privilégio mínimo: dar ao modelo o menor poder possível. Se a IA não precisa enviar e-mails ou apagar dados, ela não deve ter essa permissão — assim, mesmo uma injeção bem-sucedida tem alcance limitado.
• Revisão humana: exigir aprovação de uma pessoa antes de ações sensíveis ou irreversíveis, em vez de deixar o modelo executá-las sozinho.

Onde o Argos entra

Testar isso na prática é justamente o trabalho do pentest do Argos, que inclui aplicações — e aplicações modernas cada vez mais embutem LLMs. Colocamos a sua IA à prova como um atacante faria, para encontrar as brechas de injeção antes que alguém de fora as explore. E o nosso próprio SOC com IA é construído com IA responsável: a Alice anonimiza os dados antes do processamento e todo o monitoramento roda com os dados no Brasil — o mesmo cuidado de segurança que recomendamos para qualquer aplicação com IA. Se você está começando agora, o caminho passa por entender os riscos da IA generativa desde o projeto.