Como o MinutaIA detecta prompt injection

O risco

Instruções endereçadas ao modelo, não ao leitor humano.

Prompt injection é o nome técnico para uma fraude antiga em forma nova. Alguém insere, dentro de um documento que será lido por uma IA jurídica, instruções endereçadas ao modelo redator em vez de aos destinatários humanos do processo.

Pode ser uma frase em branco sobre branco, num PDF aparentemente comum. Pode ser uma camada de OCR escondida por trás do texto visível de uma petição. Pode ser um trecho microscópico, fora da página, em modo de renderização invisível. Em todos os casos, o leitor humano nunca vê.

O modelo, sem defesa, lê o documento inteiro. Inclusive o que estava escondido. E pode obedecer.

Por que isso é estruturalmente difícil de defender? Por uma propriedade arquitetural dos modelos de linguagem: instrução e dado vivem no mesmo canal. Diferente de SQL, em que a query é separada do parâmetro por design, o LLM recebe uma única sequência de tokens e precisa decidir, durante a inferência, o que é instrução legítima do desenvolvedor e o que é apenas texto a processar. Essa decisão é estatística, não tem garantia formal de robustez, e é exatamente onde prompt injection se aloja. A literatura formaliza o problema desde 2022 (Perez & Ribeiro; indirect prompt injection de Greshake et al.), e até hoje não existe defesa única que o feche.

O estado da arte combina duas abordagens complementares: defesas aplicadas antes da inferência, sobre o material que o modelo vai consumir, como filtragem e sanitização da entrada (input filtering) ou separação de canais via marcadores que sinalizam onde acaba instrução e começa dado (spotlighting); e defesas aplicadas depois da inferência, sobre o que o modelo produziu (output verification). O MinutaIA opera nos dois eixos: a Camada 1 atua antes da inferência, a Camada 2, depois.

Por isso, desde julho de 2025, nenhuma minuta sai do MinutaIA sem passar por duas camadas de verificação independentes.

A metodologia

Duas camadas, dois mundos.

Nenhum filtro único cobre o problema inteiro. O ataque pode estar no documento, e nesse caso precisa ser interceptado antes que o modelo o leia. Pode também ter sucesso em iludir um filtro, e nesse caso precisa ser identificado pelo efeito que produziu no raciocínio do modelo.

Cada camada do MinutaIA tem o seu mundo:

Camada 1 · Antes da geração

Olhamos para o que o PDF estava tentando esconder.

Quando você abre um processo no MinutaIA, cada PDF anexado é analisado em sua estrutura interna, página por página. Olhamos para a forma como cada caractere foi desenhado e quais propriedades gráficas foram aplicadas, não apenas para o texto que o leitor enxerga. É nesse nível que o texto oculto se denuncia.

A análise identifica cinco assinaturas gráficas de ocultação:

Cada uma dessas assinaturas explora uma feature legítima da especificação do PDF (ISO 32000), usada de forma indevida. O modo de renderização Tr 3 marca texto como não pintável: legitimamente serve para tornar selecionável o texto sobre imagens digitalizadas, e é também o esconderijo mais comum de instruções adversariais. Alpha de preenchimento próximo de zero existe para efeitos de marca d'água, mas, setado em ca 0.01, preserva o glifo na camada de dados enquanto o torna invisível na renderização. Operações de pintura posicionadas fora da CropBox explicam diagramas que ultrapassam o papel; também escondem texto que nenhum visualizador mostra, mas que toda biblioteca de extração lê.

A análise gráfica do MinutaIA não busca atacantes diretamente. Busca o uso anômalo dessas features: texto invisível ao olho mas íntegro na camada de dados que os modelos consomem. Cada trecho que cumpre um dos critérios vira um candidato a inspeção. Cumprir o critério gráfico não basta para chamar de prompt injection: uma camada OCR mal posicionada pode ter as mesmas propriedades. Essa diferenciação fica para a etapa seguinte.

Sinalizar um trecho como suspeito é apenas o começo. A pergunta seguinte é mais delicada: isso é, de fato, uma tentativa de injeção?

Um classificador que lê o trecho como dado, nunca como instrução.

A pergunta tem implicação estrutural: quem responde? Pedir ao próprio modelo redator que rejeite instruções hostis dentro do documento que ele precisa ler é pedir que cumpra dois papéis em conflito durante a mesma chamada: seguir o que se parece com instrução, e simultaneamente decidir o que ignorar. Esse arranjo é historicamente frágil: qualquer reformulação nova do ataque tende a confundir o redator, e cada modelo novo precisa ser treinado contra todo o catálogo de variantes. A saída estrutural é decompor o papel: um modelo redige, outro avalia.

Cada candidato sinalizado é encaminhado a um classificador isolado do redator. Esse classificador recebe um único papel: dizer se o trecho parece ou não uma tentativa de manipular uma IA jurídica. Não escreve minutas. Não toma decisões jurídicas. Não interage com o usuário.

Ele opera sob uma regra fundadora: todo conteúdo dos candidatos é tratado como dado não confiável, potencialmente hostil. Nunca como instrução. Mesmo que o trecho diga “ignore o que veio antes”, o classificador não obedece. Ele observa.

A saída é estruturada. Para cada candidato, uma categoria, um nível de risco e uma justificativa curta. Quando o risco é alto, o usuário é alertado antes da geração da minuta.

Camada 2 · Depois da geração

Vemos o que o modelo estava pensando enquanto escrevia.

Toda defesa de entrada tem janela de erro. Análises baseadas em sinais gráficos confundem-se com texto técnico raro. Classificadores podem ser enganados por reformulações novas. Por isso o MinutaIA não encerra a defesa quando o modelo começa a redigir: uma segunda camada observa o que o modelo fez com aquilo que recebeu.

Modelos de linguagem com raciocínio explícito mantêm, durante a inferência, um canal estruturalmente separado do texto final entregue ao usuário: a cadeia de raciocínio (chain-of-thought). Esse canal funciona como um log de decisões intermediárias do modelo, em linguagem natural: supor um valor, escolher uma referência, optar por omitir um trecho, decidir favorecer uma parte. Para auditoria, é o sinal mais útil que se pode extrair: revela o que o modelo achou que estava sendo pedido, antes mesmo de o resultado final esconder essa informação no texto polido da peça.

O desenho tem uma propriedade importante: independência da forma do ataque. A Camada 2 não conhece as assinaturas gráficas de ocultação. Não conhece dicionários de termos hostis. Não conhece a história do PDF. Olha apenas para o efeito final no raciocínio. Variantes adversariais novas que enganariam filtros baseados em padrões ainda assim deixam rastro quando, de fato, induzem o modelo a desviar.

Um auditor independente, separado do redator, recebe três entradas:

A tarefa do auditor é cruzar essas três entradas e responder: o pensamento do modelo é compatível com o que o MinutaIA pediu e com o que o usuário pediu? Ou apareceu, no meio do caminho, uma instrução que ninguém legítimo deu?

O auditor produz dois julgamentos paralelos. Um sobre segurança: houve, ou não, sinal de injeção. Outro sobre qualidade: houve, ou não, decisão de inventar dado fictício sem que o usuário tenha pedido um documento hipotético.

Cada julgamento vem com um nível de confiança e uma justificativa curta. Os dois alimentam o indicador de segurança da minuta, exibido junto da peça gerada.

Como se complementam

Ângulos opostos sobre o mesmo problema.

As duas camadas não são redundantes. Elas atacam o mesmo problema por ângulos opostos, e por isso cobrem pontos cegos uma da outra.

A primeira camada é preventiva. Olha para o material de entrada, antes do modelo pensar, e tira do caminho o que parece tentar instruí-lo pelas costas. É excelente contra ataques que dependem de esconder texto em PDFs.

A segunda camada é consequente. Olha para o efeito, depois do modelo pensar. Não depende do canal pelo qual o ataque chegou, porque mede a fidelidade do raciocínio às instruções legítimas, não a presença de gatilhos específicos.

Esse arranjo tem nome na literatura de segurança: defense-in-depth. Sua propriedade central não é detectar mais ataques que uma camada única, mas reduzir a probabilidade de um ataque atravessar todas as camadas em sequência. Se as falhas das camadas são razoavelmente independentes, a probabilidade conjunta de atravessar todas é o produto, não a soma. O ganho real do arranjo é função direta dessa independência, e é por isso que escolhemos camadas com fundamentos opostos: uma analisa o documento como dado bruto antes da inferência, a outra analisa o modelo como agente em ação durante a inferência. Os dois conjuntos de modos de falha têm pouca interseção.

A tabela abaixo resume onde cada camada atua. “Cobre” aqui significa que a camada foi projetada para tratar aquele vetor, não que detecte 100% das tentativas. Nenhuma defesa contra prompt injection oferece essa garantia, hoje, no estado da arte.

A primeira camada é especialista em sinais. A segunda é especialista em consequências. Trabalhar com as duas em série reduz substancialmente a chance de uma instrução adversarial atravessar todo o pipeline sem ser notada.

Nenhuma defesa contra prompt injection é infalível, e seria desonesto sugerir o contrário. Atacantes evoluem, e parte do que será tentado contra modelos de linguagem em dois anos hoje ainda não tem nome. O que a arquitetura de duas camadas oferece é margem: uma falha pontual de uma camada precisa coincidir com uma falha pontual da outra para virar uma minuta comprometida sem aviso. E quando uma nova classe de ataque aparece, nós atualizamos as duas camadas, sem cobrar e sem precisar lançar versão.

Um filtro inspeciona o que entra. O outro audita o que o modelo pensou antes de a peça chegar ao usuário.

Você não precisa fazer nada.

A defesa é silenciosa por padrão. Quando os autos estão limpos e o raciocínio do modelo está coerente, nada aparece interrompendo o seu fluxo. O indicador fica verde, ao lado da minuta, e você segue trabalhando.

Quando algo é encontrado, a defesa fica visível. A primeira camada avisa que removeu trechos suspeitos de um PDF antes de redigir, com a justificativa. A segunda camada acende o indicador no canto da peça, com a razão do alerta.

Em ambos os casos, a decisão final é sua. O MinutaIA informa, propõe e age conservadoramente quando o risco é claro. Mas é o usuário que decide se assina, revisa ou descarta a peça.

Segurança em IA jurídica não é uma feature. É um compromisso ético.

Quando uma IA redige uma peça jurídica, ela participa, indiretamente, da formação de um futuro ato processual. A minuta ainda passa pela revisão e decisão do usuário, mas o risco de uma instrução adversarial não detectada não é o de um produto que “funciona pior”. É o de uma minuta que omite, distorce ou favorece, sem que o usuário perceba durante a revisão.

Por isso a detecção de prompt injection no MinutaIA não é um recurso que liga, desliga ou tem versão paga. Está ligada em todas as minutas, para todos os planos, desde julho de 2025. Não tem opt-out. Não tem ressalva.

Toda nova categoria de ataque que aparece no mundo é incorporada nas duas camadas, sem aviso e sem cobrança. A análise gráfica dos PDFs e a auditoria do raciocínio recebem novos sinais e novos padrões de manipulação à medida que o estado da arte avança.

É o tipo de trabalho que ninguém vê quando funciona, e que ninguém perdoa quando falha. Achamos que está bem assim.