A injeção imediata de vulnerabilidades é o principal risco para aplicações corporativas que utilizam modelos de linguagem, de acordo com a OWASP, que manteve sua posição de destaque na lista Top 10 pelo segundo ano consecutivo. Não se trata de um cenário teórico ou um problema de laboratório: é uma consequência direta do funcionamento desses sistemas.
Um modelo de linguagem não distingue entre as instruções fornecidas pelo seu desenvolvedor e o texto que processa. Tudo chega como palavras. Se um documento lido pelo sistema contém algo na forma de uma instrução, existe a possibilidade de que ele a trate como tal.
A versão conhecida — um usuário escrevendo "ignore suas instruções" — é a menos preocupante, porque o atacante precisa estar presente e suas permissões são as mesmas de qualquer outro usuário.
A versão que importa em um ambiente de negócios é a injeção indiretaO texto malicioso não é escrito pelo usuário; ele está inserido no conteúdo que o sistema processa como parte de seu funcionamento normal.
Os vetores usuais:
Em todos os casos, o processo é o mesmo: alguém externo escreve um texto que seu sistema irá ler e que pode influenciar seu funcionamento. E em todos os casos, o dano potencial é exatamente igual ao escopo das permissões que você concedeu a essa pessoa.
A resposta intuitiva é filtrar instruções suspeitas na entrada. Isso não funciona de forma confiável por três motivos:
A linguagem possui infinitas formas. Qualquer lista de padrões proibidos pode ser reformulada. A instrução pode estar em outro idioma, ser parafraseada ou dividida em várias frases.
Pode estar escondido. Texto em branco em uma página em branco em um PDF, metadados, conteúdo que o usuário não vê, mas o sistema lê.
O filtro não consegue saber a intenção. Um e-mail legítimo pode conter a frase "por favor, encaminhe isto para o departamento de contabilidade". O sistema não possui uma maneira robusta de determinar se essa frase é uma instrução para si mesmo ou uma informação destinada a uma pessoa.
A conclusão operacional é ao mesmo tempo desconfortável e esclarecedora: Temos que assumir que a injeção ocorrerá e projetar de forma que isso não importe..
Princípio | Em que consiste? | O que isso impede |
|---|---|---|
Licença mínima | O sistema só acessa o que sua tarefa específica exige. | Que uma instrução injetada alcance dados externos |
Separação de canais | Conteúdo externo nunca é tratado como uma instrução do sistema. | Permita que um PDF redefina o comportamento. |
Lista branca de ações | Somente as operações explicitamente listadas são permitidas. | Que algo imprevisto aconteça |
Validação humana no irreversível | Pagamentos, comunicações externas, alterações de produção | Que o dano se materialize sem revisão. |
Inscrição completa | Registra o que foi digitado e o que foi executado. | Que o incidente é irreparável |
Essas cinco são decisões arquitetônicas, não configurações de ferramentas. E todas as cinco custam pouco se implementadas antes da construção, razão pela qual este artigo se encaixa mais em uma discussão sobre design do que sobre segurança.
A OWASP adiciona dois riscos relacionados a esta tabela que devem ser mencionados: LLM02, divulgação de informações sensíveis, e LLM06, capacidade excedente. Os três apresentam o mesmo problema visto de ângulos diferentes: o que o sistema consegue ler, o que ele consegue fazer e quem consegue influenciá-lo. Desenvolvemos isso em Conceder permissões a um agente é uma decisão arriscada.
Imagine um assistente que processa as faturas que chegam ao e-mail da administração: ele extrai o valor, o fornecedor e o número da conta e prepara o pagamento.
Um fornecedor fraudulento envia uma fatura com uma pequena instrução no rodapé para que o sistema utilize um número de conta diferente. Se o assistente tiver permissão para preparar os pagamentos e ninguém verificar o número da conta no registro do fornecedor, a fraude é executada com a eficiência de um sistema automatizado.
Note que, neste exemplo, o modelo não falhou: ele fez exatamente o que o texto lhe pediu. A falha reside no projeto, que permitiu que um texto externo determinasse uma informação crucial sem verificá-la com a fonte original.
Portanto, a regra que repetimos em todos os projetos é a seguinte: O modelo elabora e interpreta; o sistema decide os fatos.. Valores, contas, status e permissões são verificados em relação ao sistema de origem; eles nunca são aceitos a partir de conteúdo processado.
Quando alguém apresenta uma solução baseada em IA que lê conteúdo externo, três perguntas separam a solução séria da improvisada:
Um provedor que responde "nosso modelo não cai nessa armadilha" não compreendeu o risco. A contenção não depende da qualidade do modelo, mas sim do escopo que lhe foi concedido.
Trata-se da manipulação do comportamento de um modelo de linguagem por meio de texto que o modelo processa como se fossem instruções. A OWASP classifica isso como o principal risco em seu Top 10 para aplicações de modelos de linguagem até 2025, porque o modelo não distingue estruturalmente entre as instruções do desenvolvedor e o conteúdo que analisa.
Esta é a variante relevante em ambientes empresariais: as instruções não são escritas pelo usuário, mas estão presentes no conteúdo que o sistema processa rotineiramente — um e-mail de um fornecedor, um PDF, uma página da web, um ticket de suporte ou um campo de formulário.
Não de forma confiável. A linguagem permite reformulações infinitas, instruções podem ser ocultadas em texto invisível ou metadados, e um filtro não consegue determinar a intenção. A abordagem correta é assumir que isso acontecerá e limitar o dano potencial por meio de permissões e controles.
Com cinco princípios de design: permissão mínima por tarefa, separação entre conteúdo externo e instruções do sistema, lista branca de ações permitidas, validação humana obrigatória em operações irreversíveis e registro completo de entradas e ações realizadas.
Sim, se o sistema os processar e tiver permissões amplas. Um exemplo típico é uma fatura que inclui uma instrução para alterar o número da conta de pagamento. O problema não está no modelo em si, mas no design que permite que um texto externo determine dados críticos sem verificá-los com a fonte.
O que acontece se o conteúdo processado incluir instruções direcionadas ao sistema? O que o sistema pode fazer no pior cenário possível? E seria possível reconstruir um incidente ocorrido há um mês? Uma resposta que nega a possibilidade de um ataque indica falta de consciência do risco.
Seu sistema de IA lê conteúdo escrito por terceiros? Analisamos o escopo, as permissões, a separação de canais e a rastreabilidade, e informamos qual é o pior cenário possível com o design atual. Solicitar uma avaliação →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
