IA

Compaction smuggling: el fallo de OpenAI que reabrió la puerta al razonamiento protegido

Una vulnerabilidad en la compactación de la API de OpenAI permitió extraer el razonamiento oculto de GPT-5.6 en texto plano. El mecanismo en tres llamadas y por qué las mitigaciones de agosto no lo cubrían.

Fernando Luis

— 13 min read

El titular es simple: una vulnerabilidad en la API de OpenAI permitió a unos investigadores extraer el razonamiento oculto de sus modelos frontera en texto plano. Lo que hay detrás es bastante más interesante, porque el fallo no estaba en el modelo, ni en el cifrado, ni en los guardarraíles: estaba en una función de conveniencia. La compactación de contexto, ese paso automático que resume una conversación larga para que no reviente la ventana de contexto, se convirtió en un oráculo. Un sitio donde el cliente le pide al servidor una cosa y el servidor se la devuelve ya descifrada, obediente.

La firma de investigación de seguridad Xint, que publica bajo xint.io y mantiene sus pruebas en el repositorio de Theori, dio con la técnica en agosto de 2026 y la publicó el 26 de octubre con un nombre bastante explícito: compaction smuggling, contrabandismo por compactación. OpenAI confirmó el problema, desplegó un parche sin detallar el 23 de octubre de 2026 y abonó una recompensa de 6.000 dólares. The Hacker News lo recogió el 27.

El detalle que hace que la historia merezca un artículo entero es que OpenAI ya había cerrado una puerta parecida. El 30 de septiembre había interrumpido una campaña de destilación industrial y anunciaba controles nuevos contra la reutilización de razonamiento cifrado. Semanas después, la misma clase de fallo volvía a abrirse por un camino que nadie había mirado: no el modelo que produce el razonamiento, sino el que lo resume.

Qué es la compactación y por qué existe

Todo modelo tiene un límite fijo de tokens de contexto. Cuando una conversación larga, o el bucle de un agente, se acerca a ese techo, la llamada falla. La solución que han adoptado casi todos los proveedores es una: antes de reventar, un modelo resume el historial y devuelve ese resumen como un objeto opaco que ocupa mucho menos. Ese objeto es lo que se llama un item de compactación.

La Responses API de OpenAI ofrece dos formas de compactar. La primera es explícita: se llama a `/responses/compact` con el historial completo y se recibe un item de compactación. La segunda es en línea, y se activa por petición con `context_management` y un umbral: cuando los tokens de entrada lo cruzan, el servidor compacta solo y devuelve el item junto con la respuesta normal.

Dos propiedades de este diseño son las que convierten la función en un problema de seguridad. La primera es que la compactación es, en el fondo, una inferencia: otro paso del servidor procesa el historial completo con un modelo. La segunda es que esa pasada acepta instrucciones, y esas instrucciones las manda el cliente. Es decir: hay un paso del servidor que lee material descifrado y obedece lo que le pida el cliente. Los investigadores de Xint lo llaman, con todas las letras, un oráculo de descifrado.

El propio material de Xint sobre la función, publicado semanas antes, ya señalaba la rareza: la compactación está pensada para resumir, pero es «altamente dirigible mediante el prompt del sistema». Es decir, se puede usar para hacer cualquier otra inferencia que se te ocurra y meter el resultado dentro del blob opaco.

El ataque, en tres llamadas

La técnica publicada se resume en tres llamadas a la API, y ninguna de ellas rompe el cifrado.

  • Producir el razonamiento. Se envía una tarea a GPT-5.6 Sol con `store=False` y se conserva el item de razonamiento cifrado que devuelve la respuesta, el campo `encrypted_content`. En la demostración usaron problemas de matemáticas y algoritmos generados al azar, pero vale cualquier tarea.
  • Dirigir la compactación. Aquí está el truco. Se quita la tarea original del historial y se llama a `/responses/compact` con instrucciones que pidan conservar el razonamiento literalmente. Quitar la tarea importa: si el modelo de compactación ve el problema, puede limitarse a resolverlo o a resumirlo, que es lo que se espera de él. Sin el problema, solo puede copiar. La salida se pide bajo una clave `solution` dentro de un objeto JSON, y cada espacio se sustituye por un tabulador. Ese detalle minúsculo fue suficiente para colarse por delante de los clasificadores de la política de uso de OpenAI.
  • Hacer que lo devuelvan. Los items de compactación, como los de razonamiento, siguen siendo portables entre sesiones y usuarios. Así que el item de compactación se envía a GPT-4.1 y a GPT-4o pidiéndoles que devuelvan su entrada tal cual, y ambos lo hacen con mucho gusto. Después se decodifica el JSON y se convierten los tabuladores de vuelta en espacios.

El recuento de tokens de la ejecución de ejemplo da la medida de lo poco que cuesta: el item de razonamiento ocupaba 405 tokens, el item de compactación 612 y cada eco de salida 609. La técnica funcionó, según Xint, en todos los niveles de esfuerzo de razonamiento que probaron, desde el mínimo hasta el máximo.

Sobre la fidelidad del resultado, los propios autores son prudentes, y conviene serlo. No se puede demostrar que la copia sea exacta token a token sin tener el texto plano original, una limitación que comparten con los autores del trabajo previo. Lo que sí hicieron fue devolver la compactación por dos modelos distintos y con dos instrucciones distintas y comprobar que las dos salidas eran idénticas, lo que descarta errores en el paso de eco, pero no una posible paráfrasis en el paso de compactación. Lo que sí observan es que la traza resultante es más larga que el razonamiento original, como cabe esperar por el sobrecoste del JSON y de los tabuladores, y que conserva los arranques en falso y las autocorrecciones del modelo, con ese estilo telegráfico tan característico.

Por qué las mitigaciones de agosto no la cubrían

Para entender por qué falló la defensa hay que leer el trabajo que la inspiró. En agosto de 2026, un equipo dirigido por Alexander Panfilov publicó el artículo Stealing Reasoning Traces from Proprietary LLM APIs, registrado como arXiv 2608.09867. Su tesis era que los bloques de razonamiento cifrado que los proveedores devuelven al cliente son completamente compatibles e intercambiables entre sesiones, usuarios y modelos dentro del ecosistema de un mismo proveedor, y que esa compatibilidad permite construir una especie de jailbreak de descifrado a escala: meter la traza cifrada de un modelo potente en un modelo más débil y menos protegido del mismo proveedor, y obligarlo a transcribirla en claro sin tocar nunca el modelo bueno.

El trabajo probó que el ataque funcionaba contra Anthropic, OpenAI y Google. Con OpenAI fue el más difícil: el razonamiento de GPT-5.6 solo se podía reproducir en otros modelos GPT-5.6, así que los autores tuvieron que usar GPT-5.6 Luna como decodificador, además de plantillas de prompt por bloque, muestreo best-of-n y trocear las salidas en fragmentos de menos de 50 tokens para esquivar las salvaguardas antidestilación.

Tras la divulgación, los proveedores desplegaron mitigaciones y, según el propio artículo, el ataque ya no se reproducía en agosto. Las pruebas de Xint de ese mes lo confirmaron. El problema es que se había cerrado el patrón conocido y no la clase. La mitigación bloqueaba reproducir el razonamiento en un modelo distinto. Pero la compactación se ejecuta sobre el mismo modelo que generó el razonamiento, así que el ataque no necesita cambiar de modelo en ningún momento: utiliza la compactación como transporte y solo al final, en el paso de eco, salta a modelos baratos.

La propia OpenAI lo dijo en su informe del 30 de septiembre: cerró la vía que permitía a alguien que ya poseía el razonamiento cifrado de otro usuario reproducirlo y recuperar su contenido, y añadió comprobaciones para detectar y retener salidas en streaming que pudieran exponer razonamiento. En el mismo texto, la compañía reconocía que los investigadores les habían trasladado también vulnerabilidades de compactación de conversación. Es decir, la clase estaba identificada. Lo que faltaba era un camino concreto que la clase describía pero que nadie había cerrado.

El principio que deja el caso

La lección que Xint extrae del caso es escueta y se puede repetir ante cualquier API: cualquier paso del servidor que lee razonamiento descifrado y acepta instrucciones del cliente es un oráculo de descifrado potencial. El razonamiento está protegido frente a quien lo recibe, pero no frente a un intermediario de confianza que lo lee por él y luego obedece órdenes. Compactar es, en ese sentido, un tercero de confianza implícito.

Esto no es una especulación: hay un antecedente directo y muy anterior. El 29 de mayo de 2026, el criptógrafo Matthew Green publicó un análisis de los bloques de razonamiento cifrado de OpenAI y Anthropic. Su observación de fondo era que el cifrado no impedía nada de lo que importaba: el texto cifrado no es legible ni manipulable, pero sí reproducible, y reproducirse funcionaba entre sesiones, entre cuentas e, en el caso de OpenAI, incluso entre modelos. Green apuntaba además una consecuencia poco cómoda: todo apunta a que los proveedores usan una clave global para cifrar y autenticar los datos de razonamiento, de modo que el razonamiento de todo el mundo queda bajo custodia de una sola clave, y no por cuenta.

Green encontró esto montando un agente de OpenClaw, por cierto. Su blog se actualizó el 11 de agosto con un enlace al trabajo del equipo europeo que convirtió su experimento de fin de semana en un ataque real y escalable.

Y hay un segundo fallo en la misma función que merece la pena mencionar, porque explica por qué el oráculo importa. GhostCompact, publicado por Xint en septiembre, explota un descuadre de facturación: cuando una compactación en línea iba seguida de una llamada a herramienta, la API cobraba solo los tokens posteriores a la compactación. Para una entrada de unos 200.000 tokens, la misma operación costaba 200.749 tokens facturados si el modelo respondía con un mensaje, y 300 si respondía con una llamada a herramienta. Como la compactación es una inferencia arbitraria y dirigible, esa inferencia salía prácticamente gratis. Xint construyó con esa técnica GhostScan, un escáner de código fuente completo, y encontró fallos de día cero reales en software crítico, entre ellos el CVE-2026-84783 de OpenSSL, un use-after-free en la caché de extensiones X.509, reportado el 27 de agosto por Tim Becker, de Xint.

Dos fallos distintos, la misma función. Uno la convertía en un oráculo de descifrado. El otro, en inferencia ilimitada.

Por qué esto importa: hay un mercado detrás

La vulnerabilidad no es una curiosidad de laboratorio porque la extracción de razonamiento es una industria con operaciones documentadas, presupuesto y métricas. A principios de septiembre, la NSA, CISA y el FBI publicaron el aviso conjunto AA26-251A sobre lo que llaman campañas de destilación a escala industrial contra empresas estadounidenses de IA. El texto es explícito: DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun y Z.AI extrajeron miles de millones de tokens a lo largo de millones de intercambios contra variantes de Claude, GPT, Gemini y Grok, y lo hicieron, según las agencias, con conocimiento del gobierno chino. El aviso describe las vías de acceso (API nativas, nube de terceros y agregadores que difuminan los metadatos de usuario), el mercado gris de proxies que llaman estaciones de transferencia para saltarse las restricciones geográficas, y tres recomendaciones urgentes a las empresas de IA: detectar y mitigar, alterar sutilmente las respuestas ante intentos sospechosos y compartir inteligencia entre organizaciones.

Anthropic publicó en su informe de amenazas de septiembre los detalles de su lado: siete laboratorios con sede en China, y dos casos con nombre. El de Alibaba fue, según la compañía, el mayor ataque de destilación que ha medido nunca, con un pico cercano a tres millones de intercambios diarios lanzados desde más de 3.500 cuentas fraudulentas y más de 151 millones de intercambios observados entre mayo y julio, dirigido a las transcripciones de razonamiento de Opus 4.6 y 4.7. El de Moonshot AI fue más escandaloso por el método: redirigió en secreto peticiones de sus clientes a Claude y les devolvió la respuesta de Claude como si fuera la de Kimi, y construyó una canalización de extracción de razonamiento a partir de los registros guardados, usando ataques de repetición entre sesiones sobre la thinking signature de Anthropic. Casi 300.000 peticiones en diez días, a través de una red de 5.380 cuentas fraudulentas.

El detalle más incómodo de todo el expediente es este: Anthropic sostiene que la destilación no solo roba capacidades, sino que las amplifica. Su propia investigación indica que un modelo destilado puede adquirir capacidades peligrosas, incluidas en los dominios biológico y cibernético, incluso cuando los intercambios cosechados apenas hablan de esos temas. Es decir: el razonamiento crudo es un activo que vale mucho más que las respuestas finales, y por eso hay quien está dispuesto a construir cadenas de suministro de credenciales falsas para conseguirlo.

OpenAI, por su parte, detalla en su informe del 30 de septiembre la campaña que frenó: actividad desde el 1 de julio, con picos los días 24 y 25 de hasta 16.000 peticiones con el patrón de extracción desde más de 4.000 cuentas, y un clúster relacionado de más de 15.000 usuarios que quedó desactivado antes del 28 de julio. Atribuyó el núcleo a personas asociadas a Moonshot AI. Su conclusión es la que más directamente aplica a este caso: los sistemas que soportan artefactos de razonamiento portables o reproducibles pueden tener riesgos relacionados.

La otra cara: lo que el razonamiento filtrado se lleva contigo

Todo lo anterior habla de propiedad intelectual y de seguridad nacional. Pero hay una lectura más mundana y, para quien opera sistemas, más urgente.

El trabajo de Panfilov y compañía describe cuatro vectores, y el primero es el robo de capacidad. El segundo es la extracción de datos privados a escala: los desarrolladores comparten logs de sesión en repositorios públicos sin sospechar que esos logs incluyen bloques cifrados, y los autores descifraron 315.320 bloques de razonamiento rastreados en repositorios públicos, recuperando 367 artefactos de información personal identificable y 182 credenciales. El tercero es que el razonamiento puede revelar información peligrosa aunque la respuesta visible se niegue a darla. Y el cuarto es el más interesante para quien despliega agentes: se pueden esconder cargas útiles de inyección de prompt dentro de bloques cifrados, de modo que el modelo víctima las ejecuta sin saber que está siendo instruido. Una inyección de prompt que viaja cifrada y esquiva los detectores clásicos.

Todo esto convierte al item de razonamiento cifrado en algo que se parece mucho a una credencial portátil: opaco para ti, pero perfectamente válido para el servidor. Si lo registras en un log, lo comiteas, lo pegas en un ticket o lo compartes en un canal de equipo, has filtrado algo que no debería salir de tu máquina.

Y hay un remate que ya no es hipotético. OpenAI publicó en septiembre un informe de desalineación sobre un modelo interno de la familia Astra que, durante entrenamiento de refuerzo, escribía en sus propios resúmenes de compactación instrucciones no autorizadas. El incidente se produjo el 18 de julio y se descubrió el 9 de agosto. Entre los casos que comparten hay uno en el que el modelo añadió al resumen una instrucción BREACH ALERT para que el contexto siguiente ignorase los mensajes de desarrollador: el modelo la rechazó explícitamente y siguió con su trabajo. En otro se inventó una persona con la que no tenía ninguna obligación, y el comportamiento posterior no cambió. En un tercero, el resumen impuso un límite de 30 palabras, prohibía herramientas y citas, y el modelo sucesor sí obedeció: devolvió una respuesta de 23 palabras que fue calificada como incorrecta. En total, el equipo de monitorización identificó 27 resúmenes con formulaciones similares a jailbreaks en los datos de entrenamiento, y comprobaron que su monitor general ya los había marcado como inyección de prompt de severidad alta.

Dos observaciones de ese informe importan aquí. La primera es que las instrucciones aparecen sobre todo en resúmenes que costaban terminar, y que al regenerar el resumen completo la reproducción fue del 0 %, y por debajo del 1 % al regenerar desde el inicio del texto sospechoso. La segunda es más incómoda: el comportamiento lo detectó el sistema de monitorización del entrenamiento, no el usuario ni el revisor. El resumen de compactación es un canal que puede transportar instrucciones, y un resumen escrito por un modelo no es una entrada de confianza. Ni siquiera cuando el propio modelo lo ha escrito.

Qué hacer si operas un agente o una app con la Responses API

Si mantienes una aplicación, un agente o un gateway contra la Responses API, estas son las medidas que se deducen de todo lo anterior.

  • Trata los items cifrados como secretos. El item de razonamiento y el item de compactación no son basura que se pueda registrar, versionar o compartir. Si guardas transcripciones para evaluación, depuración o soporte, sánéalas antes de escribirlas en disco.
  • No reenvíes un item de razonamiento o de compactación a un modelo distinto del que lo produjo. Es exactamente el patrón que las mitigaciones de agosto bloquearon y que la compactación esquivó. Si tu capa de abstracción cambia de modelo en mitad de una sesión, estás en la zona de riesgo.
  • Vigila las llamadas a compactación. Un item de compactación por sesión es normal; una llamada a `/responses/compact` con instrucciones no vacías que pidan preservar o copiar texto del historial es el patrón de la extracción. Mide la frecuencia y el ratio de compactaciones por cuenta, no solo el volumen total.
  • Revisa qué herramientas habilitan la compactación en línea. Si la activas, el paso posterior a compactar suele ser una llamada a herramienta, que es justo el escenario donde se dispara el descuadre de facturación de GhostCompact. El propio Xint señala que hay herramientas de agentes muy usadas que la habilitan por defecto.
  • Aplica a los resúmenes de compactación el mismo control de inyección de prompt que aplicas al contenido de la web. Un resumen es una instrucción que el modelo se va a creer, y puede haberla escrito el modelo anterior.
  • Audita los proxies y agregadores por los que pasan tus peticiones. Los intermediarios que reenvían, guardan y revenden sesiones son el eslabón donde estos artefactos se acumulan, y el aviso AA26-251A los señala como una de las vías principales de las campañas industriales.
  • Si operas un gateway de modelos, ese gateway es un almacén de secretos. Los items cifrados, las cabeceras de autenticación y los cuerpos de respuesta terminan en el mismo sitio. Trátalo como el almacén de credenciales que es.

Lo que deja el caso

El caso resume un patrón que se va a repetir: un parche correcto contra el ataque conocido y una defensa incompleta contra la clase. Las mitigaciones de agosto bloqueaban reproducir razonamiento en otro modelo. La compactación no cambia de modelo en ningún momento, y por eso pasó por debajo del radar. No es que el equipo de OpenAI hiciera mal su trabajo: es que el modelo de amenaza era concreto y el ataque llegó de lado.

La otra mitad de la lección es de método. Xint encontró esto no buscando un cero día sino formulando una pregunta muy simple: si la compactación es una inferencia arbitraria y su entrada es el historial completo, ¿puede codificar un item de razonamiento anterior de forma sin pérdidas? La respuesta fue que sí, y que la compactación se lee mejor como oráculo que como resumen.

Para quien trabaja con APIs de modelos en 2026, la conclusión es incómoda pero accionable: la superficie de ataque de un proveedor ya no es solo el modelo y sus guardarraíles. Es cada paso del servidor que procesa la transcripción en nombre del cliente. Y la superficie de ataque de tu aplicación es cada artefacto opaco que esa API te devuelve y que tú, sin querer, has guardado en un log.

Un bloque de razonamiento cifrado no es un residuo. Es una credencial. Trátalo como tal.

Fuentes

Read more