Inyección de prompts en estado salvaje

Un rastreador de técnicas de inyección de prompts reportadas públicamente de aproximadamente los últimos dos años, mantenido por Rachel James (cybershujin).

Cada técnica se desglosa en los tres elementos de una inyección de prompts:

1. Método de entrega — cómo las instrucciones inyectadas llegan al modelo (el resultado de una llamada a una herramienta, un sitio web externo, una conexión MCP, un documento, un correo electrónico, una imagen, etc.).
2. Codificación — la ofuscación aplicada al payload, si la hay (Base64, leetspeak, caracteres de etiqueta Unicode invisibles, homoglifos, …). En blanco cuando el payload es texto plano o el informe no lo indica.
3. Comportamiento de propagación — si la inyección está diseñada para propagarse o persistir (entregada a cualquiera que se conecte a un servidor MCP envenenado, persistida en la memoria a largo plazo/de proyecto de un agente, arrastrada a lo largo de una cadena de llamadas a herramientas, forzada a emitir un correo electrónico que transporta más instrucciones, …). En blanco cuando no hay propagación.

Cada entrada también registra los modelos contra los que se confirmó que funciona (si los hay), un enlace a la fuente que lo reporta y — cuando se conoce — la fuente del ataque (el investigador, el equipo rojo o el actor en estado salvaje del que se originó).

Panel en vivo: https://cybershujin.github.io/Prompt-Injection-in-the-Wild/

---

Alcance y metodología

• Dentro del alcance: técnicas para inyectar instrucciones adversarias en un LLM o en un agente impulsado por LLM que hayan sido reportadas públicamente — por investigadores de seguridad, equipos rojos, proveedores, o según lo observado en actividad en estado salvaje. Se incluyen tanto la inyección de prompts directa como la indirecta (transportada por datos).
• Fuera del alcance: listas genéricas de palabras para jailbreak sin mecanismo de entrega/propagación, quejas puras sobre la alineación de modelos, y marketing sin sustancia técnica.
• Nunca se adivina. Cada celda no vacía se toma de una declaración explícita en la fuente citada. Si un informe no indica la codificación, el comportamiento de propagación, los modelos confirmados o la fuente del ataque, esa celda se deja en blanco — un blanco significa "no declarado", nunca un "ninguno" inferido.
• Verificación. Cada entrada se marca como Confirmed o Not fully vetted. "Not fully vetted" señala una entrada cuya fuente es vaga, no confirmada, o cuyo mecanismo no está claro — se muestra en lugar de descartarse, para que un revisor pueda juzgarla.
• Clase de evidencia — en estado salvaje vs. investigación. Cada entrada se etiqueta como In-the-wild (abuso observado en el mundo real o un incidente real en producción), Research / red-team (una demostración de un investigador de seguridad o equipo rojo / divulgación responsable — una técnica real y funcional, pero no observada siendo abusada por un atacante), Vendor advisory o Unclear. Este es un eje separado de la verificación: una técnica puede estar Confirmed (verificada y funcional) y aun así haber sido demostrada únicamente en un laboratorio. Tenga en cuenta: la inyección de prompts maliciosa genuina en estado salvaje todavía se documenta raramente en público, por lo que la gran mayoría de las entradas aquí son divulgaciones de investigación / equipo rojo — en el momento del backfill inicial, 29 de 32 eran de investigación/equipo rojo y solo 3 eran en estado salvaje. Use el filtro Evidence en el panel para aislar los casos del mundo real.
• Actualizaciones. Los nuevos informes se rastrean mensualmente (Perplexity sonar-deep-research, red amplia) y se proponen como un pull request en borrador para revisión del mantenedor. Nada se fusiona automáticamente. Consulte el rastreador hermano Threat-Actors-use-of-Artifical-Intelligence para el mismo flujo de trabajo aplicado al uso de IA por parte de actores de amenazas.

Cómo se construyen los datos

Los datos viven únicamente en la tabla de abajo (este archivo es la única fuente de verdad). Un generador determinista y sin dependencias (tools/build_exports.py) los compila en cada commit en:

• index.html — el panel interactivo (servido a través de GitHub Pages),
• tracker.json — datos normalizados legibles por máquina,
• stix/prompt-injection-stix2.1.json — un bundle STIX 2.1 (cada técnica como un attack-pattern, etiquetada con su ID de MITRE ATLAS y un mapeo Not fully vetted → baja confianza).

No edite manualmente esos tres archivos; edite la tabla y deje que CI los reconstruya.

---

Técnicas