ResumeShield propõe separação de canais como defesa definitiva contra prompt injection oculta em currículos analisados por IA
Candidatos podem esconder instruções dentro de currículos usando texto branco, fonte de tamanho zero, metadados ou caracteres de largura zero, que passam despercebidos por revisores humanos mas são lidos e obedecidos por pipelines de triagem baseados em LLM — uma injeção indireta classificada pela OWASP como LLM01:2025. O ResumeShield demonstra que colocar o conteúdo do candidato em um canal de dados explicitamente isolado elimina sozinho 100% dos ataques testados, enquanto filtragem de conteúdo sem essa separação ainda deixa 16,7% dos ataques funcionando.
O cenário de ameaça aqui é particularmente interessante porque inverte a relação de confiança usual entre avaliador e avaliado: normalmente confiamos mais em quem avalia do que no material avaliado, mas um triador de currículos baseado em LLM lê um documento fornecido justamente pela pessoa que está sendo avaliada, criando um incentivo direto para o candidato manipular o processo de decisão embutindo instruções dentro do próprio documento. Como um revisor humano não vê essas instruções (por estarem visualmente ocultas), a manipulação passa despercebida até chegar à etapa de extração de texto do pipeline automatizado.
O artigo cataloga nove técnicas de ocultação usadas para esconder o payload: texto na cor de fundo, fonte de tamanho zero, elementos de marcação/HTML ocultos, comentários no formato do documento, campos de metadados, e caracteres de largura zero intercalados no texto visível. Todas elas exploram a mesma lacuna: o pipeline de extração de texto (usado para converter o documento em uma string que vai para o prompt do LLM) normalmente não distingue o texto que um humano veria do texto presente no arquivo, então tudo que está tecnicamente presente no documento acaba entrando no contexto do modelo como se fosse conteúdo legítimo do currículo.
A defesa do ResumeShield combina quatro camadas: três estágios de filtragem de conteúdo (detecção de padrões de instrução, normalização de caracteres invisíveis, etc.) mais uma camada arquitetural que separa fisicamente o conteúdo do candidato em um canal de dados explicitamente declarado como não confiável nas instruções do operador — uma aplicação direta do princípio de separação entre canal de instrução e canal de dados que tem sido recomendado como mitigação estrutural contra prompt injection em geral, não só para currículos. O resultado da ablação é o dado mais informativo do artigo: a separação de canais sozinha (sem nenhuma filtragem de conteúdo) já elimina 100% dos ataques testados, enquanto a pilha completa de filtragem sem essa separação arquitetural ainda deixa 16,7% dos ataques bem-sucedidos.
Isso reforça um padrão que já vinha aparecendo na literatura de segurança de LLM: filtros de conteúdo (block-lists, classificadores de intenção) são uma defesa frágil e reativa, enquanto mudanças arquiteturais que estabelecem por design quais partes do prompt são dados e quais são instruções confiáveis tendem a fechar classes inteiras de ataque de uma vez. Para qualquer sistema de triagem automatizada que processa documentos fornecidos por partes com incentivo para manipular o resultado (currículos, propostas, formulários de solicitação), a lição prática é priorizar isolamento arquitetural de canal antes de investir em heurísticas de detecção de payload.