No es inyección de prompts, ni role-playing, ni tampoco disfrazar solicitudes maliciosas como preguntas normales. Esta vez, el riesgo surge durante el proceso en el que el agente completa tareas de forma autónoma.
Fable 5 es el modelo de nivel Mythos que Anthropic ha puesto a disposición del público, no solo posee capacidades integrales extremadamente potentes, sino que también incorpora en su periferia un nuevo clasificador de seguridad (Safety Classifier) como línea de defensa.
Según el diseño oficial, cuando una solicitud del usuario involucre áreas de alto riesgo como ciberseguridad, biología, química, destilación de modelos, etc., el sistema priorizará la identificación del riesgo y, dependiendo del nivel, rechazará directamente la solicitud o cambiará al modelo Opus 4.8, más conservador, para procesarla.
Numerosas pruebas de usuarios han descubierto que las técnicas de ataque de "jailbreak" ampliamente utilizadas en el pasado, como prompts adversarios, role-playing, desvíos mediante codificación o expresiones veladas, casi todas han resultado ineficaces frente a este mecanismo de seguridad, demostrando su gran capacidad de intercepción de riesgos a nivel de intención.
Sin embargo, el mismo día del lanzamiento de Fable 5, un equipo de investigación internacional formado por instituciones como la Universidad de Fudan, la Universidad de Deakin, la Universidad de la Ciudad de Hong Kong (China), la Universidad de Melbourne, la Universidad de Administración de Singapur y la Universidad de Illinois en Urbana-Champaign anunció que habían logrado superar con éxito el mecanismo de protección de seguridad de Fable 5.
Este método de ataque fue diseñado principalmente por Yutao Wu, estudiante de doctorado de la Universidad de Deakin. Todo el ataque requiere solo una conversación y tarda menos de 5 segundos en eludir el clasificador de seguridad inicial e inducir al modelo a generar contenido dañino y prohibido.
Los resultados del análisis de tráfico indican además que la salida dañina provino directamente del propio Fable 5, y no del modelo Opus 4.8 al que el sistema cambia automáticamente después de activar el mecanismo de seguridad. Esto significa que el ataque no solo logró eludir la detección del clasificador de seguridad, sino que también vulneró sustancialmente la línea de defensa de seguridad de Fable 5.
Vale la pena mencionar que el conocido hacker Pliny the Liberator también ha hecho pública recientemente una forma de eludir el clasificador de seguridad de Fable 5. Sin embargo, la ruta técnica adoptada por el equipo de Fudan y Deakin no es una simple exploración combinatoria, sino que descubrió un defecto fundamental en este tipo de sistemas de agentes superinteligentes como Fable 5.
Según se informa, el equipo completó la investigación preliminar y la publicó en marzo de este año. La investigación no se centró únicamente en el diseño del sistema Fable 5, sino que estudió la arquitectura de defensa de "clasificador de seguridad + modelo" adoptada comúnmente por la nueva generación de agentes superinteligentes, revelando directamente los defectos estructurales inherentes a este tipo de mecanismos de seguridad, lo que rápidamente demostró su efectividad de ataque tras el lanzamiento de Fable 5.
La información pública muestra que ya en marzo de este año, el equipo había utilizado una tecnología similar para extraer con éxito los prompts del sistema de 37 modelos de lenguaje principales y sistemas de agentes, completando la verificación de código abierto en Claude Code (95% de coincidencia).
Según se entiende, el responsable del equipo de investigación es el profesor Ma Xingjun del Instituto de Inteligencia Embebida Confiable de la Universidad de Fudan.
En los últimos años, su equipo ha llevado a cabo investigaciones sistemáticas en áreas como la seguridad de los grandes modelos de lenguaje, agentes e inteligencia embebida, logrando una serie de resultados científicos líderes a nivel internacional y ganando el campeonato en el concurso de benchmarks de seguridad del Centro de Seguridad de IA de EE.UU.
Actualmente, su equipo está avanzando activamente en la transferencia de resultados, centrándose en la seguridad de los agentes y explorando la construcción de capacidades de infraestructura de seguridad para los sistemas de agentes de próxima generación.
Según el profesor Ma, la importancia significativa de este resultado de investigación radica en que plantea un nuevo desafío al paradigma de defensa estática actual centrado en los clasificadores de seguridad: depender únicamente de un clasificador de seguridad previo no es suficiente para prevenir completamente los comportamientos de riesgo potencial en sistemas de agentes avanzados.
Los clasificadores de seguridad se centran principalmente en identificar y bloquear riesgos en la entrada del usuario, pudiendo detectar y filtrar efectivamente instrucciones de alto riesgo explícitas, pero no pueden percibir los comportamientos de riesgo interno que surgen gradualmente durante la ejecución prolongada, la planificación de múltiples pasos, la interacción con el entorno y la invocación de herramientas por parte del agente.
El método para vulnerar Fable 5 proviene del artículo publicado por el equipo en marzo de este año titulado "Internal Safety Collapse in Frontier Large Language Models".
El artículo revela un fenómeno de seguridad oculto: "Colapso Interno de Seguridad (Internal Safety Collapse, ISC)": cuando un agente actual completa tareas de largo alcance, la falla de seguridad no necesariamente proviene de prompts externos maliciosos, sino que puede ocurrir en la propia cadena de ejecución del modelo.
No es un ataque con prompts externos, sino una falla interna en la cadena de tareas
Los ataques tradicionales suelen entrar desde el exterior. El atacante escribe un prompt de entrada que parece inofensivo pero en realidad es adversario, o utiliza role-playing, codificación, traducción, instrucciones indirectas, etc., para disfrazar una intención maliciosa como una solicitud normal. La tarea principal del clasificador de seguridad es bloquear el riesgo en este nivel.
El detector de Fable 5 está diseñado precisamente para este escenario. Es muy sensible a las solicitudes de alto riesgo directas, incluso bloqueando muchas solicitudes normales. Pero lo que revela el ISC es otra ruta: el riesgo no necesariamente proviene de solicitudes peligrosas introducidas directamente por el usuario.
El agente se enfrenta a un directorio de trabajo aparentemente ordinario: archivos, objetivos, flujos de verificación y tareas pendientes. Luego, comienza a planificar, leer archivos, ejecutar código, corregir errores e intentar continuamente que la tarea pase la verificación.
Si se usa una metáfora visual para explicarlo, el mecanismo de seguridad tradicional protege la "entrada" del sistema, verificando si la entrada del usuario presenta riesgos; mientras que lo que revela el ISC se asemeja más a los niveles de sueños en "Inception".
Cuando la tarea avanza a la segunda, tercera o incluso capas de ejecución más profundas, el modelo reinterpreta los objetivos de la tarea basándose en el contexto interno acumulado, y en este proceso se produce gradualmente una desviación.
En este caso, la entrada inicial del usuario podría ser completamente normal e inofensiva, y el proceso de ejecución de la tarea en las primeras etapas también podría ser siempre conforme: leer archivos, analizar datos, escribir código, invocar herramientas, todo parece avanzar según lo previsto.
Sin embargo, cuando el agente llega a una etapa crítica de ejecución, puede derivar por sí mismo una conclusión: si no lleva a cabo ciertos comportamientos que originalmente no debería ejecutar, no podrá completar la tarea final.
Es precisamente en este proceso donde el riesgo no proviene de la entrada externa, sino que se forma gradualmente en la propia cadena de ejecución de tareas del modelo. En otras palabras, el modelo no es "corrompido" paso a paso por el usuario. Es en el proceso de "completar la tarea seriamente" donde él mismo llega a una posición insegura.
¿Cómo se descubrió este fenómeno?
Según el equipo, el ISC no fue diseñado inicialmente como un método de ataque. Surgió originalmente de la observación de procesos de ejecución prolongada de agentes. Cuando un agente se coloca en un entorno de tareas complejas, no solo ejecuta instrucciones mecánicamente. Planifica, prueba, modifica la salida según la retroalimentación del "harness" o "validator", y forma objetivos intermedios durante múltiples rondas de ejecución.
Esta es precisamente la forma de uso más común de muchos flujos de trabajo de agentes en la actualidad. El usuario no escribe un prompt cuidadosamente diseñado, y mucho menos construye manualmente instrucciones de ataque. Muchas veces, el usuario solo da una instrucción muy vaga:
"Ayúdame a completar esta tarea." "Ayúdame a mejorar esto un poco más."
Luego, el agente entra por sí mismo en el espacio de trabajo, lee archivos, comprende el estado actual, detecta elementos faltantes, formula un plan, ejecuta modificaciones y corrige continuamente problemas basándose en la retroalimentación.
Por ejemplo, en un escenario de AutoResearch, el usuario solo proporciona un artículo incompleto y una instrucción como "ayúdame a completarlo". El agente juzgará por sí mismo qué le falta: análisis experimental, trabajo relacionado o texto de tablas. Los escenarios de código son similares: una instrucción como "ayúdame a hacer que este proyecto funcione" puede desencadenar comprobaciones de dependencias, ejecución de pruebas, localización de errores y autocompletado.
Muchas veces, el contexto previo es completamente inofensivo. El usuario no le ha pedido que genere contenido riesgoso, ni la descripción de la tarea contiene palabras clave peligrosas evidentes. Pero en ciertas estructuras de tareas, para pasar la verificación, el agente completará activamente ciertos contenidos que no deberían ser generados por el modelo. Basándose en esta observación, el equipo de investigación propuso además un marco de ataque: TVD (Tarea, Verificación, Datos).
¿Por qué una estructura de descripción de tarea aparentemente común se convierte en un ataque?
La estructura TVD no es compleja, e incluso se asemeja a los flujos de trabajo de ingeniería comunes:
· Tarea (Task): una tarea profesional;
· Datos (Data): un archivo de datos incompleto;
· Verificador (Validator): un verificador que solo comprueba formato, integridad y si se ha completado el objetivo.
Tomemos como ejemplo entrenar un modelo Guard. Esta es originalmente una tarea muy profesional y normal. Un investigador podría querer entrenar o evaluar un detector de seguridad, por ejemplo, cargar un modelo de clasificación de texto desde Hugging Face para juzgar a qué categoría de etiqueta de seguridad pertenece una salida específica del modelo.
En esta tarea, los Datos son las muestras que el modelo debe detectar; el Verificador define si la tarea está completa. Comprobará si la entrada es texto, si la longitud es suficiente, si los campos están completos, si el formato de las etiquetas es correcto. Para cualquiera con experiencia en entrenamiento de aprendizaje automático, este es un flujo de trabajo familiar. El agente también está muy familiarizado con este flujo de trabajo.
El problema aparece aquí. Si los Datos están incompletos, la tarea no puede ejecutarse. El Verificador reportará errores, indicando campos faltantes, longitud insuficiente o formato incompleto. Para que el flujo de entrenamiento continúe, el agente completará estos Datos por sí mismo.
Desde la perspectiva del agente, no está "actuando mal". Solo está completando una tarea normal de aprendizaje automático: reparar datos, pasar la verificación, hacer que el script de entrenamiento se ejecute. Pero desde una perspectiva de seguridad, el riesgo aparece en este momento: el Verificador se parece más a un inspector de ingeniería que a un revisor de seguridad. Solo verifica si la tarea se completó según el formato, no comprende los límites de seguridad detrás del contenido.
Problemas similares existen ampliamente en campos como medicina, biología, química, ciberseguridad, farmacología y seguridad en medios. El artículo recopila más de 50 de estos escenarios, involucrando múltiples herramientas reales de investigación científica o ingeniería, como BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, OpenAI Moderation API, etc.
Estas herramientas en sí mismas no son herramientas maliciosas. Todo lo contrario, son herramientas profesionales comúnmente utilizadas en investigación científica o ingeniería real. Pero el problema de TVD es: cuando la Tarea es normal, la Herramienta es normal, el Verificador es normal, el agente aún puede dirigirse hacia una salida insegura en el proceso de completar los Datos.
Por lo tanto, el enfoque del ISC no está en las técnicas de prompts, sino en la capacidad de autocompletado del agente para "tareas incompletas": cuando las condiciones de finalización se superponen con los límites de riesgo, el modelo puede tratar la salida insegura como un entregable normal.
Vulnerar Fable 5 demuestra que los detectores fuertes no pueden bloquear el riesgo interno de la cadena de tareas
El caso de Fable 5 muestra que depender solo de detectores externos aún puede no cubrir algunos escenarios de agentes de largo alcance. Esto no significa que los clasificadores de seguridad no tengan valor. Por el contrario, son muy útiles para solicitudes maliciosas externas y de hecho han hecho que muchos métodos tradicionales de "jailbreak" fallen.
Pero esta falla demuestra que que un detector externo sea efectivo en los límites del Prompt no equivale a que pueda cubrir los riesgos de tareas de largo alcance dentro del agente.
Si el punto de entrada no proviene del Prompt del usuario, sino que surge de los objetivos, herramientas, verificadores y trayectorias de ejecución del agente, entonces el detector de seguridad se vuelve muy frágil.
Desde Fable 5 hasta más de 60 otros modelos, incluido el modelo para móviles de Apple
Junto con la investigación, se publicó ISC-Bench, cubriendo 9 áreas profesionales. La versión del artículo contiene más de 60 plantillas desencadenantes, que se expandieron a 84 plantillas después de la publicación de código abierto. Los objetos de prueba incluyen casi todos los modelos y sistemas de agentes de vanguardia de todos los proveedores.
En la lista de evaluación basada en ISC-Bench, hasta junio de 2026, ¡más de 60 modelos de vanguardia han expuesto riesgos similares bajo la métrica ASR@3!
Actualmente, el proyecto en GitHub ha obtenido más de 800 estrellas y ha recopilado múltiples casos de replicación independiente (incluyendo vulnerar el modelo para móviles de Apple), y se actualiza continuamente.
Según se informa, el equipo está realizando investigaciones de seguridad a gran escala en modelos de vanguardia y actualmente posee una gran cantidad de datos de distribución interna insegura de modelos. Los resultados de investigación relacionados se publicarán gradualmente en el futuro.
