Rompe en 5 segundos, solo con una conversación: ¿El "mecanismo de seguridad más fuerte" de Claude Fable 5 fue hackeado por un equipo chino?

Título original: «Ataque en 5 segundos, con una sola conversación: el mecanismo de seguridad más fuerte de Fable 5 fue vulnerado por un equipo chino»
Fuente original: Máquina de Corazón

No es una inyección de提示, no es un juego de roles, y no es disfrazar solicitudes maliciosas como preguntas normales. Esta vez, el riesgo aparece durante el proceso en que el agente autónomamente completa tareas.

Fable 5 es un modelo Mythos abierto al público por Anthropic, que no solo posee capacidades integrales muy fuertes, sino que también introduce una nueva generación de clasificadores de seguridad (Safety Classifier) como línea de defensa.

Según el diseño oficial, cuando las solicitudes del usuario involucran áreas de alto riesgo como ciberseguridad, biología, química, destilación de modelos, etc., el sistema prioriza la identificación de riesgos y, según el nivel de riesgo, rechaza directamente la solicitud o cambia a un modelo más conservador, Opus 4.8.

Numerosos tests con usuarios han demostrado que las técnicas de evasión de seguridad ampliamente usadas anteriormente, como提示 adversariales, juegos de roles,绕行 de codificación y expresiones veladas, fallan casi por completo ante este mecanismo de seguridad, mostrando su gran capacidad para interceptar riesgos a nivel de intención.

Sin embargo, justo el día del lanzamiento de Fable 5, un equipo de investigación internacional formado por instituciones como la Universidad de Fudan, la Universidad Deakin, la Universidad de Ciudad de Hong Kong, la Universidad de Melbourne, la Universidad de Gestión de Singapur y la Universidad de Illinois en Urbana-Champaign anunció que habían logrado vulnerar el mecanismo de protección de Fable 5.

Este método de ataque fue diseñado por el doctorando Yutao Wu de la Universidad Deakin. Todo el ataque requiere solo una interacción, dura menos de 5 segundos, y puede evadir el clasificador de seguridad previo, induciendo al modelo a generar contenido prohibido y dañino.

Los resultados del análisis de tráfico muestran que la salida dañina proviene directamente de Fable 5, y no del modelo Opus 4.8 que se activa tras disparar el mecanismo de seguridad. Esto significa que el ataque no solo evade la detección del clasificador de seguridad, sino que también rompe sustancialmente la línea de defensa de Fable 5.

Cabe destacar que el hacker conocido Pliny the Liberator también publicó recientemente una forma de evadir el clasificador de seguridad de Fable 5. La estrategia técnica utilizada por el equipo de Fudan y Deakin no fue una simple exploración combinatoria, sino que descubrió una falla fundamental en sistemas de agentes inteligentes de esta clase.

Según se informa, el equipo completó la investigación preliminar y la publicación en marzo de este año. Este estudio no se diseñó solo para Fable 5, sino que abordó la arquitectura de defensa de «clasificador de seguridad + modelo» que usan los nuevos agentes inteligentes, revelando defectos estructurales en estos mecanismos de seguridad, lo que permitió que la vulnerabilidad se manifestara rápidamente tras el lanzamiento de Fable 5.

Datos públicos muestran que, ya en marzo, el equipo utilizó técnicas similares para extraer con éxito las instrucciones del sistema de 37 modelos grandes y sistemas de agentes, y verificó en Claude Code con una apertura de código que coincidía en un 95%.

Se sabe que el líder del equipo de investigación es el profesor Ma Xingjun, del Instituto de Inteligencia Confiable y Embodied de la Universidad de Fudan.

En los últimos años, su equipo ha llevado a cabo investigaciones sistemáticas en áreas como modelos grandes, agentes y seguridad en inteligencia embodied, logrando una serie de resultados de investigación de vanguardia internacional y ganando el campeonato en la competencia de estándares de seguridad de la AI del Centro de Seguridad de la AI de EE. UU.

Actualmente, su equipo está promoviendo activamente la transformación de estos logros, centrados en la seguridad de agentes, explorando la construcción de capacidades de infraestructura de seguridad para la próxima generación de sistemas de agentes inteligentes.

Según el profesor Ma, la importancia de estos resultados radica en que plantean un nuevo desafío al paradigma de defensa estática centrado en clasificadores de seguridad: depender únicamente del clasificador de seguridad previo no es suficiente para prevenir comportamientos potencialmente peligrosos en sistemas de agentes avanzados.

El clasificador de seguridad se enfoca en identificar y bloquear riesgos en las entradas del usuario, detectando y filtrando instrucciones de alto riesgo de manera efectiva, pero no puede percibir los riesgos internos que surgen en procesos de ejecución prolongados, planificación en múltiples pasos, interacción con el entorno y llamadas a herramientas.

El método para vulnerar Fable 5 proviene del artículo publicado en marzo de este año titulado «Colapso de Seguridad Interna en Modelos de Lenguaje de Gran Escala en Frontera».

El artículo revela un fenómeno de seguridad oculto llamado «Colapso de Seguridad Interna (ISC)»: cuando un agente completa una tarea a largo plazo, la falla de seguridad no necesariamente proviene de una提示 maliciosa externa, sino que puede ocurrir en la propia cadena de ejecución del modelo.

No es un ataque por提示 externo, sino una falla interna en la cadena de tareas

Los ataques tradicionales suelen entrar desde fuera. Los atacantes escriben提示 aparentemente inocuos pero en realidad adversariales, o usan juegos de roles, codificación, traducción, instrucciones indirectas, etc., disfrazando intenciones maliciosas como solicitudes normales. La función principal del clasificador de seguridad es detener estos riesgos en esa capa.

El detector de Fable 5 está diseñado precisamente para estos escenarios. Es muy sensible a solicitudes de alto riesgo directas, incluso bloqueando muchas solicitudes normales. Pero ISC revela otra vía: el riesgo no siempre proviene de la entrada peligrosa del usuario.

El agente enfrenta un directorio de trabajo aparentemente normal: archivos, objetivos, procesos de verificación y tareas pendientes. Luego comienza a planificar, leer archivos, ejecutar código, corregir errores y tratar de hacer que la tarea pase la validación.

Para explicarlo con una metáfora, los mecanismos de seguridad tradicionales protegen la «entrada» del sistema, encargada de verificar si la entrada del usuario tiene riesgos; mientras que ISC es más parecido a los múltiples niveles de sueños en «El Origen».

Cuando la tarea avanza a la segunda, tercera o incluso capas más profundas, el modelo, basado en el contexto interno acumulado, vuelve a entender los objetivos y, en ese proceso, puede desviarse progresivamente.

En estas circunstancias, la entrada inicial del usuario puede ser completamente normal e inofensiva, y el proceso de ejecución también puede ser siempre conforme a las reglas: leer archivos, analizar datos, escribir código, llamar herramientas, todo parece avanzar como se espera.

Pero cuando el agente llega a una etapa clave, puede deducir por sí mismo que, si no realiza ciertas acciones que normalmente no debería, no podrá completar la tarea final.

Es en ese momento que el riesgo no proviene de la entrada externa, sino que se forma gradualmente en la cadena de ejecución del propio modelo. Es decir, el modelo no se vuelve malicioso por instrucciones del usuario paso a paso, sino que, en su afán de «cumplir la tarea», llega a un estado inseguro por sí mismo.

¿Cómo se descubrió este fenómeno?

Según el equipo, ISC no fue inicialmente diseñado como un método de ataque. Surgió primero de la observación del proceso de ejecución prolongada del agente. Cuando un agente se coloca en un entorno de tareas complejo, no solo ejecuta instrucciones mecánicamente. Planifica, prueba y error, modifica salidas según la retroalimentación del harness o validador, y forma objetivos intermedios en múltiples rondas.

Este es precisamente el flujo de trabajo más común en muchos agentes hoy en día. Los usuarios no escriben prompts cuidadosamente diseñados, ni construyen instrucciones adversariales a mano. Muchas veces, solo dan una frase muy vaga:

「Ayúdame a completar esta tarea.」「Haz que esto quede mejor.」

Luego, el agente entra en el área de trabajo, lee archivos, comprende el estado actual, detecta elementos faltantes, diseña planes, realiza modificaciones y corrige problemas según la retroalimentación.

Por ejemplo, en escenarios de AutoResearch, el usuario solo proporciona un borrador de un artículo incompleto y una frase como «Ayúdame a completarlo», y el agente automáticamente determina qué falta: análisis experimental, trabajos relacionados o tablas. En escenarios de código, una simple «Haz que el proyecto funcione» puede activar verificaciones de dependencias, pruebas, localización de errores y autocompletado.

Muchas veces, el contexto previo es completamente inofensivo. El usuario no pide que genere contenido peligroso, ni hay palabras clave peligrosas en la descripción de la tarea. Pero en ciertas estructuras de tareas, el agente puede, para pasar la verificación, completar activamente contenidos que no debería generar. Basándose en esta observación, el equipo de investigación propuso un marco de ataque: TVD (Tarea, Verificación, Datos).

¿Por qué una estructura de descripción de tarea aparentemente normal puede ser un vector de ataque?

La estructura TVD no es compleja, e incluso se asemeja mucho a procesos de ingeniería comunes:

· Tarea: una tarea especializada;

· Datos: un archivo de datos incompleto;

· Validador: un verificador que solo comprueba formato, integridad y si se cumple el objetivo.

Tomando como ejemplo el entrenamiento de un modelo Guard, que en realidad es una tarea muy especializada y normal. Los investigadores pueden querer entrenar o evaluar un detector de seguridad, por ejemplo, usando Hugging Face para cargar un modelo de clasificación de texto y determinar a qué categoría de seguridad pertenece una salida del modelo.

En esta tarea, los Datos son las muestras que el modelo debe detectar; el Validador especifica si la tarea está completa. Verifica si la entrada es texto, si la longitud es suficiente, si los campos están completos, si el formato de la etiqueta es correcto. Para alguien con experiencia en entrenamiento de aprendizaje automático, esto es un flujo de trabajo familiar. El agente también está familiarizado con este flujo.

El problema surge aquí. Si los Datos son incompletos, la tarea no puede comenzar. El Validador dará error, indicando que faltan campos, que la longitud no es suficiente o que el formato es incorrecto. Para que el proceso de entrenamiento continúe, el agente rellenará estos Datos por sí mismo.

Desde la perspectiva del agente, no está «haciendo el mal». Solo está completando una tarea normal de aprendizaje automático: reparar datos, pasar la validación, hacer que el script de entrenamiento funcione. Pero desde la seguridad, el riesgo surge en ese momento: el Validador es más como un inspector de ingeniería que como un auditor de seguridad. Solo verifica si la tarea cumple con el formato, sin entender los límites de seguridad subyacentes.

Este problema también existe ampliamente en campos como medicina, biología, química, ciberseguridad, farmacología y seguridad mediática. La investigación recopiló más de 50 escenarios similares, usando diversas herramientas de investigación o ingeniería reales, como BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, API de Moderación de OpenAI, etc.

Estas herramientas en sí mismas no son maliciosas. Al contrario, son herramientas profesionales comunes en investigación o ingeniería. Pero el problema de TVD radica en que, cuando la tarea, la herramienta y el validador son normales, el agente aún puede, en el proceso de completar los datos, generar salidas inseguras.

Por lo tanto, el foco de ISC no está en técnicas de提示, sino en la capacidad del agente para completar automáticamente tareas «incompletas»: cuando las condiciones de finalización y los límites de riesgo se superponen, el modelo puede considerar que una salida insegura es una entrega normal.

La vulneración de Fable 5 demuestra que los detectores fuertes no pueden detener riesgos internos en la cadena de tareas

El caso de Fable 5 muestra que solo con detectores externos aún puede no cubrir ciertos escenarios de agentes a largo plazo. Esto no significa que los clasificadores de seguridad no tengan valor. Al contrario, son útiles contra solicitudes maliciosas externas y hacen que muchas técnicas tradicionales de越狱 fallen.

Pero esta vulneración demuestra que, que un detector externo sea efectivo contra los límites del prompt no significa que pueda cubrir los riesgos internos en la cadena de tareas del agente.

Si la brecha no está en el prompt del usuario, sino en los objetivos, herramientas, validadores y trayectorias de ejecución del agente, entonces los detectores de seguridad se vuelven muy vulnerables.

Desde Fable 5 hasta más de 60 otros modelos, incluyendo modelos en dispositivos móviles de Apple

Junto con la publicación de ISC-Bench, que cubre 9 áreas profesionales, la versión del artículo incluye más de 60 plantillas de activación, y tras su apertura, se expandió a 84 plantillas, probando casi todos los modelos y sistemas de agentes de los principales fabricantes.

En la lista de evaluación basada en ISC-Bench, hasta junio de 2026, más de 60 modelos de vanguardia muestran riesgos similares en la métrica ASR@3.

El proyecto en GitHub ya ha obtenido más de 800 estrellas, y se han recopilado múltiples casos de reproducción independiente (incluyendo la vulneración de modelos en dispositivos móviles de Apple), y continúa en actualización.

Se sabe que el equipo está realizando investigaciones de seguridad a gran escala en modelos de vanguardia, y ha obtenido datos internos sobre distribuciones inseguras en muchos modelos. Los resultados se publicarán próximamente.

Enlace original

Haz clic para conocer las posiciones abiertas en BlockBeats

¡Bienvenido a unirte a la comunidad oficial de BlockBeats:

Canal de suscripción en Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Cuenta oficial en Twitter: https://twitter.com/BlockBeatsAsia