O Supremo Tribunal Federal identificou comandos ocultos em uma petição do ARE 1.608.713 destinados a influenciar eventual sistema de inteligência artificial que processasse o documento. O episódio não alterou a decisão do relator, mas expõe uma nova superfície de ataque: arquivos aparentemente normais que carregam instruções para máquinas.
O caso veio a público em 25 de setembro de 2026. Em nota oficial, o Supremo Tribunal Federal informou que detectou, no Recurso Extraordinário com Agravo (ARE) 1.608.713, instruções ocultas inseridas em uma petição para orientar sistemas de inteligência artificial a adotar determinada linha de fundamentação e produzir resultado favorável à recorrente.
O relator, ministro Cristiano Zanin, registrou o episódio no processo, votou pela aplicação de multa de dois salários mínimos por violação do dever de lealdade processual e determinou a comunicação dos fatos à Ordem dos Advogados do Brasil, para análise ético-disciplinar, e ao Ministério Público Federal, para apuração de eventual prática criminosa. O julgamento virtual da Primeira Turma foi iniciado em 25 de setembro e estava previsto para terminar em 2 de outubro.
Há uma correção importante em relação a parte das publicações que circularam nas redes sociais: o STF qualificou o episódio como a primeira tentativa identificada na própria Corte. Não é, porém, o primeiro caso conhecido no Judiciário brasileiro. O Superior Tribunal de Justiça registrou em setembro de 2026 outro caso de prompt injection oculto em peça processual, tratado no Informativo de Jurisprudência 902.
O que exatamente foi tentado no STF
A técnica identificada é conhecida como prompt injection. No contexto dos modelos de linguagem, ela procura introduzir instruções capazes de modificar o comportamento esperado da inteligência artificial. Quando a instrução maliciosa chega não pela pergunta direta do usuário, mas por um arquivo, página, e-mail ou outra fonte externa que a IA precisa interpretar, o caso é classificado como indirect prompt injection, ou injeção indireta de prompt.
A OWASP coloca Prompt Injection como LLM01:2025 e ressalta que uma instrução maliciosa pode funcionar mesmo quando não é legível ou perceptível para uma pessoa, desde que seja extraída e processada pelo modelo. É justamente esse ponto que torna documentos uma superfície de ataque relevante.
No caso do ARE 1.608.713, o objetivo descrito pelo STF era direcionar eventual ferramenta de IA utilizada na análise processual. O próprio Zanin esclareceu, no entanto, que seu gabinete não utiliza inteligência artificial para analisar processos ou fundamentar decisões e que a tentativa não teve efeito sobre o recurso, já rejeitado anteriormente.
Por que um documento pode ter dois conteúdos diferentes
Para o leitor humano, uma petição pode aparentar conter apenas o texto jurídico visível. Para um sistema automatizado, entretanto, o arquivo pode incluir elementos adicionais: texto em cor branca, fontes extremamente reduzidas, objetos fora da área visível, camadas, comentários, conteúdo alternativo, metadados ou outros elementos que ainda possam ser extraídos por parsers, mecanismos de OCR ou pipelines de ingestão.
Isso significa que a pergunta de segurança deixa de ser apenas “o que aparece na tela?” e passa a incluir “o que o sistema consegue extrair deste arquivo?”. A diferença é particularmente importante em ambientes que utilizam IA para resumir documentos, classificar petições, localizar precedentes, extrair entidades, sugerir minutas ou apoiar triagens.
Essa lógica já havia sido explorada pelo Minuto da Segurança em Prompt injection indireta: quando uma página ou documento assume o controle do agente. O caso do STF transforma um risco técnico abstrato em um episódio concreto dentro de um fluxo documental sensível.
O impacto vai além do Judiciário
O mesmo mecanismo pode aparecer em currículos analisados por IA, propostas comerciais, contratos, documentos recebidos de fornecedores, relatórios, e-mails, páginas web, tickets de suporte ou arquivos carregados em sistemas de RAG. Sempre que um modelo recebe conteúdo de terceiros e esse conteúdo pode influenciar instruções, existe uma fronteira de confiança que precisa ser tratada explicitamente.
Em uma empresa, por exemplo, um agente encarregado de resumir contratos pode receber um PDF com instruções ocultas para minimizar determinada cláusula, priorizar um fornecedor ou solicitar informações adicionais. Se esse agente tiver acesso a ferramentas, a consequência pode ir além de uma resposta incorreta e alcançar consultas indevidas, envio de mensagens ou execução de ações.
Por isso, o risco cresce conforme aumenta a autonomia do sistema. A OWASP relaciona prompt injection também ao problema de Excessive Agency: quanto mais funções e permissões a IA recebe, maior o impacto potencial de uma instrução manipulada.
A prova digital precisa preservar o arquivo original
O episódio também tem implicações importantes para perícia e resposta a incidentes. Imprimir um documento ou convertê-lo para uma representação puramente visual pode eliminar justamente os elementos que explicam como uma instrução foi inserida e como um sistema poderia extraí-la.
Em uma investigação, o arquivo original deve ser preservado juntamente com hash criptográfico, cadeia de custódia, metadados relevantes e, quando necessário, sua estrutura interna. Em formatos como PDF, isso pode incluir objetos, streams, fontes, coordenadas, camadas e texto extraível. A análise deve comparar o que é visível ao usuário com o que é efetivamente entregue ao pipeline de processamento.
Esse cuidado não significa que toda divergência entre conteúdo visual e conteúdo extraído seja maliciosa. PDFs legítimos podem conter camadas de OCR, tags de acessibilidade e informações técnicas. O indicador relevante é a presença de conteúdo destinado a influenciar comportamento automatizado de forma incompatível com a finalidade do documento.
Como proteger sistemas que analisam documentos com IA
Não existe um único filtro capaz de eliminar prompt injection. A própria OWASP observa que RAG, fine-tuning ou instruções de sistema não resolvem isoladamente o problema. A proteção precisa combinar controles de conteúdo, arquitetura, autorização e revisão humana.
O primeiro controle é tratar documentos, páginas e mensagens externas como entrada não confiável. O conteúdo recuperado deve ser marcado e isolado do conjunto de instruções confiáveis do sistema. Pipelines de ingestão podem detectar padrões suspeitos, texto oculto, discrepâncias entre renderização e extração e instruções dirigidas ao próprio modelo.
O segundo controle é limitar o que a IA pode fazer. Um modelo usado para resumir documentos não precisa ter permissão para enviar e-mails, alterar registros ou executar comandos. Quando uma ferramenta realmente precisa ser acionada, o princípio do menor privilégio deve limitar escopo, identidade, duração e contexto das credenciais.
O terceiro controle é aplicar validação independente às saídas. Uma recomendação de IA não deve se transformar automaticamente em decisão, transação ou alteração de sistema sem regras externas, verificações determinísticas e, nos casos de maior impacto, aprovação humana.
O quarto controle é manter observabilidade. Logs devem permitir reconstruir qual arquivo foi processado, quais trechos foram extraídos, que modelo e versão foram usados, quais ferramentas foram chamadas e quais autorizações foram aplicadas. Isso ajuda a diferenciar falha de modelo, conteúdo malicioso e erro operacional.
Por fim, as organizações precisam testar esse cenário. A OWASP recomenda exercícios adversariais e testes de penetração específicos para sistemas de IA. O objetivo não é apenas verificar se o modelo “obedece” ao prompt do sistema, mas comprovar que uma instrução maliciosa contida em dados externos não consegue ultrapassar controles de autorização e causar impacto real.
O caso do STJ mostra que não foi um episódio isolado
O caso anterior registrado pelo STJ reforça que o fenômeno já saiu do laboratório. No REsp 2.256.731-PB, a Corte descreveu comando oculto em peça processual destinado a induzir uma ferramenta de IA a considerar vencedora uma tese e produzir decisão favorável. O tribunal tratou a conduta como incompatível com a boa-fé processual, determinando comunicação às autoridades competentes.
Os dois episódios não demonstram que decisões judiciais brasileiras tenham sido efetivamente produzidas ou alteradas por prompt injection. O que demonstram é que pessoas já estão tentando explorar fluxos em que documentos podem ser processados por sistemas de IA. Isso muda a discussão de “é possível?” para “como detectar e conter?”.
Uma nova superfície de ataque nasceu dentro do documento
O caso do STF é relevante porque desloca prompt injection de aplicações experimentais para um ambiente de alta sensibilidade institucional. A tentativa não produziu efeito sobre a decisão do ARE 1.608.713, mas evidenciou que o conteúdo de um arquivo pode ser preparado para duas audiências diferentes: a pessoa que o lê e a máquina que o processa.
Para tribunais, empresas e órgãos públicos, a consequência prática é clara: qualquer sistema de IA que consuma documentos externos precisa assumir que o próprio documento pode ser hostil. A defesa depende de separar dados de instruções, reduzir privilégios, validar saídas, preservar evidências e testar continuamente o comportamento do sistema diante de entradas manipuladas.
Referências
Be the first to comment