Ocho investigadores han publicado en arXiv un paper que enseña a sacar el razonamiento oculto de los modelos de OpenAI, Anthropic y Google sin tocar la clave de cifrado. La técnica no rompe nada: coge el bloque cifrado que el proveedor te devuelve por su API y se lo mete a un modelo hermano más pequeño del mismo proveedor, que a veces lo lee en voz alta. Sobre 315.320 bloques públicos recuperaron 367 datos personales y 182 credenciales, incluidas claves de API y contraseñas.
Puntos clave
- El paper se titula "Stealing Reasoning Traces from Proprietary LLM APIs" y lo firman Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping y Maksym Andriushchenko.
- El fallo es de arquitectura: los bloques cifrados son intercambiables entre sesiones, usuarios y modelos del mismo proveedor.
- 315.320 bloques de razonamiento recogidos de repositorios públicos dieron 367 piezas de información personal y 182 credenciales.
- Los tres laboratorios fueron avisados antes de publicar y ya han cambiado sus sistemas.
Qué se estaba protegiendo y por qué se rompió
Los modelos de razonamiento piensan antes de contestar. Esa cadena intermedia es propiedad intelectual pura: enseña cómo el modelo llega a la respuesta, y con ella un competidor puede entrenar un modelo pequeño para que imite al grande. Por eso los laboratorios dejaron de mandarla en claro.
La solución que eligieron los tres fue la misma. En lugar de guardar el razonamiento en su servidor, lo cifran y te lo mandan a ti dentro de la respuesta de la API. Tu aplicación lo guarda, no lo puede leer, y se lo devuelve al modelo en la siguiente llamada para que retome donde lo dejó. Es elegante y barato: el estado vive en el cliente, no en la infraestructura del laboratorio.
Ahí está el problema. Ese sobre cerrado ahora viaja. Pasa por tu servidor, por tus logs, por tu repositorio si se te cuela en un fichero de test. Y resulta que el sobre no está atado ni a tu sesión ni al modelo que lo generó.
Cómo funciona el ataque
Los investigadores cogieron un bloque cifrado generado por un modelo grande y se lo pasaron a un modelo más pequeño de la misma familia, del tipo Haiku frente a Opus. El modelo pequeño acepta el bloque porque el formato es compatible. Con un prompt de jailbreak encima, a veces lo convierte de vuelta en texto legible.
Nadie ha robado la clave. El descifrado lo hace el propio proveedor, con su propio modelo, porque nunca comprobó quién le estaba dando el sobre ni de dónde venía.
La parte que debería preocupar a cualquiera que monte cosas encima de estas APIs es la segunda mitad del hallazgo. Los 315.320 bloques no los sacaron hackeando a nadie: estaban en repositorios públicos, gente que había subido trazas de sus propias aplicaciones sin saber que dentro había algo recuperable. De ahí salieron 367 datos personales y 182 credenciales.
Qué implica para quien construye encima
Si tu aplicación llama a Claude, ChatGPT o Gemini con razonamiento activado, estás manejando un objeto que hasta esta semana tratabas como ruido opaco. Un blob que guardas, que registras en el log y que probablemente acaba en algún sitio con menos control que tu base de datos.
Ese blob puede contener información que el modelo vio y decidió no enseñar en la respuesta final. Un dato de un documento que le pasaste, una credencial que apareció en un fichero de configuración, el contenido de un correo. Lo que el usuario nunca leyó, porque el modelo lo descartó por el camino, sigue ahí dentro.
Hay un segundo hallazgo más incómodo para los laboratorios. Los investigadores encontraron indicios compatibles con destilación: trazas de Kimi K3 parecidas a las ocultas de modelos frontera. Parecido no es prueba, y ellos lo dicen. Pero abre la puerta a que las trazas cifradas hayan servido de material de entrenamiento para modelos rivales.
Eso convierte el paper en algo más que un aviso de seguridad. Si las trazas se pueden recuperar y sirven para entrenar, la protección que los laboratorios montaron para blindar su ventaja competitiva estaba funcionando en la dirección contraria: repartía el activo en sobres que cualquiera podía guardar.
Qué hicieron los laboratorios
Los tres proveedores recibieron el aviso antes de la publicación y modificaron sus sistemas. El paper no detalla las contramedidas concretas, y ninguno de los tres ha publicado una nota técnica al respecto.
La corrección evidente es atar el bloque cifrado a su origen: a la sesión que lo generó, al usuario y al modelo concreto. Si un bloque solo lo puede reabrir el modelo que lo escribió, dentro de la misma conversación, el ataque desaparece. Es una comprobación barata y llama la atención que no estuviera desde el principio.
Queda la duda de si el parche cubre las trazas antiguas. Los 315.320 bloques que los investigadores recogieron de repositorios públicos siguen ahí, en repositorios públicos. Un cambio en el servidor impide reabrirlos hoy, pero no borra lo que ya se publicó ni lo que otros hayan recogido antes del aviso.
Por qué importa
Los tres laboratorios ya han parcheado, así que el susto operativo es limitado. Lo que queda es una lección de diseño que aplica a cualquier empresa que esté metiendo agentes en producción.
El secreto creó una superficie de ataque nueva. Al mover el estado del razonamiento al cliente para ahorrarse infraestructura, los proveedores convirtieron un dato interno en un dato que circula. Y todo lo que circula acaba en un log, en un backup y en un repositorio.
Si tenéis agentes en producción, la revisión concreta es esta: mirad dónde acaban los campos opacos que devuelven las APIs de IA. Los que nadie lee porque no se pueden leer. Tratadlos como si fueran datos personales, porque a veces lo son. Y si alguna vez habéis subido trazas a un repositorio público para depurar, ese repositorio merece una pasada.
Relacionado
