Exfiltración del lado del servidor mediante agentes de investigación profunda

¿Qué es esto?

La exfiltración del lado del servidor es una clase de inyección de prompts indirecta en la que un agente conectado filtra tus datos desde la nube del proveedor en lugar de desde tu navegador. El caso de referencia es ShadowLeak, divulgado por Radware el 18 de septiembre de 2025 (reportado a OpenAI el 18 de junio de 2025, corregido a principios de agosto de 2025). Radware demostró que un único correo manipulado, procesado por el agente Deep Research de ChatGPT conectado a Gmail, podía hacer que el agente leyera contenido sensible de la bandeja de entrada y lo enviara a una URL controlada por el atacante — sin clics, sin interfaz visible y sin aprobación del usuario.

Lo que distingue a esta clase es dónde ocurre la fuga. La investigación previa — EchoLeak (Aim Security) y AgentFlayer (Zenity) — dependía del renderizado del lado del cliente: la exfiltración se disparaba cuando el navegador del usuario cargaba una imagen controlada por el atacante. ShadowLeak traslada la fuga al backend de OpenAI: la propia herramienta de navegación del agente realiza directamente la solicitud saliente.

Cómo funciona

El ataque aprovecha la tríada letal — datos privados, contenido no confiable y un canal saliente — presentes a la vez en un mismo agente conectado. El contenido no confiable es un correo de apariencia inofensiva cuyas instrucciones se ocultan en el HTML (fuentes diminutas, texto blanco sobre blanco, trucos de maquetación): el humano nunca las ve, pero el agente las lee y las obedece al procesar el buzón.

Radware reportó que las instrucciones directas del tipo «envía estos datos a mi URL» se rechazaban de forma fiable; el enfoque que funcionó pasó de persuadir al modelo a abusar de la capa de ejecución de herramientas. Las técnicas de evasión reportadas son conductuales, no un exploit de código: afirmar una autorización falsa, disfrazar el punto de recolección como un servicio de «cumplimiento», ordenar reintentos para vencer controles de seguridad no deterministas, e instruir al agente a codificar en Base64 los campos robados antes de añadirlos a la URL — para que la capa de ejecución solo viera una cadena opaca en lugar de datos en claro. (Omitimos el payload textual; lo relevante es el patrón, no una receta reutilizable.)

Documento no confiable (correo/archivo/issue/invitación)
   → instrucciones ocultas en HTML/metadatos   [REDACTED]
   → la herramienta de navegación del agente lanza la solicitud desde la nube del proveedor
   → los datos codificados salen por una URL del atacante  ← sin render en el cliente, sin registro en tu red

Por qué importa

Las fugas del lado del servidor son más difíciles de ver y de detener que las del lado del cliente. La exfiltración parte del interior de la red del proveedor, de modo que una pasarela web segura, un agente de endpoint o una política de navegador de tu lado nunca ven la solicitud. Nada se renderiza, así que el usuario no tiene ninguna pista visual. Y donde las fugas de imágenes del lado del cliente suelen estar limitadas a una lista blanca de dominios (el mecanismo url_safe de OpenAI), Radware no observó ninguna restricción comparable sobre las URL que el agente podía alcanzar directamente — un conjunto mucho más amplio de sumideros de exfiltración.

La lección más amplia es la generalidad: cualquier conector que alimente texto a un agente es un vector de inyección. Radware señala que el mismo patrón se extiende a Drive, SharePoint, invitaciones de Outlook y Google Calendar, mensajes de Teams, README e issues de GitHub, registros de Notion y Linear. El agente se convierte en un proxy de confianza que saca los datos bajo la apariencia de un uso normal de herramientas.

Defensas

El saneamiento del contenido antes de la ingesta ayuda pero no basta: normaliza y elimina el CSS invisible, los caracteres ofuscados y el HTML sospechoso de los documentos antes de que el agente los lea. No detendrá una instrucción bien diseñada que sobreviva a la normalización.

Las mitigaciones duraderas atacan la tercera pata de la tríada y el comportamiento del agente:

• Cortar el canal saliente. El 4 de junio de 2026, OpenAI extendió el Lockdown Mode a las cuentas personales y Business de autoservicio de ChatGPT (introducido el 13 de febrero de 2026). Desactiva de forma determinista Deep Research, el modo Agente, la navegación web en vivo (solo caché), la recuperación de imágenes web, la red de Canvas, los conectores en vivo y las descargas de archivos — precisamente para eliminar las rutas que una inyección exitosa usa para exfiltrar. Véase nuestra nota sobre el Lockdown Mode de OpenAI.
• Lista blanca de salida. Limita los dominios que la capa de navegación/herramientas de un agente puede alcanzar a un pequeño conjunto aprobado, y trata cualquier herramienta de fetch directo como de alto riesgo.
• Monitoreo de intención. El control recomendado por Radware es una monitorización conductual continua: comparar las acciones y la intención inferida del agente con el objetivo original del usuario, y bloquear las desviaciones en tiempo real.
• Higiene de conectores. Concede los alcances más estrechos, aísla los conectores sensibles y registra las lecturas de conectores para que un intento de exfiltración deje un rastro que tú controlas.

Este es el lado ofensivo de una defensa que ya hemos cubierto; ambos encajan directamente con el marco de la tríada letal.

Estado

Elemento	Estado	Fecha
ShadowLeak (ChatGPT Deep Research, Gmail)	Corregido por OpenAI	Principios de agosto de 2025
Clase de exfiltración del lado del servidor	En curso, en todos los conectores	2025–2026
Lockdown Mode de OpenAI (corta el canal saliente)	Desplegado en personal/Business	4 de junio de 2026
Fugas del lado del cliente (EchoLeak, AgentFlayer)	Previas, corregidas	2025

La exfiltración del lado del servidor no es un único fallo que se corrige una vez; es una propiedad estructural de los agentes conectados y autónomos. Hasta que la monitorización a nivel de intención y el control estricto de salidas sean estándar, la postura más segura para los datos sensibles es negar al agente un canal saliente que no necesita estrictamente.