Cómo los atacantes explotan la 'personalidad' de los chatbots de IA

Hackear los primeros chatbots de IA era, según The Verge, un asunto casi cómico: bastaba escribir «ignora tus instrucciones anteriores» para que el modelo obedeciera sin rechistar. Eso era 2023. En 2026, los ataques que realmente funcionan son considerablemente más sofisticados, y apuntan a algo que los ingenieros de seguridad llevan meses advirtiendo: la «personalidad» del modelo, es decir, el conjunto de valores, restricciones y rol que se le asigna en el system prompt.

La pieza publicada el 24 de mayo en The Verge por Robert Hart lo pone sobre la mesa con claridad: los atacantes ya no intentan romper las reglas del modelo de frente. Aprenden a negociar con su identidad.

De los trucos de texto a la ingeniería de identidad

La primera generación de jailbreaks era puramente léxica: reformulaciones, codificaciones en base64, instrucciones contradictorias. Los modelos actuales —con RLHF más robusto y alineación reforzada en varias capas— resisten esos ataques bastante bien. Lo que ha emergido en su lugar es una técnica más sutil: convencer al modelo de que su «verdadero yo» es diferente del que Anthropic, OpenAI o quien sea ha configurado.

Esto se consigue de varias formas:

• Roleplay persistente: el atacante establece un escenario de ficción donde el modelo interpreta a un personaje sin las restricciones habituales. Si el escenario se sostiene suficiente tiempo en el contexto, el modelo puede empezar a responder desde ese marco.
• Autoridad fabricada: mensajes que simulan ser instrucciones del propio desarrollador o del sistema, aprovechando que el modelo no puede verificar la procedencia real de un system prompt.
• Erosión gradual: una serie de peticiones aparentemente inocuas que, acumuladas, desplazan el comportamiento del modelo hacia respuestas que no daría de entrada.

Ninguna de estas técnicas es nueva en teoría, pero su sofisticación práctica ha aumentado de forma notable. Hay comunidades dedicadas a documentar qué formulaciones funcionan contra qué modelos, con un nivel de metodología que recuerda al trabajo de un equipo de pentest.

Por qué los modelos con «personalidad» son un vector de ataque

Hay una ironía aquí que vale la pena señalar. Los modelos se hacen más seguros en parte dándoles una identidad más coherente y valores más arraigados. Pero esa misma identidad crea una superficie de ataque: si el modelo tiene un «yo», se puede intentar manipular ese yo.

En el caso de Claude, Anthropic ha publicado su Modelo de Constitución y la política de uso con bastante detalle, describiendo cómo se construye el carácter del modelo precisamente para que sea resistente a este tipo de manipulación. La apuesta es que una identidad bien formada es más robusta que una serie de reglas explícitas: el modelo no evita hacer daño porque «está prohibido», sino porque genuinamente no quiere hacerlo. En la práctica, esto funciona mejor que las listas negras de palabras, pero no es inmune.

Para quién importa esto y en qué medida

Este problema afecta de forma diferente a distintos perfiles:

• Equipos que despliegan Claude u otros modelos en producción: si usáis system prompts con roles personalizados —un agente de soporte, un asistente interno, un copiloto de código— conviene revisar si esos roles están diseñados de forma que un atacante no pueda «ampliarlos» mediante el contexto de conversación.
• Desarrolladores de servidores MCP y plugins: cuando un agente puede ejecutar herramientas externas, el radio de daño de un jailbreak exitoso deja de ser solo una respuesta de texto inapropiada y pasa a ser una acción real en un sistema.
• Equipos de seguridad corporativa: la prompt injection —inyectar instrucciones maliciosas en contenido que el modelo va a leer, como un correo o un documento— sigue siendo el vector más preocupante en entornos con agentes que consumen datos externos.

Los hooks de Claude Code, por ejemplo, permiten ejecutar comandos shell en eventos del ciclo de vida del agente. Si un atacante logra que el agente interprete instrucciones inyectadas en un archivo como legítimas, las consecuencias van mucho más allá de una respuesta de texto.

Qué hacer con esto hoy

No hay una solución única, pero sí algunas prácticas que reducen la superficie:

1. Mantener el system prompt lo más corto y específico posible; cada instrucción adicional es contexto que un atacante puede intentar contradecir.
2. Separar los permisos: un agente que solo necesita leer no debería tener herramientas de escritura.
3. Auditar los logs de conversación en busca de patrones de erosión gradual, no solo de palabras clave prohibidas.
4. Tratar cualquier contenido externo que el modelo vaya a procesar como potencialmente hostil, igual que se tratan las entradas de usuario en una aplicación web.

Desde ElephantPink, llevamos meses insistiendo en que la seguridad de los agentes no se puede resolver solo en el nivel del modelo. La arquitectura del sistema importa tanto como la alineación del LLM, y este tipo de cobertura ayuda a que esa conversación salga del ámbito de los equipos de red team y llegue a quienes están construyendo integraciones reales.