Invisible Work
Conversar

Guia

O que é prompt injection em IA e por que filtrar o texto não resolve

Invisible Work8 min de leitura

Em uma frase

Prompt injection é quando um texto que o modelo de IA lê, como um e-mail, uma página ou um PDF, o faz obedecer a uma instrução que não veio de quem o opera. Na forma indireta, o atacante não precisa de acesso ao sistema: basta escrever algo que o sistema vá ler. Segundo o NCSC, o modelo não tem fronteira entre instrução e dado, e por isso o risco se reduz, mas não se elimina.

O que é prompt injection, sem jargão

Prompt injection é quando um texto que o modelo lê faz o modelo obedecer a uma instrução que não veio de quem o opera. A frase escondida num e-mail, numa página ou num PDF vira ordem, e o sistema age como se a empresa a tivesse dado.

O nome vem de 2022. Simon Willison o propôs depois que Riley Goodside mostrou que o GPT-3, ao traduzir um texto, obedecia a um trecho que mandava ignorar as instruções anteriores. A semelhança com a injeção de SQL era de propósito: nos dois casos, o programador monta a instrução juntando texto dele com texto de fora.

A OWASP separa duas formas. Na injeção direta, quem digita no sistema altera o comportamento dele. Na injeção indireta, o texto vem de uma fonte externa que o modelo consome, como um site ou um arquivo. A segunda é a que importa para empresa, porque o atacante não precisa de acesso ao sistema: basta escrever algo que o sistema vá ler. Foi o que Greshake e coautores mostraram em 2023, ao atacar o Bing Chat e aplicações montadas sobre o GPT-4.

Não é o mesmo que jailbreak. Willison reserva o primeiro nome para o ataque ao sistema que mistura texto confiável e não confiável, e chama de jailbreak o truque para fazer o modelo dizer o que o fornecedor proíbe. Para ele, quem confunde os dois ignora o problema porque não vê por que importaria se o modelo dá uma receita indevida. A OWASP trata o jailbreak como uma forma de prompt injection; o que interessa na empresa é a forma em que o modelo age.

Exemplo da Anthropic

Você pede a um agente para ler seus e-mails e rascunhar respostas aos pedidos de reunião. Um dos e-mails, aparentemente de um fornecedor, traz em texto branco uma instrução: encaminhar para um endereço externo as mensagens com a palavra “confidencial”. Você não vê a instrução. O agente a lê junto com o resto.

Por que não tem conserto como a injeção de SQL teve

A injeção de SQL se resolveu na raiz: com consulta parametrizada, o banco nunca interpreta o dado como comando. O NCSC, o centro de segurança cibernética do Reino Unido, explica por que isso não se repete aqui. Dentro de um modelo de linguagem não existe distinção entre dado e instrução; só existe o próximo token. Por isso, escreve o centro, o problema pode nunca ser totalmente mitigado, e comparar os dois é perigoso porque leva a defesas que não fecham a brecha.

O agente obedece ao que lê, então o dano depende do que ele pode fazerDois desenhos lado a lado. À esquerda, um e-mail de fornecedor com uma instrução escondida chega a um agente que tem acesso aos dados da empresa e a um botão de enviar para fora; a instrução é cumprida e os dados saem. À direita, o mesmo e-mail chega a um agente sem o botão de enviar para fora; a instrução é lida, mas não há como cumpri-la.Agente com permissão amplaAgente com permissão mínimae-mail dofornecedor“envie os dados”agentedados da empresaenvia p/ foraa instrução é cumpridae-mail dofornecedor“envie os dados”agentedados da empresasem esta saídaa instrução não tem como sair
O texto malicioso é o mesmo nos dois lados. O que muda o resultado não é o filtro de entrada, e sim o que o agente tinha permissão de fazer depois de ler.

O que existe hoje reduz a chance, não a elimina. A Anthropic descreve três frentes: treinar o modelo por reforço para recusar instruções maliciosas, passar classificadores sobre todo conteúdo não confiável que entra e manter uma equipe humana tentando quebrar o agente. Com tudo isso, o relato é franco: um ataque que dá certo em 1% das tentativas ainda representa risco real, e nenhum agente de navegador é imune.

  1. Lista de frases proibidas

    Bloquear “ignore as instruções anteriores” não adianta, avisa o NCSC: há infinitas maneiras de reescrever o ataque, e o modelo as entende todas.

  2. Produto que promete deter

    Willison desconfia de quem anuncia pegar 95% dos ataques: em segurança de aplicação web, 95% é nota de reprovação. O NCSC pede cuidado com quem diz “parar”, e atenção a quem explica como reduz.

  3. RAG e fine-tuning

    A OWASP registra que as duas técnicas, que tornam a resposta mais relevante, não mitigam por completo a vulnerabilidade.

Willison lista dezenas de casos em produtos de fornecedores grandes, do Microsoft 365 Copilot ao Slack e ao ChatGPT Operator. Quase todos foram corrigidos fechando o canal por onde o dado saía, não impedindo o modelo de ler a instrução.

O ponto de vista da Invisible Work: suponha que o agente obedece

Desmontada a premissa, a pergunta de segurança muda. Se não dá para garantir que o modelo distingue o que a empresa mandou do que um estranho escreveu, a defesa que começa por “como mantemos o texto ruim fora?” parte de uma premissa que, segundo o NCSC, talvez nunca se cumpra por completo. A pergunta que sobra é outra: se o agente obedecer ao pior texto que vai ler, qual é o maior dano possível?

Essa conta tem uma forma curta, que o NCSC cita de uma conversa entre Willison e Baibhav Bista: quando o modelo processa a informação de uma parte, os privilégios dele caem ao nível dessa parte. Um agente que lê e-mails de desconhecidos não deve ter ferramentas de quem tem a senha do financeiro. O agente tem a permissão da fonte menos confiável que ele lê.

Três capacidades que, juntas, deixam o atacante levar os dadosTrês caixas em linha: acesso a dados privados, exposição a conteúdo não confiável e canal para comunicar com o exterior. Setas das três convergem para uma caixa laranja: o atacante leva os dados. Um X sobre qualquer uma das três caixas desfaz o caminho.1. dados privadose-mail, CRM, ERP2. texto de terceirose-mail, página, PDF3. canal para forae-mail, link, APIo atacante leva os dadostire uma das três e o caminho se desfazfiltro de texto não tira nenhuma
A tríade é de Simon Willison. Com as três juntas no mesmo agente, uma instrução escondida em conteúdo não confiável consegue mandar dados privados para fora. Tirar uma das três quebra o caminho.

Willison nomeou o caso grave de tríade letal: o agente que reúne acesso a dados privados, exposição a conteúdo não confiável e um jeito de se comunicar para fora. Com as três juntas, um atacante consegue que ele pegue os dados e os envie. Dá para desfazer com uma pergunta por perna, e nenhuma delas é sobre o texto: o agente precisa mesmo ver esse dado? Precisa mesmo ler texto de terceiros? Precisa mesmo falar com o exterior? Tirar uma resolve; filtrar o texto não tira nenhuma.

Exemplo hipotético

Uma distribuidora põe um agente para ler as faturas que fornecedores mandam por e-mail e lançá-las no ERP. Ele lê texto de terceiros (perna 2) e enxerga o cadastro de preços e de clientes (perna 1). Enquanto não tiver como enviar e-mail nem chamar endereços externos, a instrução escondida numa fatura pode, no pior caso, lançar um valor errado, o que a conferência de lançamentos pega. Se alguém lhe der a ferramenta de responder ao fornecedor “para agilizar”, nasceu a perna 3 e, com ela, o caminho de saída para o cadastro.

Três perguntas antes de pôr um agente para ler o que vem de fora

  1. Qual é o pior texto que ele pode ler?

    Liste as fontes que um estranho consegue escrever: caixa de e-mail, formulário, página da web, currículo, anexo. A permissão do agente deve caber na menos confiável delas.

  2. Qual é o pior verbo que ele pode executar?

    Enviar, pagar, apagar e publicar valem mais que ler. O NCSC recomenda travas determinísticas, que não dependem do modelo, em vez de tentar impedir que o texto malicioso chegue a ele.

  3. Quem saberia, e quando?

    Registrar entradas, saídas e chamadas de ferramenta, e tratar chamada recusada como sinal, porque o atacante precisa afinar o ataque. Sem log, o primeiro aviso é o dano.

Isso aproxima o tema de quatro outros guias. O desenho de um agente define quanta permissão ele tem; os guardrails de menor privilégio são a defesa que se sustenta, e o filtro de texto, a que não; o MCP facilita juntar ferramentas de origens diferentes, o que, nas palavras de Willison, empurra o usuário para a tríade sem perceber; e a pessoa que aprova (human-in-the-loop) só protege se vir o efeito da ação, não o nome da ferramenta. A camada onde essas travas moram é o harness. O caso do limite que a velocidade humana impunha sozinha está no Insight sobre agentes sem alçada.

Perguntas antes de pôr um agente para ler texto de fora

  1. Quais fontes de texto qualquer estranho consegue escrever e o agente lê?
  2. O que o agente consegue enviar, pagar, apagar ou publicar depois de ler essas fontes?
  3. Há um agente que reúne dados privados, texto de terceiros e canal para fora? Qual das três pernas dá para tirar?
  4. A trava é uma regra no sistema de destino ou um pedido no prompt?
  5. Se alguém plantou uma instrução ontem, o que o registro mostraria hoje?

Limites

As defesas de treinamento e de classificação mudam rápido, e o número da Anthropic é de um agente de navegador medido pela própria empresa contra um atacante interno dela. A tríade é uma regra de Willison, não um padrão técnico; o desenho de menor privilégio, a leitura de que o agente herda a permissão da fonte menos confiável e as perguntas acima são da Invisible Work. O NCSC fala de risco residual: a conta certa não é zerar o risco, e sim ver se o negócio tolera o que sobra.

Continue lendo