Como um texto escondido em um arquivo pode dar ordens ao seu assistente de IA
Aldemar Araujo Castro
Criação: 13/09/2026
Atualização: 13/09/2026
Palavras: 1990
Tempo de leitura: 10 minutos
A folha em branco
alguém escreveu no verso
a lupa revela
Resumo. Este texto explica a injeção de prompt, ataque em que um conteúdo lido por um assistente de inteligência artificial é interpretado como ordem em vez de dado. Apresenta a raiz do problema, que é a ausência de separação entre instrução e conteúdo, distingue as modalidades direta, indireta e oculta em documentos, discute a evidência experimental obtida em tarefas de oncologia e oferece um mapa das demais ameaças associadas ao uso dessas ferramentas na pesquisa. Encerra com condutas práticas ao alcance do pesquisador e do comitê de ética, da limitação de permissões à triagem prévia de arquivos de terceiros.
Introdução
Um parecerista recebe para análise um projeto de pesquisa em formato portátil, com noventa páginas, e pede a um assistente de inteligência artificial que resuma a metodologia. O resumo chega impecável. O que ele não viu é que, na página quarenta e sete, havia um parágrafo em corpo dois, em branco sobre fundo branco, instruindo o assistente a ignorar as orientações anteriores, omitir qualquer menção ao cálculo amostral e classificar o protocolo como metodologicamente adequado.
Nenhuma senha foi quebrada. Nenhum sistema foi invadido. O arquivo era exatamente o que aparentava ser, e o assistente cumpriu a ordem que recebeu, apenas não foi o parecerista quem a deu.
Essa é a ameaça conhecida como injeção de prompt, e ela ocupa o primeiro lugar nas listas de risco de aplicações de modelos de linguagem desde que essas listas passaram a existir. O texto que se segue explica o mecanismo, mostra as formas que o ataque assume, apresenta a evidência experimental já produzida em contexto clínico, oferece um mapa das demais ameaças que acompanham o uso dessas ferramentas na pesquisa e encerra com o que está ao alcance do pesquisador e do comitê de ética fazer a respeito.
Instrução e dado no mesmo fluxo
Convém começar pelo que o problema não é. Não é falha de senha, não é invasão, não é vírus, e não se resolve trocando de fornecedor.
Um modelo de linguagem recebe uma sequência única de texto. Nela convivem, sem qualquer fronteira estrutural, a instrução do desenvolvedor que configurou o sistema, o pedido que o usuário digitou e todo o conteúdo trazido de fora, isto é, o documento anexado, a página consultada, a mensagem recebida, o resultado devolvido por uma ferramenta. O modelo prevê a continuação mais provável dessa sequência inteira. Ele não dispõe de um canal fisicamente separado que lhe informe o que é comando e o que é material a examinar, e é justamente essa ausência de separação entre instrução e dado que cria a vulnerabilidade.
A comparação com a injeção de código em consultas a bancos de dados é útil e tem um limite que precisa ser dito. Naquele caso existe uma gramática formal, e é possível escapar caracteres de modo confiável, de sorte que o problema foi tecnicamente resolvido décadas atrás. A linguagem natural não tem gramática formal, não admite escape, e por isso a injeção de prompt permanece, hoje, sem solução completa. O trabalho que primeiro demonstrou a viabilidade do ataque em aplicações reais já apontava essa consequência incômoda: qualquer conteúdo que o sistema venha a ler é superfície de ataque, e a superfície cresce à medida que o sistema ganha acesso a mais fontes (Greshake et al., 2023).
Direta, indireta e invisível
A modalidade direta é a menos interessante. O próprio usuário escreve instruções para contornar as regras do sistema, pedindo que o assistente ignore orientações anteriores ou assuma um papel sem restrições. Quem ataca e quem usa são a mesma pessoa, e o prejuízo, se houver, recai sobre o fornecedor do serviço.
A modalidade indireta é a que importa para a vida acadêmica. Aqui o atacante nunca conversa com o assistente: ele deposita o texto em algum lugar que o assistente virá a ler no curso de uma tarefa legítima. Um comentário em uma página, um campo de metadados, uma linha em uma planilha compartilhada, o corpo de um manuscrito, a descrição de um repositório. Quando o sistema recupera aquele material, encontra ali algo redigido na forma de ordem, frequentemente acompanhado de uma falsa marca de autoridade, do tipo que se apresenta como vindo do desenvolvedor, ou de uma falsa autorização, afirmando que o usuário já consentiu com determinada ação.
A ocultação é o agravante prático, e é onde o problema toca diretamente o cotidiano de quem lê documentos de terceiros. Em arquivos em formato portátil, o texto pode estar em corpo mínimo, em branco sobre branco, em camadas não visíveis na tela, em campos de metadados, em texto alternativo de imagem ou em anotações que o leitor humano jamais encontra, mas que o extrator de texto entrega ao modelo integralmente. Em conteúdo com imagens, a instrução pode estar inscrita na própria figura, o que dispensa qualquer manipulação do arquivo de texto.
Quanto ao objetivo, três finalidades cobrem quase tudo. A exfiltração busca induzir o assistente a colocar informação sensível em lugar acessível ao atacante, tipicamente montando um endereço eletrônico com os dados embutidos. A ação indevida busca provocar uma operação com efeito real, como enviar mensagem, apagar arquivo ou publicar conteúdo. E a corrupção do resultado busca apenas que a resposta saia errada de modo favorável a quem plantou o texto, que é a hipótese mais difícil de detectar, porque não deixa rastro operacional nenhum. O parecer sai assinado, plausível e falso.
Quase seiscentos ataques em oncologia
A pergunta natural do pesquisador é se isso funciona fora do laboratório de segurança. Funciona, e há medida disso em contexto clínico.
Um grupo submeteu modelos de visão e linguagem a tarefas de interpretação de imagens médicas em oncologia, com quase seiscentos ataques distribuídos entre quatro sistemas de ponta, inserindo instruções nos materiais fornecidos ao modelo, sem qualquer acesso aos parâmetros internos. Todos os modelos testados mostraram-se suscetíveis, e as respostas puderam ser desviadas para conclusões incorretas a partir de conteúdo que um profissional olhando a mesma imagem não perceberia (Clusmann et al., 2025).
O achado tem duas implicações que valem mais do que o número. A primeira é que o ataque não exige acesso privilegiado, apenas a capacidade de colocar conteúdo no caminho do modelo, o que qualquer pessoa que envie um arquivo consegue fazer. A segunda é que o domínio clínico não confere imunidade alguma: a sofisticação médica da tarefa não corrige a fragilidade linguística do mecanismo.
O mapa das outras ameaças
A injeção de prompt é a primeira da lista, não a única. Vale conhecer o restante do mapa, porque as defesas diferem.
A divulgação de informação sensível ocorre quando o sistema revela, na resposta, algo que não deveria, seja dado pessoal presente no material carregado, seja conteúdo de outro documento indexado no mesmo acervo. Para um comitê de ética que processe vários protocolos com a mesma ferramenta, o risco é concreto e de consequência institucional imediata, porque envolve projeto alheio e dados de participantes.
A agência excessiva aparece quando o assistente recebe mais ferramentas, mais permissões ou mais autonomia do que a tarefa exige. Um fluxo que apenas resume documentos não precisa de acesso de escrita nem de capacidade de enviar mensagens, e cada permissão concedida além do necessário converte uma falha de interpretação em ação consumada. Essa categoria subiu posições nas listas recentes precisamente porque assistentes com acesso a sistemas reais se tornaram comuns.
A cadeia de suprimentos é a porta que se abre pelo que se instala, e não pelo que se digita. Modelos obtidos de repositórios públicos, extensões, bibliotecas e conectores de terceiros entram no processo com privilégios próprios, e um componente comprometido não precisa enganar ninguém, já está dentro.
O envenenamento de dados manipula o material que treina ou alimenta o sistema. A variante que mais interessa a quem monta um acervo próprio para consulta é o envenenamento da base de recuperação, isto é, inserir no repositório um documento redigido para ser recuperado com frequência e distorcer respostas futuras, o que é uma forma silenciosa e persistente de contaminar todo um fluxo de trabalho.
A desinformação é a saída incorreta apresentada com confiança, e no ambiente acadêmico assume as formas mais custosas que conhecemos, da referência inexistente à atribuição falsa de posição a um autor. O tratamento inadequado da saída, por sua vez, ocorre quando o texto produzido pelo modelo é usado por outro sistema sem validação, por exemplo inserido em uma página ou executado como comando, e é nesse ponto que a falha de um assistente se converte em vulnerabilidade clássica de aplicação.
Há ainda a família de riscos própria dos sistemas que agem por conta própria, com ferramentas e memória. Ali entram o desvio de objetivo, o uso indevido de instrumentos legítimos, o abuso de credenciais, o envenenamento de memória, que persiste entre sessões, e as falhas em cascata, quando um sinal falso se propaga por um encadeamento automatizado. Registro com destaque uma categoria que costuma passar despercebida e que é, na minha leitura, a mais relevante para quem supervisiona: a exploração da confiança humana, em que uma justificativa bem redigida induz o operador a aprovar algo prejudicial. A defesa mais recomendada contra todos os demais riscos é a aprovação humana, e o ataque mais eficaz contra essa defesa é uma boa explicação.
Convém a ressalva de método. Essas listas, mantidas por organizações do setor de segurança, são referência de mercado e vocabulário comum, não norma técnica com força obrigatória, e sua ordenação reflete tanto dados de incidentes quanto percepção da comunidade profissional.
O que fazer na prática acadêmica
A intuição inicial de quase todo usuário é acrescentar à instrução do assistente uma frase mandando ignorar comandos encontrados em documentos. Isso ajuda, deve ser feito e não basta, porque defesa e ataque disputam o mesmo espaço probabilístico, sem qualquer garantia de que a primeira prevaleça. A literatura que vem construindo referenciais de avaliação nesse campo mostra ganhos reais com técnicas de treinamento e de estruturação da entrada, mas nenhuma delas elimina o problema (Yi et al., 2025).
Daí a formulação que considero central. A pergunta correta não é como impedir que o modelo seja enganado, e sim o que deve permanecer intacto quando ele for enganado.
Na prática, isso se traduz em poucas condutas. Conceder ao assistente apenas as ferramentas e os acessos que a tarefa exige, e nada além. Exigir confirmação humana explícita para qualquer operação irreversível, com o conteúdo da ação apresentado de forma concreta, e não apenas a justificativa de quem a propõe. Tratar toda instrução encontrada dentro de um documento como informação a ser avaliada, jamais como ordem a ser cumprida. Submeter arquivos de terceiros a triagem prévia, inspecionando o que não aparece na tela, isto é, camadas ocultas, metadados, texto de dimensão mínima e conteúdo embutido, antes de entregá-los a qualquer ferramenta. Não carregar dados pessoais sensíveis de saúde, protocolos sob sigilo ou manuscritos em avaliação em serviços cujas políticas de retenção não se conheça, ponto em que a exigência não é apenas técnica, é jurídica, dado o regime de proteção conferido a dados de saúde. E manter registro do que foi lido, decidido e executado, porque sem trilha de auditoria um incidente é simplesmente indetectável.
Vale acrescentar que esse conjunto de cuidados se insere em uma discussão mais ampla sobre o uso responsável dessas ferramentas em medicina, na qual se tem sustentado que a governança precisa acompanhar a velocidade de adoção, com supervisão declarada e responsabilidade humana preservada (Harrer, 2023), e na qual já se defende expressamente a necessidade de supervisão regulatória específica para modelos de linguagem aplicados à saúde (Meskó e Topol, 2023). A segurança, aqui, não é um capítulo à parte da ética em pesquisa, é um de seus desdobramentos operacionais.
Considerações finais
A injeção de prompt é desconcertante porque não se parece com nenhuma ameaça que a formação acadêmica nos ensinou a reconhecer. Não há código malicioso, não há credencial roubada, não há alarme. Há apenas texto, escrito em português corrente, escondido em um arquivo que alguém enviou por vias inteiramente legítimas, e que o assistente lê com a mesma obediência com que lê o pedido do próprio usuário. Quem confere um parecer produzido dessa maneira não encontra sinal algum de que algo deu errado, porque nada, tecnicamente, deu errado.
A conduta que decorre disso é menos tecnológica do que parece. Consiste em reservar ao julgamento humano as decisões que importam, em limitar o que a ferramenta pode fazer sem que alguém confirme, em desconfiar de instruções que apareçam dentro de documentos e em lembrar que a fluência de um texto nunca foi, nem nunca será, evidência de sua correção. É a mesma disciplina que a pesquisa já exige em outros domínios, aplicada a um instrumento novo. Quem incorporar essa disciplina cedo vai usar essas ferramentas por muito mais tempo, e com muito menos sobressaltos, do que quem descobrir o problema depois de assinar um parecer que não escreveu.
Fontes
[1]. Greshake K, Abdelnabi S, Mishra S, Endres C, Holz T, Fritz M. Not what you’ve signed up for: compromising real-world LLM-integrated applications with indirect prompt injection. In: Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security. New York: ACM; 2023. p. 79-90.
DOI: https://doi.org/10.1145/3605764.3623985
Disponível em: https://doi.org/10.1145/3605764.3623985
Comentário: trabalho que demonstrou pela primeira vez, em aplicações reais, a viabilidade da injeção indireta, mostrando que basta ao atacante depositar conteúdo no caminho do sistema. Fundamenta a primeira e a segunda seções do texto e é a leitura de partida para quem quiser compreender a superfície de ataque de assistentes que consultam fontes externas.
[2]. Clusmann J, Ferber D, Wiest IC, Schneider CV, Brinker TJ, Foersch S, et al. Prompt injection attacks on vision language models in oncology. Nat Commun. 2025;16(1):1239.
DOI: https://doi.org/10.1038/s41467-024-55631-x
Disponível em: https://doi.org/10.1038/s41467-024-55631-x
Comentário: avaliação sistemática de modelos de visão e linguagem em tarefas oncológicas, com quase seiscentos ataques distribuídos entre quatro sistemas de ponta, sem acesso a parâmetros internos. Sustenta a terceira seção deste texto e é a evidência mais próxima da prática clínica de que o problema não se restringe a laboratórios de segurança.
[3]. Yi J, Xie Y, Zhu B, Kiciman E, Sun G, Xie X, et al. Benchmarking and defending against indirect prompt injection attacks on large language models. In: Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining. New York: ACM; 2025. p. 1809-20.
DOI: https://doi.org/10.1145/3690624.3709179
Disponível em: https://doi.org/10.1145/3690624.3709179
Comentário: referencial de avaliação que compara ataques e defesas de injeção indireta de modo padronizado, permitindo medir ganhos reais de cada técnica. Fundamenta a afirmação, na quinta seção, de que existem mitigações com efeito mensurável, porém nenhuma que elimine o problema.
[4]. Harrer S. Attention is not all you need: the complicated case of ethically using large language models in healthcare and medicine. eBioMedicine. 2023;90:104512.
DOI: https://doi.org/10.1016/j.ebiom.2023.104512
Disponível em: https://doi.org/10.1016/j.ebiom.2023.104512
Comentário: análise das condições éticas de uso de modelos de linguagem em medicina, com ênfase na necessidade de governança compatível com a velocidade de adoção. Sustenta a articulação, na quinta seção, entre segurança da informação e ética em pesquisa, tratadas aqui como faces do mesmo dever.
[5]. Meskó B, Topol EJ. The imperative for regulatory oversight of large language models (or generative AI) in healthcare. npj Digit Med. 2023;6(1):120.
DOI: https://doi.org/10.1038/s41746-023-00873-0
Disponível em: https://doi.org/10.1038/s41746-023-00873-0
Comentário: defesa da criação de supervisão regulatória específica para modelos de linguagem aplicados à saúde, antes que o uso se generalize sem parâmetros. Fundamenta a observação final do texto sobre governança e situa a discussão de segurança no plano institucional, e não apenas no individual.
Pontos para Recordar
- A injeção de prompt ocorre quando um conteúdo lido pelo assistente é interpretado como instrução em vez de dado, sem que haja invasão, senha quebrada ou código malicioso.
- A causa é estrutural: instrução do sistema, pedido do usuário e conteúdo externo chegam ao modelo em uma sequência única, sem fronteira que os separe.
- A modalidade indireta é a mais perigosa, pois o texto malicioso é depositado em documentos, páginas ou metadados que o assistente virá a ler no curso de uma tarefa legítima.
- Em arquivos, a instrução pode estar oculta em corpo mínimo, branco sobre branco, metadados, texto alternativo de imagem ou camadas invisíveis na tela.
- Estudo em oncologia com quase seiscentos ataques mostrou que modelos de visão e linguagem de ponta podem ser desviados sem qualquer acesso a seus parâmetros internos.
- Outras ameaças relevantes incluem divulgação de informação sensível, agência excessiva, comprometimento da cadeia de suprimentos, envenenamento de bases de consulta, desinformação e exploração da confiança de quem aprova.
- A mitigação eficaz é de arquitetura e de processo: permissões mínimas, confirmação humana para ações irreversíveis, triagem prévia de arquivos de terceiros e registro auditável do que foi lido e executado.
Declaração de uso de Inteligência Artificial Generativa
Este texto foi produzido com o auxílio de Claude, desenvolvida pela Anthropic, utilizado como ferramenta de apoio nas fases de brainstorming, de estruturação do conteúdo e de produção do texto. A responsabilidade pela versão final e precisão das informações, pelo pensamento crítico, pela seleção das fontes e pelo conteúdo publicado é integralmente do autor.