Una nueva investigación apunta a una flaw en APIs de IA que, en ciertas condiciones, permitió que el razonamiento “oculto” entre llamadas se recuperara a partir de registros de sesiones. El hallazgo no se limita a una vulnerabilidad teórica: el estudio describe rutas de abuso capaces de extraer artefactos de privacidad, incluyendo datos sensibles como claves de API y contraseñas.
Lo que vuelve el caso especialmente relevante es el enfoque: el cifrado del contenido no fue “roto”. En su lugar, el problema se apoyó en cómo los proveedores aceptaban y procesaban bloques opacos de razonamiento entre sesiones, modelos y usuarios, convirtiendo logs publicadas en material reutilizable.
Qué se entiende por “razonamiento oculto” en APIs
Los sistemas de modelos de lenguaje usan mecanismos para mantener el contexto de conversación entre llamadas a una API. En varios proveedores, parte de ese estado de conversación puede incluir objetos de razonamiento que no se entregan como texto legible al cliente, sino como estructuras cifradas u opacas.
Según el informe, el objetivo del diseño es conservar el estado de razonamiento sin exponer directamente el texto subyacente. Sin embargo, si esos objetos se conservan de forma intacta en registros (por ejemplo, logs de agentes) y luego se reutilizan, podrían convertirse en un vector de exposición.
La falla: bloques opacos portables que se pueden reanclar
La investigación describe cómo un bloque creado en una sesión podía reproducirse en otra. El resultado fue que, durante las pruebas, el contenido no solo pudo recuperarse, sino también transferirse hacia un modelo más débil dentro de la misma “familia” del proveedor para forzar la revelación.
Importante: el estudio recalca que el ataque no requería obtener claves de cifrado. La extracción dependía de que los bloques opacos se consideraran válidos y fueran aceptados por la API, permitiendo que el razonamiento oculto se “reinyectara” en una ejecución posterior.
Cuatro rutas de abuso descritas por los investigadores
El equipo detrás del trabajo “Stealing Reasoning Traces from Proprietary LLM APIs” documentó cuatro caminos hacia el abuso del material de razonamiento en logs:
- Destilación de modelos: robar razonamiento propietario para entrenar o mejorar modelos derivados.
- Extracción entre usuarios: recuperar datos privados presentes en trazas publicadas por otras personas.
- Reconstrucción de contenido dañino: obtener información que el sistema ocultó tras una respuesta visible “segura”.
- Inyección disfrazada: esconder instrucciones maliciosas dentro de bloques opacos de razonamiento, evitando que aparezcan en texto visible.
Este conjunto de rutas ayuda a entender por qué el riesgo no se limita a un caso de “lectura accidental”: el diseño permite reanclar estados opacos y usarlos como canal para ataques más amplios.
Resultados a escala: cientos de miles de bloques y artefactos de privacidad
La evaluación se apoyó en 6.708 trayectorias públicas de agentes. A partir de ellas, el equipo decodificó 315.320 bloques de pensamiento. Tras excluir fuentes de referencia de evaluación, identificaron 704 artefactos de privacidad provenientes de sesiones reales.
Dentro de ese subconjunto, el informe reportó hallazgos concretos: 62 claves de API, 33 contraseñas, 24 tokens de acceso y siete claves privadas. Además, al menos 64 artefactos aparecieron únicamente en el razonamiento oculto y no en las trazas visibles publicadas.
Ese punto es crucial: incluso si un responsable “sanea” el texto legible, podría dejar sin querer secretos dentro del bloque opaco, que otro actor podría reanclar y decodificar.
El ataque entre usuarios no equivale a acceso arbitrario
El estudio enfatiza una limitación: el ataque no otorga acceso arbitrario a chats privados. Para que ocurriera, era necesario contar con:
- Un bloque de razonamiento cifrado u opaco que hubiese sido publicado en un log de agente (o que pudiera obtenerse de manera equivalente).
- Acceso a una API compatible al mismo proveedor y a un modelo que pudiera completar la cadena de ejecución.
En otras palabras, el problema aparece cuando el razonamiento opaco llega a manos de terceros y se reutiliza dentro del flujo correcto.
Qué cambió y qué recomiendan hacer los desarrolladores
Los investigadores notificaron sus hallazgos a los proveedores afectados que estaban directamente involucrados en el análisis, mencionándose también a Microsoft y Hugging Face. Según el reporte, las demostraciones dejaron de funcionar tras mitigaciones, y el estado del caso se sostiene en la declaración de reproducibilidad del propio equipo a partir de agosto de 2026.
Aun así, el estudio ofrece recomendaciones prácticas para equipos que manejan logs o compartición de trazas:
- Eliminar bloques de razonamiento y campos de razonamiento opaco cuando se compartan registros.
- No publicar transcripciones completas de la API, incluso si el texto visible se ha sanitizado.
- Revisar el proceso de generación y almacenamiento de logs para asegurar que no se conserven objetos que mantengan estado de razonamiento.
El objetivo no es solo “ocultar texto”: es evitar que los artefactos de privacidad viajen como piezas reutilizables.
Por qué la portabilidad entre sesiones agrava el riesgo
El informe señala que, durante las pruebas, esos objetos resultaron portables entre sesiones, usuarios y modelos dentro del contexto evaluado. En el experimento, un “decoder” más débil actuaba como decodificador “borroso” (según la terminología del artículo) para transcribir razonamientos generados por modelos más capaces.
Además, el trabajo describe que esa portabilidad permitía una prueba de concepto de prompt injection invisible: el bloque opaco podía contener instrucciones maliciosas que, al reanclarse en otra tarea, provocaban acciones orientadas por el atacante sin que la instrucción apareciera en el texto visible.
Evidencia pública y dudas abiertas
El documento público deja varias preguntas abiertas. Por un lado, no se reporta un reconocimiento público de la falla por parte de los tres proveedores mencionados. Por otro lado, el hecho de que los ataques ya no fueran reproducibles se apoya en la declaración de reproducibilidad del equipo, no en una confirmación oficial detallada ligada a la documentación vigente.
También existe una cuestión separada: aunque el equipo decodificó cientos de miles de bloques en repositorios públicos, el informe no prueba si esos bloques ya publicados permanecen decodificables con el estado actual de los sistemas. Son dos escenarios distintos: ataques “frescos” vs. reutilización de artefactos antiguos.
Antecedente: el comportamiento de replay ya se conocía
El trabajo se apoya en una investigación previa de Matthew Green, criptógrafo de Johns Hopkins, quien mostró que los bloques cifrados de razonamiento podían ser reproducidos entre sesiones y cuentas. Sin embargo, en esa etapa anterior se quedaba corto respecto a una técnica fiable para extracción de secretos.
De acuerdo con el relato del propio Green, se reportó el comportamiento de replay mediante programas de recompensas. Según su cuenta, OpenAI consideró el reporte irreproducible y Anthropic indicó que no veía implicaciones de seguridad. El artículo actual, en cambio, transforma ese replay en un método más amplio y documenta consecuencias de privacidad a mayor escala.
Conclusión: seguridad de logs y privacidad por diseño
La investigación muestra que una flaw en APIs de IA puede surgir no al romper cifrado, sino al permitir que objetos opacos de razonamiento sigan siendo reinyectables y procesables cuando se comparten en logs. El impacto potencial incluye la exposición de secretos y la posibilidad de reconstruir partes del razonamiento que no deberían salir del sistema.
Para equipos que usan APIs de modelos y publican trazas de agentes, la medida más efectiva es operativa: retirar bloques de razonamiento y evitar compartir transcripciones crudas que conserven estado cifrado. Con ello, se reduce el riesgo de que terceros conviertan registros “sanitizados” en material reutilizable para ataques.
Fuente: https://thehackernews.com/2026/08/openai-anthropic-google-api-flaw-let.html
