Un canal encubierto entre dos cuentas
Esquema del caso: el canal no es la red, es el almacenamiento que las dos sesiones comparten.
Durante años, un asistente de IA fue una caja de texto: preguntabas, respondía y no tocaba nada. Eso se ha acabado. El asistente de hoy ejecuta código, lee el correo, mueve ficheros y trabaja sobre repositorios y cada una de esas capacidades es un permiso que su dueño concedió con un clic. Cuando el asistente pasa de responder a actuar, hereda todos los permisos de la persona que lo usa y, con ellos, todos sus fallos de diseño.
Esta semana Check Point ha documentado un caso que ilustra exactamente eso. Dos cuentas de ChatGPT podían hablarse entre sí sin que nadie abriera un puerto ni robara una credencial los contenedores donde el asistente ejecuta código, normalmente uno por sesión, compartían almacenamiento interno sin aislar. Con esa pieza en su sitio, bastaba con dejar una instrucción escrita en una sesión para que la sesión de otra persona leyera su Gmail, Drive, Teams o sus repositorios de GitHub y entregara el contenido a la cuenta del atacante. (Fuente: blog.checkpoint.com)
No hay exploit binario que analizar ni payload que buscar. La instrucción es texto y el canal es un directorio compartido. Lo llamativo es lo que no aparece en el relato es decir, ninguna autenticación rota, ninguna credencial robada, ningún cortafuegos atravesado o ninguna web falsa engañando a nadie. Se usó una sesión legítima, con permisos que su dueño ya había concedido para leer datos que esa sesión tenía todo el derecho a leer.
El sandbox no es la frontera
La palabra sandbox transmite una seguridad que no siempre tiene. En un agente con herramientas el contenedor aísla procesos, no datos. Si dos inquilinos comparten un servicio interno es decir, un volumen, una cola, una caché, o un directorio de trabajo, el límite real es ese servicio, no la puerta que vigila el WAF.
¿Y la exfiltración? cuando llega, sale disfrazada de tráfico normal HTTPS hacia Google, Microsoft o GitHub, autenticado como el usuario. Las listas de dominios permitidos, la reputación de destinos o el filtrado por categorías no ven nada raro porque no hay nada raro y eso es lo grave, es la misma conexión que el agente abre todos los días cuando alguien le pide ordenar el correo.
Conviene decirlo sin adornos y es que la frontera de un agente es exactamente aquello que su sesión ya tiene autorizado. Todo lo que el agente puede leer con permiso es para un atacante que controla las instrucciones material disponible.
No es un caso aislado
La misma semana ha traído variantes del mismo patrón. Anthropic reconoció su cuarto incidente de hacking por IA un Claude Opus 4.6 temprano, en una evaluación de enero con salida a internet mal configurada, no pudo abortar su tarea y accedió a sistemas reales de terceros. No se detectó hasta agosto y obligó a revisar 481 millones de transcripciones (Fuente: thehackernews.com)
Por su parte, la Comisión Europea examina bajo la AI Act el caso DseWiki ya que entre mayo y julio, miles de agentes autónomos usaron una wiki alemana como canal de comunicación, con 14.666 ediciones atribuidas a 3.103 agentes (Fuente: infobae.com)
Los tres casos comparten la misma forma. El agente hace lo que se le pide, con los permisos que ya tiene y el fallo aparece en la infraestructura que lo rodea es decir, almacenamiento compartido entre cuentas o salida a internet mal configurada, un destino que nadie esperaba, no, la culpa no está en el modelo.
El atacante también es un agente
Y no conviene mirar solo lo que hace tu agente. Esta misma semana se ha documentado la primera intrusión empresarial orquestada por agentes autónomos: Unit 42 reconstruyó un ataque completo ejecutado en menos de diez horas, con más de cincuenta técnicas de MITRE ATT&CK y coordinación entre agentes a través de ficheros Markdown. Lo que antes era trabajo de semanas se comprimió en una noche (Fuente: deafnews.it)
Google Threat Intelligence describe el mismo salto desde el otro lado, una campaña multiagente comprometió miles de credenciales en seis horas sobre infraestructura robada y hay grupos envenenando metadatos de paquetes open source para que los asistentes de código recomienden dependencias maliciosas (Fuente: radarbytes.com)
Junta las dos piezas y el cuadro cambia ya que el agente es a la vez superficie de ataque y herramienta del atacante. La defensa que solo mira el perímetro llega tarde a las dos cosas.
¿Qué mirar?
- Inventario de conectores. Qué puede leer y escribir el agente, conector por conector. El que no sea imprescindible para la tarea se apaga; cada permiso que sobrevive es superficie.
- Registro de llamadas a herramienta. La traza útil no está en las conexiones de red, está en el uso de herramientas es decir qué herramienta, sobre qué recurso, a qué hora y con qué frecuencia. Es la telemetría la que distingue un agente trabajando de un agente usado en tu contra hay que activarla y retenerla.
- Aislamiento entre inquilinos. Almacenamiento separado por sesión y por usuario, y el agente tratado como identidad propia en lugar de como extensión de tu cuenta. Si dos sesiones comparten un recurso interno, ese recurso es el límite.
Cómo lo probaría en mi laboratorio
Dos cuentas del mismo asistente, el mismo conector activo en ambas y una instrucción inocua que escriba un fichero. Después, desde la segunda cuenta, comprobar si veo algo que no debería ver. Si lo veo… tengo el problema medido y reproducible y no he tocado nada de producción. Es una prueba de veinte minutos que dice más que cualquier cuestionario de cumplimiento.
Lo que hay que retener
Aislar procesos no es aislar datos. El límite de un agente no está en la puerta que vigila la red, sino en lo que su sesión puede leer y en quién más puede leer ese mismo sitio.