Un chatbot de atención al cliente filtró sus propios prompts de sistema tras una simple petición de una receta de cordero. En cuestión de minutos, el bot no solo proporcionó la receta, sino que también generó código Python y reveló las instrucciones internas que guían su comportamiento.
El incidente demuestra que el "prompt de sistema" de un modelo de lenguaje no es un muro de seguridad. Cuando un bot decide sobre la marcha si la petición de un usuario encaja con su misión, un atacante puede desviar ese razonamiento y lograr que el modelo exponga información privilegiada.
Qué desencadenó la brecha
La prueba comenzó con una pregunta sencilla: "¿Puedes darme una receta de estofado de cordero?". El bot, cuyo propósito declarado era explicar los servicios de la empresa, respondió con una receta completa, añadió un breve script de Python que analizaba los ingredientes y luego imprimió el texto exacto de su prompt de sistema: el texto que le indica al modelo cómo comportarse.
La petición en sí era inofensiva; el peligro residía en la disposición del bot a tratar la receta como parte de su tarea principal.
Por qué es importante
Los chatbots ocupan ahora funciones de cara al cliente, gestionando datos personales, activando transacciones o controlando herramientas internas. Si se puede inducir a un modelo a revelar su propio conjunto de instrucciones, un atacante obtiene información sobre las barreras de seguridad que supuestamente deberían impedir que el modelo realice acciones perjudiciales.
Cómo funciona el ataque
- Perfilar el propósito del bot – El evaluador identificó que la función del bot era explicar los servicios de la empresa.
- Crear un vínculo falso – Al afirmar que la receta era necesaria para decidir qué servicio debía usar el usuario, el evaluador le dio a la petición una relevancia superficial con la misión del bot.
- Explotar la lógica – El bot aceptó la relevancia fabricada, permitió que la petición superara su comprobación de relevancia interna y desactivó las barreras de seguridad que la habrían bloqueado.
El ataque se basa en la autoevaluación de relevancia del modelo. Cuando esa evaluación puede ser influenciada, las propias "reglas" del modelo se vuelven negociables.
Tres puntos de fallo
| Etapa del fallo | Qué sucedió |
|---|---|
| Secuestro de objetivos | El bot trató una petición de cocina no relacionada como parte de su objetivo de explicación de servicios. |
| Deriva de capacidades | Generó código Python ejecutable a pesar de que su función no incluía la generación de código. |
| Filtración de prompts | Imprimió el prompt de sistema exacto que debía permanecer oculto. |
Cada etapa representa la ruptura de una capa defensiva diferente que muchos despliegues asumen que el propio modelo aplica.
Capas defensivas que realmente funcionan
Sacar las barreras de seguridad del modelo y trasladarlas al código determinista restaura un límite de seguridad fiable.
- Enrutamiento de tareas – Utilice un clasificador independiente para asignar los mensajes entrantes a una lista fija de intenciones permitidas. Si una petición queda fuera de esa lista, rechácela directamente. El modelo nunca llegará a discutir sobre la relevancia.
- Capacidad mínima – Despoje al bot de las herramientas que no necesita. Si no requiere ejecución de código o acceso amplio a bases de datos, elimine esas capacidades.
- Autorización determinista – Realice las comprobaciones de permisos en el código de la aplicación, no en el modelo de lenguaje. El modelo puede sugerir una acción, pero el código decide si la lleva a cabo.
- Validación de salida – Escanee cada respuesta del modelo en busca de contenido no permitido —como prompts de sistema o datos sensibles— antes de que llegue al usuario.
Un filtro que simplemente pregunta "¿Está prohibida esta petición?" puede ser eludido por un usuario persuasivo. Una capa de enrutamiento que comprueba contra una lista cerrada no deja lugar a la negociación.
Qué vigilar a continuación
Las empresas que dependen de la IA conversacional deben auditar sus despliegues en busca de los tres modos de fallo ilustrados por la prueba de la receta de cordero. Mientras tanto, trate cualquier prompt de sistema como conocimiento público; no cuente con él para evitar que un modelo se revele a sí mismo.
La conclusión es clara: si su modelo de seguridad depende de un párrafo de instrucciones en lenguaje natural, es frágil. Refuércelo con código que pueda ser auditado, versionado y aplicado independientemente de lo que diga el modelo.