Técnica EchoGram Rompe la Seguridad de GPT, Claude y Gemini y Plantea una Pregunta Inquietante

Un fallo invisible en los grandes modelos de lenguaje que usas cada día podría dejar pasar órdenes peligrosas como si nada. La firma de ciberseguridad HiddenLayer ha puesto nombre a ese fallo: EchoGram, una técnica que ataca los “guardrails” de modelos como GPT-5.1, Claude o Gemini y los hace dudar justo donde deberían ser más firmes.

La clave está en unos elementos casi desconocidos para el usuario medio, los llamados “flip tokens”, que se añaden a una petición sin cambiar lo que tú pides en realidad. Consiguen torcer la forma en que el sistema entiende la entrada.

Los Modelos de Lenguaje de Gran Escala (LLMs) como GPT-5.1, Claude y Gemini son hoy la base de asistentes de IA, chatbots de soporte, filtros de contenido y herramientas que escriben código o analizan contratos. Estos sistemas llevan incorporados “guardrails”, es decir, mecanismos automáticos que bloquean instrucciones peligrosas, respuestas tóxicas o usos claramente maliciosos. Tú te apoyas en ellos sin verlo, cada vez que pides algo sensible a un asistente.

EchoGram entra justamente ahí. En vez de atacar la app que ves en pantalla, ataca cómo el modelo y sus filtros internos deciden si una entrada es segura o no. Según HiddenLayer, EchoGram explota detalles de la configuración interna del modelo y de sus filtros automatizados de seguridad, para conseguir que peticiones maliciosas parezcan inocentes o que mensajes normales parezcan una amenaza.

La trampa está en las listas o secuencias desequilibradas de tokens. Un “token” es cada pequeño trozo en que el modelo corta un texto: puede ser una palabra, parte de una palabra o un símbolo raro. Si en los datos de entrenamiento un token aparece muy poco, o casi siempre en un contexto positivo pero casi nunca en uno negativo (o al revés), queda “mal equilibrado” en la memoria estadística del sistema.

EchoGram se aprovecha de eso: forma secuencias con tokens poco representados o descompensados y los inserta en la petición del atacante. El contenido real de la instrucción no cambia, pero el modelo de seguridad mira esa combinación de tokens y “piensa” que está ante algo diferente. Ahí es donde los guardrails empiezan a fallar sin que nadie lo note.

El concepto de “flip token” viene justo de esa capacidad de dar la vuelta a la interpretación. Son palabras o símbolos que, colocados en cierto orden, cambian cómo el modelo evalúa lo que ve. No añaden información nueva a la frase, pero modifican el peso que el sistema da a cada parte de la entrada. Es como si añadieras ruido en un idioma que solo entiende el filtro automático, no la persona que escribe la consulta.

De esta forma, un atacante puede construir una consulta aparentemente normal, añadirle unos cuantos flip tokens, y conseguir que la capa de seguridad la apruebe. Las instrucciones peligrosas siguen ahí, sólo que enmascaradas por esa secuencia de tokens desequilibrados. Al otro lado, el modelo operativo puede llegar a ejecutar lo que pides como si fuera una tarea legítima.

El efecto contrario también es posible y da otro giro preocupante. El mismo mecanismo de EchoGram puede lograr que peticiones totalmente inocuas sean etiquetadas como dañinas. Basta con que la secuencia de tokens elegida influya en el filtro en sentido negativo. Así, una pregunta de trabajo o una consulta rutinaria puede acabar bloqueada sin motivo claro para el usuario.

HiddenLayer describe que el método técnico de EchoGram consiste, en esencia, en añadir flip tokens a la consulta sin modificar su contenido semántico. O sea, el “significado humano” del texto se mantiene, pero el significado que percibe el filtro automático cambia. “Lo peligroso no es lo que lees tú, sino lo que ‘cree ver’ el modelo de seguridad”, explican desde la compañía.

La simple adición de estos tokens es suficiente para disparar errores en los detectores de contenido peligroso que acompañan a los LLMs. Aquí no hablamos sólo del modelo principal, sino de los pequeños modelos adicionales que revisan si un texto es violento, fraudulento o sensible. Si EchoGram los confunde, la cadena completa se debilita, desde la primera revisión hasta la respuesta final.

Toda esta debilidad está muy ligada a cómo se han entrenado los filtros. La probabilidad de éxito de EchoGram depende, en gran medida, de la calidad y el equilibrio de los datos de entrenamiento que alimentan los modelos de seguridad. Si hay demasiados ejemplos positivos de cierto token y muy pocos negativos, o directamente casi ningún ejemplo, esa pieza se vuelve una palanca perfecta para el atacante.

Incluso con buenos datos, el equilibrio es delicado. Los equipos de seguridad de IA necesitan revisar constantemente las muestras usadas para entrenar tanto los filtros como los propios LLMs. Sin esa revisión continua, nuevos tokens, expresiones de moda o símbolos extraños pueden quedar mal representados y convertirse en flip tokens potenciales, sin que nadie se dé cuenta hasta que alguien explota el hueco.

Cómo EchoGram puede afectar a aplicaciones empresariales que dependen de LLMs

Si piensas en EchoGram solo como un truco académico, el impacto real se te puede escapar. Imagina, por ejemplo, un sistema de atención al cliente que deja a un asistente de IA decidir si una petición debe escalarse a un humano, o un panel de administración donde un LLM ayuda a ejecutar tareas internas con menos pasos. En estos escenarios, una solicitud maliciosa aprobada por error puede transformarse en acciones no autorizadas.

Hablamos de cambios de configuración, acceso a datos que no tocan o envíos de información fuera de la empresa. Todo depende de lo integrada que esté la IA en el flujo de trabajo. Si el modelo es una capa de defensa, EchoGram puede hacer que deje pasar justo lo que debía parar. Si es una capa de automatización, la técnica puede empujarle a ejecutar pasos que tú nunca habrías aprobado.

El lado opuesto tampoco es menor. Si EchoGram fuerza falsos positivos, peticiones normales empezarán a bloquearse con frecuencia. En una plataforma crítica, eso significa tareas retrasadas, operaciones repetidas y personal frustrado que no entiende por qué el sistema ve peligro donde no lo hay. Con el tiempo, se genera “fatiga de alerta”: cuando recibes cientos de avisos injustificados, dejas de prestar atención incluso a los importantes.

Esa fatiga impacta en la operatividad de hospitales, bancos, proveedores de energía o grandes ecommerces que usan IA como parte central de sus procesos. No es solo un problema técnico, también toca la reputación de la organización. Si tus clientes ven errores constantes o respuestas incoherentes porque un ataque tipo EchoGram ha manipulado las salidas del modelo, la imagen de fiabilidad de tu servicio se resiente.

Cómo mejorar la seguridad de LLMs frente a EchoGram y ataques similares

Hay otro ángulo menos visible pero igual de serio: la manipulación de respuestas y decisiones. En sistemas donde el modelo hace recomendaciones que luego se siguen casi de forma automática, unas pocas respuestas alteradas pueden inclinar decisiones clave. Por ejemplo, priorizar un tipo de transacción, etiquetar mal un contenido sensible o marcar como sospechoso un usuario legítimo, todo en base a salidas ya manipuladas.

Cuando esas salidas se encadenan con otros sistemas, los errores se multiplican. Integraciones empresariales que usan LLMs como filtro previo de riesgo, o como capa de clasificación de contenido, pueden quedar comprometidas si EchoGram consigue que pasen textos que nunca deberían avanzar o que se bloquee información esencial. Cada decisión errónea añade fricción en procesos que estaban pensados para ir más rápido gracias a la IA.

Los datos que sustentan este análisis proceden del informe técnico publicado por HiddenLayer en 2024, donde se detalla el comportamiento de EchoGram sobre distintos modelos y filtros. Los investigadores aplicaron secuencias de flip tokens a varios LLMs comerciales y midieron cómo cambiaban las tasas de bloqueo y aprobación. El patrón fue claro: cuando el equilibrio de los datos de entrenamiento flojeaba, la tasa de fallo de los guardrails subía de forma notable.

Nada de esto significa que estés indefenso. Lo que revela EchoGram es que los guardrails actuales, tal y como se han diseñado en muchos sistemas, siguen siendo vulnerables frente a técnicas de ataque más sofisticadas. Para ganar resiliencia, los equipos que despliegan IA tienen que combinar varias capas: mejora continua de modelos y filtros, supervisión humana activa y detección proactiva de anomalías en las entradas y en las respuestas.

Esa detección proactiva puede incluir modelos separados que vigilen patrones raros de tokens, sistemas que marquen cambios bruscos en el tipo de peticiones recibidas o revisiones humanas focalizadas en zonas de riesgo. También ayuda mantener ciclos de retraining más cortos, donde nuevos datos de uso real y de intentos de ataque se integren en los filtros de seguridad con rapidez, evitando que un flip token funcional siga siéndolo durante meses.

Para ti, como usuario o como responsable de un servicio que ya usa LLMs, la lección de EchoGram es clara: la IA no es una caja negra mágica, y sus defensas tampoco. Si ves que un proveedor presume de guardrails perfectos, conviene preguntar cómo revisa sus datos de entrenamiento, qué controles humanos mantiene y qué sistemas tiene para detectar patrones anómalos. Si en los próximos meses empiezan a aparecer actualizaciones específicas sobre “mejoras de seguridad en filtros de contenido”, será una señal de que el sector está reaccionando a este tipo de ataques.

EchoGram nos recuerda que, en los LLMs más populares, la seguridad no sólo depende del modelo principal, sino de los datos, los filtros y las personas que los vigilan. Si se refuerza ese trípode con revisión constante, equilibrio de ejemplos positivos y negativos, y monitoreo inteligente, podrás seguir aprovechando la IA en tus aplicaciones sin que unos pocos flip tokens decidan por ti cuándo algo es seguro y cuándo no.