La trifecta letal en producción: cómo los copilotos empresariales se convirtieron en herramientas de exfiltración de datos

El artículo desarrolla un marco de análisis —la "trifecta letal" (lethal trifecta), acuñado por Simon Willison— para explicar por qué varios copilotos y agentes de IA empresariales terminaron, durante 2025, filtrando datos privados sin que mediara ningún fallo de seguridad tradicional en el código. La idea central es sencilla: un sistema basado en un modelo de lenguaje se convierte en un riesgo de robo de datos cuando coinciden tres condiciones a la vez: (1) tiene acceso a datos privados, (2) está expuesto a contenido no confiable (un correo, un ticket de soporte, un formulario web, un issue público) y (3) dispone de una vía de salida hacia el exterior. El problema de fondo es que el modelo procesa instrucciones y datos por el mismo canal: cualquier texto que llega al contexto —una fila de base de datos, un ticket, un correo— es, para el modelo, una instrucción candidata. Cuando las tres condiciones concurren, la filtración es cuestión de tiempo; basta con eliminar una de las tres patas para que el ataque no tenga adónde ir.

El autor ilustra el patrón con casos concretos y documentados. El primero es EchoLeak (CVE-2025-32711, CVSS 9.3), una vulnerabilidad de "cero clics" contra Microsoft 365 Copilot, revelada por Aim Labs en junio de 2025. Un atacante envía un único correo manipulado; cuando el usuario más tarde hace una consulta cualquiera a Copilot, la canalización de recuperación de contenido (retrieval) incorpora ese correo al contexto y ejecuta la instrucción oculta, permitiendo a Copilot acceder a contenido de OneDrive, SharePoint y Teams y exfiltrarlo. Aim Labs denominó la técnica "LLM Scope Violation". Lo llamativo del caso, según el artículo, es la cantidad de controles razonables que el ataque logró sortear de forma encadenada: evadió el propio clasificador de inyecciones de Microsoft, esquivó la redacción de enlaces mediante Markdown de estilo referencia, disparó la petición de salida a través de una imagen que el cliente cargaba automáticamente, y envió los datos mediante un proxy de Microsoft Teams que ya gozaba de la confianza de la política de seguridad de contenido. Cada control era razonable por separado, pero la cadena completa los superó a todos, lo que lleva a la conclusión de que la inyección de instrucciones ya es una clase de vulnerabilidad práctica y de alta severidad en producción, y que la defensa debe ser arquitectónica —mínimo privilegio, acotar los datos antes de que el modelo pueda alcanzarlos, pruebas adversariales continuas— y no un simple filtro mejor.

El segundo caso, ForcedLeak (CVSS 9.4), identificado por Noma Security, afectó a Salesforce Agentforce con la función Web-to-Lead activada. Un atacante envía un formulario público de captación de leads con una instrucción oculta en el campo Descripción (que admite hasta 42.000 caracteres, espacio suficiente para una carga completa). Cuando un usuario interno le pide al agente que procese los leads, este ejecuta la instrucción incrustada, consulta datos del CRM y los exfiltra. El dato más citado del caso es que los datos salieron hacia un dominio que seguía figurando en la lista de destinos de confianza de Salesforce pero cuyo registro había caducado; los investigadores lo compraron por cinco dólares, demostrando que una lista blanca de dominios verifica hacia dónde va una petición, pero nunca si esa petición debería producirse. Es el llamado problema del "diputado confundido" (confused deputy) en producción, agravado por la falta de mantenimiento de esas listas.

Dos casos adicionales, ambos vinculados al Model Context Protocol (MCP), trasladan el mismo patrón al ámbito del desarrollo de software. En Supabase MCP, demostrado por General Analysis, un desarrollador que usa Cursor con el conector de Supabase autenticado mediante la clave service_role —que por diseño ignora la seguridad a nivel de fila y ve todas las filas de la base de datos— pide al agente que revise tickets de soporte. Un atacante introduce en un ticket una instrucción oculta que pide leer la tabla integration_tokens y pegarla en la respuesta; el agente, incapaz de distinguir el contenido de un ticket de una instrucción, lo hace. Supabase respondió publicando un modo de solo lectura y acotado por proyecto, lo que elimina la posibilidad de escritura, pero Willison señala que el solo-lectura ayuda y no basta: un modelo que puede leer datos privados y está expuesto a inyección igualmente los filtra a través de su propia respuesta. En GitHub MCP, expuesto por Invariant Labs en mayo de 2025, un atacante abre un issue en un repositorio público con una instrucción oculta; cuando la víctima pide a su agente que revise los issues abiertos, este sigue la instrucción, extrae contenido de un repositorio privado y lo escribe en un pull request dentro del repositorio público, donde el atacante puede leerlo con calma. Invariant lo bautizó como "toxic agent flow": un problema arquitectónico que no depende de un proveedor concreto sino de cualquier modelo conectado a ese servidor MCP.

A partir de estos casos, el artículo extrae un conjunto de lecciones defensivas comunes, que enmarca dentro de lo que llama la "escalera de contención" (Containment Ladder). Primero, como el modelo no puede distinguir datos de instrucciones, la separación debe ser estructural, porque ningún clasificador detecta todas las formulaciones posibles (EchoLeak batió uno diseñado justamente para esto). Segundo, todo contenido recuperado o ingerido debe tratarse como hostil, diseñando el sistema para que, aunque una inyección tenga éxito, no alcance nada de valor. Tercero, conviene romper deliberadamente una de las tres patas de la trifecta: si un agente maneja contenido no confiable, no debería tener a la vez amplio acceso de lectura a datos privados y una vía de salida. La regla "Agents Rule of Two" de Meta lo resume así: sin un humano en el bucle, un agente debe quedarse como máximo con dos de las tres condiciones, algo que puede codificarse en permisos de nube, reglas de red y controladores de admisión. Cuarto, el acceso de salida debe ser algo que se concede explícitamente, no algo que viene por defecto: ForcedLeak, EchoLeak y los casos de MCP necesitaron una vía de salida, y varios de ellos usaron un destino que ya gozaba de confianza previa. Quinto, el modo de solo lectura es un control real pero incompleto: impide el robo por escritura mientras deja intacta la fuga a través de la propia respuesta del agente.

El artículo cierra subrayando que ninguno de los copilotos analizados borró nada; durante una ventana de tiempo, varios de ellos funcionaron como una herramienta de robo de datos con una marca corporativa reconocible. Cualquier organización que opere un copiloto empresarial o un agente conectado por MCP con acceso a datos privados y capacidad de alcanzar el exterior ya reúne los ingredientes de uno de estos incidentes. La conclusión del autor es que el remedio es estructural y está en manos de cada organización, sin depender de que el proveedor lo resuelva: acotar los datos accesibles, cortar deliberadamente una de las tres patas, convertir el acceso de salida en algo que se otorga de forma explícita, y dejar de pedirle a una lista blanca de dominios una garantía que nunca estuvo diseñada para ofrecer.