Prompt Injection in the Wild

Um rastreador de técnicas de prompt injection reportadas publicamente dos últimos dois anos, aproximadamente, mantido por Rachel James (cybershujin).

Cada técnica é dividida nos três elementos de um prompt injection:

1. Método de entrega — como as instruções injetadas chegam ao modelo (o resultado de uma chamada de ferramenta, um site externo, uma conexão MCP, um documento, um e-mail, uma imagem, etc.).
2. Codificação — a ofuscação aplicada ao payload, se houver (Base64, leetspeak, caracteres de tag Unicode invisíveis, homoglifos, …). Em branco quando o payload é texto simples ou o relatório não informa.
3. Comportamento de propagação — se a injeção foi projetada para se espalhar ou persistir (entregue a qualquer pessoa que se conecte a um servidor MCP envenenado, persistida na memória de longo prazo/projeto de um agente, transportada ao longo de uma cadeia de chamadas de ferramentas, feita para emitir um e-mail carregando instruções adicionais, …). Em branco quando não há propagação.

Cada entrada também registra os modelos contra os quais foi confirmada como funcional (se houver), um link para a fonte do relatório e — quando conhecida — a origem do ataque (o pesquisador, red team ou ator em atividade real de onde se originou).

Dashboard ao vivo: https://cybershujin.github.io/Prompt-Injection-in-the-Wild/

---

Escopo e metodologia

• No escopo: técnicas para injetar instruções adversariais em um LLM ou agente baseado em LLM que tenham sido reportadas publicamente — por pesquisadores de segurança, red teams, fornecedores, ou conforme observado em atividade real. Tanto prompt injection direto quanto indireto (transportado por dados) estão incluídos.
• Fora do escopo: wordlists genéricas de jailbreak sem mecanismo de entrega/propagação, reclamações puras sobre alinhamento de modelo e marketing sem substância técnica.
• Nunca adivinhado. Toda célula não vazia é retirada de uma declaração explícita na fonte citada. Se um relatório não declara a codificação, o comportamento de propagação, os modelos confirmados ou a origem do ataque, essa célula é deixada em branco — um espaço em branco significa "não declarado", nunca um "nenhum" inferido.
• Verificação. Cada entrada é marcada como Confirmed ou Not fully vetted. "Not fully vetted" sinaliza uma entrada cuja fonte é vaga, não confirmada, ou cujo mecanismo é pouco claro — ela é exposta em vez de descartada, para que um revisor possa julgá-la.
• Classe de evidência — in-the-wild vs. pesquisa. Cada entrada é marcada como In-the-wild (abuso real observado ou um incidente real em produção), Research / red-team (uma demonstração de pesquisador de segurança ou red team / divulgação responsável — uma técnica real e funcional, mas não observada sendo abusada por um atacante), Vendor advisory ou Unclear. Este é um eixo separado da verificação: uma técnica pode ser Confirmed (verificada e funcional) e ainda assim ter sido demonstrada apenas em laboratório. Esteja ciente: prompt injection malicioso genuinamente in-the-wild ainda é raramente documentado publicamente, então a grande maioria das entradas aqui são divulgações de pesquisa / red-team — no momento do preenchimento inicial, 29 de 32 eram pesquisa/red-team e apenas 3 eram in-the-wild. Use o filtro Evidence no dashboard para isolar os casos do mundo real.
• Atualizações. Novos relatos são varridos mensalmente (Perplexity sonar-deep-research, rede ampla) e propostos como um pull request de rascunho para revisão do mantenedor. Nada é mesclado automaticamente. Veja o rastreador irmão Threat-Actors-use-of-Artifical-Intelligence para o mesmo fluxo de trabalho aplicado ao uso de IA por atores de ameaça.

Como os dados são construídos

Os dados residem apenas na tabela abaixo (este arquivo é a única fonte de verdade). Um gerador determinístico e sem dependências (tools/build_exports.py) os compila a cada commit em:

• index.html — o dashboard interativo (servido via GitHub Pages),
• tracker.json — dados normalizados legíveis por máquina,
• stix/prompt-injection-stix2.1.json — um bundle STIX 2.1 (cada técnica como um attack-pattern, marcada com seu ID MITRE ATLAS e um mapeamento Not fully vetted → baixa confiança).

Não edite manualmente esses três arquivos; edite a tabela e deixe o CI reconstruí-los.

---

Técnicas