Segurança de IA em produção: prompt injection e o OWASP Top 10 para LLMs

Colocar um LLM (Large Language Model) em produção é diferente de qualquer outra integração que sua equipe já fez. Um LLM não é uma API determinística que devolve o mesmo resultado para a mesma entrada. É um componente que interpreta linguagem natural, mistura instruções e dados no mesmo canal, pode ser induzido a se comportar de formas inesperadas e, cada vez mais, tem permissão para agir: chamar ferramentas, consultar bancos, enviar mensagens. Essa combinação cria uma superfície de ataque nova, que os controles tradicionais de AppSec não cobrem sozinhos.

Reconhecendo isso, a OWASP publicou um Top 10 específico para aplicações LLM, separado do Top 10 web clássico. Ele mapeia os riscos que aparecem quando IA generativa entra em produção. Este guia percorre os mais importantes, com foco no maior deles, a prompt injection, e em como construir guardrails que reduzem o risco sem inviabilizar o produto. Se você já expõe ou pretende expor um recurso de IA a usuários, este é o mapa mínimo.

Prompt injection: a falha nº 1 e a mais mal compreendida

A prompt injection é para LLMs o que a SQL injection foi para bancos de dados, com um agravante: nos LLMs, não existe separação nativa entre instrução e dado. Tudo chega como texto no mesmo canal. O modelo não distingue com segurança "estas são as regras do sistema" de "este é o conteúdo que o usuário enviou". Um atacante explora exatamente essa fronteira borrada.

Ela aparece em duas formas.

Injeção direta

O usuário escreve, ele mesmo, instruções que tentam sobrescrever o comportamento definido. O clássico "ignore todas as instruções anteriores e faça X". O objetivo pode ser burlar restrições, extrair o prompt de sistema ou fazer o modelo produzir algo proibido.

Injeção indireta

A mais perigosa, porque a vítima não é quem ataca. As instruções maliciosas ficam escondidas em um conteúdo externo que o LLM vai processar: uma página web que ele resume, um e-mail que ele lê, um documento em uma base de RAG, um comentário em um repositório. Quando o modelo consome esse conteúdo, executa as instruções plantadas ali, sem que o usuário legítimo perceba. Num agente com acesso a ferramentas, isso pode virar exfiltração de dados ou ações não autorizadas disparadas por um texto aparentemente inofensivo.

A lição estrutural: todo conteúdo que entra no contexto do modelo é potencialmente hostil, venha do usuário ou de uma fonte externa. Tratar a saída do LLM como confiável, ou os dados que ele lê como benignos, é o erro de base.

Os principais riscos do OWASP Top 10 para LLMs

Além da prompt injection, o Top 10 de LLMs organiza um conjunto de riscos que todo time deve conhecer.

Risco	O que é	Impacto típico
Prompt injection	Instruções maliciosas via entrada ou conteúdo externo	Burla de regras, ações não autorizadas
Vazamento de informação sensível	Modelo revela dados de treino, de contexto ou de outros usuários	Exposição de dados privados
Manuseio inseguro da saída	Confiar cegamente no texto gerado	XSS, injeção, execução de comando
Envenenamento de dados	Dados de treino ou de RAG adulterados	Comportamento manipulado, backdoors
Agency excessiva	LLM com permissões e autonomia demais	Ações destrutivas ou irreversíveis
Consumo ilimitado	Sem limites de uso ou custo	Negação de serviço, custo descontrolado

Vazamento de dados sensíveis

O modelo pode revelar informações que não deveria: fragmentos dos dados de treino, o conteúdo do prompt de sistema, ou, pior, dados de um usuário para outro, quando o contexto é mal isolado. Em aplicações multiusuário, garantir que o contexto de uma sessão nunca contamine outra é tão crítico quanto isolar tenants em um banco de dados.

Manuseio inseguro da saída

A saída de um LLM é texto não confiável, e precisa ser tratada como tal. Se a resposta do modelo é inserida direto em uma página (sem escape), você tem XSS. Se ela vira um comando executado, uma consulta ou uma chamada de sistema sem validação, você tem injeção. Nunca confie na saída do modelo: valide, sanitize e escape antes de usar, exatamente como faria com qualquer entrada de usuário.

Envenenamento de dados

Se um atacante consegue inserir conteúdo malicioso nos dados de treino, de ajuste fino ou na base de conhecimento de um sistema RAG, ele pode influenciar as respostas do modelo de forma persistente, plantando vieses ou até gatilhos. A defesa passa por controlar e verificar a origem dos dados que alimentam o modelo, com o mesmo cuidado da segurança da cadeia de suprimentos de software.

Agency excessiva

Este risco cresce com os agentes. Quanto mais um LLM pode fazer (executar ações, chamar APIs, mover dinheiro, apagar registros), maior o dano quando ele é induzido ao erro por uma injeção. Agency excessiva é dar ao modelo permissões amplas e autonomia sem supervisão. O princípio corretivo é o velho conhecido: menor privilégio. O agente recebe só as ferramentas e permissões estritamente necessárias, e ações sensíveis exigem confirmação humana.

Guardrails: como reduzir o risco na prática

Não existe uma configuração que "resolva" a prompt injection, porque ela explora a natureza do modelo. A defesa é em camadas, combinando controles antes, durante e depois da inferência.

• Menor privilégio para o modelo: limite drasticamente o que o LLM pode acionar. Ferramentas com escopo mínimo, credenciais restritas, sem acesso a nada que ele não precise. É o controle de maior impacto.
• Validação de entrada e de saída: filtre entradas suspeitas e, principalmente, trate toda saída como não confiável antes de renderizar, executar ou repassar.
• Confirmação humana (human in the loop): ações irreversíveis ou de alto impacto (pagamentos, exclusões, envios externos) passam por aprovação humana, não são executadas direto pelo agente.
• Separação de contexto e isolamento: mantenha dados de usuários isolados entre sessões e minimize o que entra no contexto. Menos informação sensível no prompt significa menos a vazar.
• Guardrails dedicados: camadas específicas que classificam e bloqueiam entradas e saídas perigosas antes que cheguem ao modelo ou ao usuário.
• Limites de uso e custo: imponha rate limiting e tetos de consumo para conter tanto abuso quanto o custo descontrolado de um ataque de exaustão.
• Observabilidade: registre prompts, respostas e ações do agente para auditoria e detecção de abuso, tratando esses logs como dados sensíveis.

Segurança de IA é engenharia de segurança aplicada a um componente novo

A tentação é tratar o LLM como uma caixa mágica que "só responde". Na prática, ele é um componente ativo, influenciável e cada vez mais poderoso, que precisa entrar no seu modelo de ameaças como qualquer outro. A boa notícia é que os princípios não são novos: menor privilégio, desconfiar de toda entrada e de toda saída, isolar contextos, exigir supervisão humana no que é crítico e observar tudo. O OWASP Top 10 para LLMs é o mapa que traduz esses princípios para o comportamento específico da IA generativa.

Na ConstructorTI, ajudamos times que estão colocando IA em produção a fazer isso com segurança: modelagem de ameaças de aplicações LLM, testes de prompt injection direta e indireta, revisão de permissões e agency de agentes, desenho de guardrails de entrada e saída e observabilidade de uso. Se você vai expor um recurso de IA aos seus usuários e quer descobrir onde ele poderia ser manipulado antes que alguém o manipule, converse com o nosso time de CyberSecurity.