Investigadores del ELLIS Institute Tübingen y el Max Planck Institute for Intelligent Systems publicaron el 10 de agosto un trabajo que afecta por igual a Anthropic, OpenAI y Google: los tres protegían los tokens de razonamiento que viajan entre llamadas de API con una única clave de cifrado global. Aprovechándolo, el equipo recuperó razonamientos internos en texto plano y, con ellos, 182 credenciales reales de sesiones de usuarios. El ataque principal ya no es reproducible y no consta que nadie lo explotara con fines maliciosos.
Es una noticia técnica que casi nadie ha cubierto y que, sin embargo, apunta directamente a una costumbre muy extendida entre quienes trabajamos con agentes y automatizaciones avanzadas.
Una sola clave para todo el razonamiento cifrado
Cuando un modelo de Inteligencia Artificial razona antes de responder, ese proceso no siempre se descarta: en flujos complejos de varias llamadas, el proveedor lo devuelve cifrado para poder reinyectarlo en el siguiente paso y mantener el contexto. El contenido queda oculto para el cliente, que solo maneja el «sobre cifrado».
El hallazgo crítico es que ese sobre estaba protegido, en los tres grandes proveedores, con una clave global compartida entre sesiones, usuarios y modelos dentro de cada plataforma. No se trataba de una clave única por sesión ni por cliente: era una sola llave para toda la infraestructura. Y cuando una misma llave abre todas las puertas, basta con encontrar una cerradura mal vigilada.
La cerradura mal vigilada resultó ser el modelo de menores prestaciones del proveedor. Los investigadores tomaron los sobres cifrados devueltos por la API y los reenviaron a modelos más débiles del mismo proveedor, que los descifraban sin problema y devolvían el razonamiento en texto plano. No hizo falta romper el algoritmo de cifrado: bastó con pedírselo al componente que compartía la clave y contaba con menos filtros de seguridad.
Las credenciales no estaban en la API: estaban en GitHub
Aquí es donde la investigación deja de ser un problema exclusivo de los proveedores de IA y pasa a ser una responsabilidad directa de los desarrolladores. Para demostrar el alcance real, el equipo no atacó a ningún usuario en producción: recolectó 6.708 trayectorias de agentes publicadas abiertamente en GitHub y Hugging Face, decodificó 315.320 bloques de razonamiento y encontró dentro 182 credenciales pertenecientes a sesiones reales.
Esos logs los subieron profesionales del sector: trazas de ejecución de agentes compartidas para documentar un proyecto, reportar un bug, acompañar un tutorial o publicar un ejemplo de integración. Muchos los compartieron con la tranquilidad de asumir que el bloque de razonamiento iba cifrado y, por tanto, no revelaba información sensible.
Publicaste un archivo ilegible. Resultó que era perfectamente legible para cualquiera que supiera a quién preguntarle.
Y el proceso de razonamiento de un agente es, por naturaleza, el lugar donde acaban los datos confidenciales: la clave de API que el agente leyó de una variable de entorno para validar permisos, la contraseña expuesta en un archivo de configuración que estaba inspeccionando en un servidor WordPress o el token de sesión que se pasó entre nodos de n8n. Nada de eso aparecía en la respuesta final devuelta al usuario, razón por la cual nadie auditaba esos bloques antes de subirlos a un repositorio.
🔒 Revisa esto si has compartido trazas de agentes:
Busca en tus repositorios públicos, Gists de GitHub e issues cualquier log de ejecución de agentes que hayas subido recientemente. Si contienen bloques de razonamiento cifrado, asume que su contenido fue accesible y rota inmediatamente las credenciales que estuvieran cargadas en las variables de entorno de esas sesiones. La vulnerabilidad de la API ha sido solucionada, pero los datos que ya fueron indexados permanecen expuestos.
Qué está resuelto y qué sigue en tus manos
Es importante contextualizar el alcance técnico para mantener una gestión de riesgos adecuada. La declaración de reproducibilidad del estudio confirma que el vector de ataque principal está mitologicamente cerrado a fecha de agosto de 2026, y el informe no muestra indicios de explotación maliciosa previa en entornos reales. El incidente en la capa del proveedor está resuelto.
Lo que no se corrige con un parche de infraestructura es la cultura de gestión de logs. Existen tres buenas prácticas fundamentales que deben aplicarse desde hoy:
- Aplica el principio de mínimo privilegio en el contexto del agente: Si un proceso automatizado está analizando una instalación de WordPress o un flujo de trabajo, no debe tener acceso a credenciales de base de datos o claves maestras que no sean estrictamente necesarias para la tarea asignada.
La lección principal para agencias y desarrolladores es clara: la arquitectura de una integración con agentes de IA tiene más capas intermedias de las que habitualmente se auditan. Entre la instrucción inicial y la respuesta devuelta existen artefactos de ejecución —razonamientos cifrados, metadatos, llamadas a herramientas— que existen y se almacenan. Asegurar que esos artefactos no terminen en un repositorio público depende exclusivamente del control de tus propios flujos de trabajo.
