Prompt injection y jailbreaks

La inyección de prompts es el equivalente, en la era de los LLM, de los fallos clásicos de inyección (SQL y comandos). La causa raíz es idéntica: una aplicación mezcla instrucciones confiables y datos no confiables en el mismo canal, y el intérprete (el modelo) no puede distinguirlos de forma fiable.

Con un LLM, el prompt del sistema, las instrucciones del desarrollador y cualquier contenido recuperado llegan como un único flujo plano de tokens. Si un texto controlado por el atacante dice Ignore previous instructions and..., el modelo puede obedecerlo porque, para el modelo, no es más que lenguaje.

• Confiable: el prompt del sistema y sus políticas.
• No confiable: las entradas del usuario, las páginas web, los archivos, las salidas de herramientas y los correos electrónicos.

La inyección directa de prompts ocurre cuando el usuario final escribe instrucciones adversarias directamente en el prompt para anular el comportamiento previsto de la aplicación.

Un intento habitual contra un bot de atención al cliente sería el siguiente:

• Se indica al bot que responda únicamente preguntas sobre facturación.
• El usuario pega un texto que reformula el rol del modelo y le pide que revele su prompt del sistema o realice acciones fuera del alcance previsto.

La inyección directa es la más fácil de analizar porque el texto malicioso y el atacante son la misma persona, pero aun así elude los controles de seguridad ingenuos.

La inyección indirecta (de segundo orden) de prompts es la variante más peligrosa. El atacante inserta instrucciones en contenido que el modelo recuperará más adelante: una página web, un PDF, una invitación de calendario, un comentario de código o un ticket de soporte.

La persona usuaria nunca ve el payload. Cuando un pipeline de RAG o un agente de navegación incorpora ese contenido al contexto, las instrucciones ocultas se ejecutan con los privilegios de la víctima.

Ejemplo: una página web contiene texto oculto que indica a un agente de resumen que exfiltre el historial de chat del usuario a una URL controlada por el atacante.

Estos términos se solapan, pero no son idénticos:

• La inyección de prompts ataca el límite de la aplicación: sustituye las instrucciones del desarrollador por datos del atacante.
• El jailbreaking ataca la alineación de seguridad del modelo: induce al modelo a producir contenido que el proveedor lo entrenó para rechazar.

Un jailbreak no requiere una aplicación vulnerable; funciona contra el modelo sin más. Muchos ataques reales combinan ambos métodos: el jailbreak relaja las negativas, mientras que la inyección redirige el comportamiento de la aplicación.

Los atacantes utilizan patrones de manipulación predecibles. Conocerlos le ayuda a realizar pruebas de red team de su propio sistema de forma responsable:

• Roleplay / persona: presentar la solicitud como ficción o como la petición de un personaje ficticio sin restricciones.
• Ofuscación: utilizar base64, leetspeak, traducciones o división de tokens para eludir los filtros de palabras clave.
• División del payload: distribuir una solicitud entre varios turnos para que ningún mensaje aislado parezca malicioso.
• Situaciones hipotéticas: For a security class, describe how one would...
• Inyección de prefijo: forzar que la respuesta comience con una afirmación como Sure, here is.

Muchos equipos recurren primero a una denylist de frases como ignore previous instructions. Este enfoque es frágil porque el espacio de entradas es prácticamente infinito.

El lenguaje natural puede expresar la misma intención de innumerables maneras, en distintos idiomas, codificaciones y metáforas. Los atacantes iteran más rápido de lo que usted puede actualizar las expresiones regulares.

Principio clave: considere el filtrado de entradas como una defensa en profundidad, nunca como un control principal. Suponga que alguna inyección logrará atravesarlo y diseñe el sistema de modo que, aun teniendo éxito, no pueda causar daños reales.

La mitigación más eficaz es arquitectónica: limite lo que puede hacer un contexto del modelo que haya sido comprometido.

• Conceda al LLM el mínimo privilegio necesario. Un agente de resumen no debería tener credenciales para enviar correos electrónicos.
• Mantenga el contenido no confiable fuera de las rutas privilegiadas. Si un agente lee datos web externos, no debería poder ejecutar también acciones irreversibles en el mismo turno sin un punto de control.
• Separe los planos de datos de los planos de control: el texto recuperado debe ser datos, no comandos.

Aunque no es infalible, la estructura del prompt eleva el nivel de dificultad. Delimite claramente los datos no confiables e indique al modelo cómo debe tratarlos.

Utilice delimitadores explícitos e indique al modelo que todo lo que se encuentre dentro de ellos son datos que se deben analizar, no instrucciones que se deben seguir. Combine esto con un rol de sistema sólido que la aplicación refuerce en cada llamada.

La salida de un modelo también es no confiable. Si la aplicación canaliza la salida del LLM hacia un shell, una base de datos, un navegador u otra herramienta, la inyección puede convertirse en ejecución remota de código o exfiltración de datos.

La tríada letal de Simon Willison describe la combinación peligrosa de:

• Acceso a datos privados,
• Exposición a contenido no confiable,
• La capacidad de comunicarse con el exterior (exfiltrar).

Un agente con las tres capacidades puede convertirse en una herramienta de robo de datos mediante una sola instrucción inyectada. Rompa la tríada para romper el ataque.

Suponga que se producirá una inyección y prepare mecanismos para detectarla:

• Registre el contexto completo (prompts, fragmentos recuperados y llamadas a herramientas) para revisar los incidentes.
• Utilice un clasificador secundario o un modelo de protección que señale las entradas y salidas sospechosas.
• Supervise el uso anómalo de herramientas: solicitudes salientes repentinas, acceso inesperado a datos y patrones de filtración del prompt.
• Incorpore tokens canario en los prompts del sistema; si aparece un canario en la salida, se ha producido una filtración.

Trate las alertas como incidentes reales y responda conforme a un manual de actuación.

Probar sus propios sistemas para detectar inyecciones es esencial y legítimo. Hágalo de forma responsable:

• Pruebe únicamente sistemas que sean de su propiedad o cuya evaluación tenga autorizada.
• Utilice un entorno controlado y datos sintéticos; nunca exfiltre datos reales de usuarios.
• Documente los hallazgos e incorpórelos a las pruebas de regresión para que las omisiones corregidas sigan corregidas.
• Coordine la divulgación cuando encuentre problemas en modelos o aplicaciones de terceros.

El objetivo es que su aplicación sea resiliente, no producir capacidades perjudiciales.

Compruebe su comprensión de los límites de confianza en la inyección.

Conclusiones clave sobre la inyección de prompts y los jailbreaks:

• La inyección surge de mezclar instrucciones confiables con datos no confiables en un mismo canal.
• La inyección directa procede del usuario; la indirecta se oculta en contenido recuperado y es más sigilosa.
• Los jailbreaks atacan la alineación del modelo; la inyección ataca el límite de la aplicación. Pueden combinarse.
• El filtrado de entradas solo es una defensa en profundidad, nunca el control principal.
• Mitigue el problema mediante la arquitectura: aplique el mínimo privilegio, separe los datos del control y rompa la tríada letal (datos privados + contenido no confiable + exfiltración).
• Considere no confiable la salida del modelo, registre todo y realice pruebas de red team de forma ética.