Seis vulnerabilidades de IA. Tres patrones de fallo. La mayoría de las organizaciones están corrigiendo la equivocada.

La ola que redefinió el riesgo de seguridad en IA

Entre junio de 2025 y abril de 2026, investigadores de seguridad revelaron seis vulnerabilidades críticas de IA en plataformas que la mayoría de las empresas utilizan a diario. De forma individual, cada divulgación generó un parche y un ciclo de noticias. En conjunto, constituyen la mayor evidencia de un cambio estructural en la manera en que se roba la información empresarial.

Puntos clave

1. Seis vulnerabilidades críticas de IA reveladas en menos de un año. EchoLeak, Reprompt, GeminiJack, ForcedLeak, GrafanaGhost y el ataque a la cadena de suministro de plugins de OpenAI afectaron a Microsoft Copilot, Salesforce, Google Gemini, Grafana y el ecosistema de OpenAI entre mediados de 2025 y abril de 2026.
2. El sector las trata como un solo problema — en realidad son tres. Estas seis vulnerabilidades muestran tres patrones de fallo distintos: entrada no confiable procesada por IA sin validación, acceso a datos demasiado amplio sin control por operación y procesos de back-end con un alcance funcional para el que nunca fueron diseñados.
3. La entrada no confiable es el fallo más constante. Todas las vulnerabilidades de la serie comienzan con datos externos que ingresan al sistema por un canal legítimo y son procesados por IA sin validación. Este patrón es el que el sector está ignorando en gran medida.
4. GrafanaGhost es arquitectónicamente diferente a las otras cinco. Grafana tiene RBAC en el acceso a datos para usuarios. El ataque nunca lo activó — porque operó a través de procesos de back-end a nivel de sistema, no mediante sesiones de usuario. Los controles de acceso a datos resuelven las otras cinco. No resuelven GrafanaGhost.
5. Los controles a nivel de modelo fallaron en todos los casos. Las defensas de Grafana cayeron ante una sola palabra clave. El CSP de Salesforce se eludió por cinco dólares. Los controles a nivel de modelo son configuraciones internas del sistema atacado — complementan controles reales, pero no los sustituyen.

EchoLeak en Microsoft 365 Copilot fue la primera vulnerabilidad de IA reconocida formalmente como zero-click — CVSS 9.3, parcheada en junio de 2025. ForcedLeak en Salesforce Agentforce llegó en septiembre de 2025 — CVSS 9.4, explotable con la compra de un dominio por cinco dólares. GeminiJack en Google Gemini Enterprise fue un ataque zero-click real que podía exfiltrar años de datos de Workspace desde un solo documento manipulado. Reprompt demostró la exfiltración de Copilot con un solo clic a través de una URL manipulada. GrafanaGhost convirtió procesos de back-end confiables en un canal invisible de exfiltración de datos. Y un ataque a la cadena de suministro en el ecosistema de plugins de OpenAI operó sin ser detectado durante seis meses en 47 empresas usando credenciales de agentes robadas.

Cada proveedor respondió de forma responsable. Todas las plataformas fueron parcheadas. Y todos los ataques aprovecharon brechas arquitectónicas que los parches individuales no resuelven.

El Informe Global de Amenazas de CrowdStrike 2026 encontró que el 82% de las detecciones en 2025 no involucraron malware — los atacantes ya operan a través de herramientas legítimas. Estas seis vulnerabilidades llevan esa tendencia al extremo: la IA es la herramienta legítima, el canal de acceso a datos confiable es la vía de exfiltración y la tecnología de monitoreo no detecta nada inusual.

Las seis vulnerabilidades de un vistazo

Patrón uno: entrada no confiable procesada como contexto confiable de IA

Todas las vulnerabilidades de esta serie comienzan igual. Datos externos ingresan al sistema por un canal legítimo — un email, un documento compartido, un formulario web, parámetros de consulta en URL, un plugin comprometido — y luego un componente de IA los procesa sin tratarlos como potencialmente maliciosos.

La carga útil de EchoLeak fue un email manipulado que Copilot procesó como contexto durante una consulta rutinaria. El usuario nunca lo abrió. La de GeminiJack fue un Google Doc manipulado, compartido con cualquier persona de la organización objetivo, indexado por el sistema RAG de Gemini y latente hasta que cualquier búsqueda de un empleado lo activaba. La de ForcedLeak fue texto oculto en un campo de formulario Web-to-Lead de 42,000 caracteres — la IA no podía distinguir entre los datos del formulario y las instrucciones inyectadas. La de GrafanaGhost fueron parámetros de consulta en URL almacenados en los registros de monitoreo de eventos de Grafana — solicitudes web externas registradas como tráfico rutinario, luego procesadas por procesos de enriquecimiento de back-end habilitados con IA.

El principio de que toda entrada externa debe validarse antes de ser procesada por cualquier sistema es fundamental en la seguridad de aplicaciones web. Las organizaciones implementan WAFs para esto. Los desarrolladores se forman en ello. Nadie lo aplicó a los datos procesados por IA — porque nadie pensó en emails, documentos compartidos, registros de eventos y campos de formularios como canales de entrada para inyección de prompts en IA.

El Informe de Seguridad de Datos de IA de Cyera 2025 reveló que el 83% de las empresas ya usan IA en operaciones diarias, pero solo el 13% tiene visibilidad sólida sobre cómo la IA accede a sus datos. Esa brecha de 70 puntos es la superficie de ataque que explotan estas vulnerabilidades. La IA procesa datos de docenas de fuentes. Nadie valida esas fuentes para detectar instrucciones adversarias hacia la IA.

Este es el fallo más consistente en las seis vulnerabilidades, y es el que el sector está ignorando. Los controles de acceso a datos no lo resuelven. Los controles a nivel de modelo tampoco. Requiere disciplina de validación de entrada extendida a toda fuente de datos que la IA procese.

Patrón dos: acceso a datos de IA demasiado amplio sin control por operación

Cinco de las seis vulnerabilidades — EchoLeak, Reprompt, GeminiJack, ForcedLeak y el ataque a plugin de OpenAI — implican sistemas de IA que operan en nombre de un usuario con acceso implícito y amplio a datos, sin controles por operación.

Microsoft 365 Copilot tiene acceso preconfigurado a OneDrive, SharePoint y Teams — toda la suite de productividad. El RAG de Google Gemini Enterprise accede nativamente a Gmail, Docs y Calendar. Salesforce Agentforce puede consultar todo el CRM. En cada caso, la IA se autentica una vez por sesión o conexión y luego accede a todo lo que puede. Cuando se ejecutan instrucciones inyectadas, la IA recupera datos mucho más allá de lo que cualquier usuario pretendía — y ninguna política evalúa cada recuperación individual.

El ataque a plugin de OpenAI es una variante de este patrón: credenciales comprometidas operaban como identidad del agente, otorgando acceso amplio en 47 entornos durante seis meses. Las credenciales eran válidas. El acceso parecía normal. Nada limitaba lo que esas credenciales podían hacer en cada operación.

El control de acceso por operación — autenticando cada solicitud de forma independiente, evaluando políticas basadas en atributos en cada operación, aislando credenciales del contexto accesible por la IA y registrando cada acceso con atribución completa — habría limitado el alcance de estos cinco casos.

El Informe de Riesgo de Seguridad y Cumplimiento de Datos de Kiteworks: Pronóstico 2026 encontró una brecha de 15 a 20 puntos entre controles de gobernanza (monitoreo, registros, intervención humana) y controles de contención (vinculación de propósito, kill switches, aislamiento de red). La brecha en la aplicación por operación es real y urgente — para las cinco vulnerabilidades donde aplica.

Patrón tres: fallos de contención de procesos y alcance funcional

GrafanaGhost es arquitectónicamente diferente a las otras cinco, y tratarlo como un problema más de control de acceso a datos es interpretar mal la vulnerabilidad.

Grafana tiene RBAC para el acceso a datos de usuario. GrafanaGhost nunca lo activó. El ataque no operó en nombre de ningún usuario. Operó a través de procesos de enriquecimiento de back-end confiables que corrían con privilegios de sistema — procesos diseñados para correlacionar, analizar y preparar datos de eventos para dashboards.

Cuando el proceso de enriquecimiento analizó el evento del atacante (que contenía el prompt de IA oculto en parámetros de consulta de URL), el componente de IA ejecutó las instrucciones en el contexto privilegiado del proceso. Construyó un dashboard que nadie solicitó, incrustó datos sensibles en etiquetas de imagen y los hizo accesibles externamente. Los investigadores de Noma descubrieron que la palabra clave «INTENT» colapsaba por completo los controles de la IA. Un fallo en la validación de URL disfrazó un servidor externo como interno.

El proceso de back-end necesitaba acceso amplio de lectura a datos. Eso es defendible. Lo que no necesitaba era la capacidad de llamar rutinas que generan dashboards, etiquetas de imagen o solicitudes salientes a servidores externos. Esas son capacidades de salida que el proceso nunca debió tener — pero nadie evitó activamente que las usara.

El ataque a plugin de OpenAI comparte un elemento del patrón tres: las credenciales de agente estaban almacenadas donde el código comprometido del plugin podía acceder, porque los tokens de autenticación no estaban aislados del contexto accesible por la IA.

El principio de mínimo privilegio debe aplicarse al alcance funcional — qué APIs, rutinas de renderizado y canales de salida puede invocar un proceso — y al almacenamiento de credenciales, no solo al acceso a datos. Esta es la brecha de contención, y requiere una respuesta arquitectónica distinta a la gobernanza de acceso a datos.

Tres patrones de fallo mapeados a controles

Los controles a nivel de modelo fallaron en todos los casos — pero eso es el síntoma

Los controles de IA de Grafana fueron derrotados por una sola palabra clave. El Content Security Policy de Salesforce se eludió con un dominio expirado de cinco dólares. El RAG de Google Gemini no pudo distinguir entre un documento manipulado y uno legítimo. Las funciones de seguridad de Microsoft Copilot no evitaron que un email o una URL manipulados secuestraran su ventana de contexto.

Los controles a nivel de modelo son configuraciones internas del sistema atacado. Pueden ser anulados por inyección de prompts, eludidos al atacar los límites de confianza o neutralizados manipulando el contexto que procesa la IA. Todos los grandes LLM han sido jailbreakeados con tasas de éxito casi perfectas en investigaciones controladas. El estudio Agents of Chaos de febrero de 2026 — realizado por 20 investigadores de MIT, Harvard, Stanford, CMU y otros — documentó agentes de IA destruyendo infraestructura, divulgando bases de datos de información personal identificable y aceptando suplantación de identidad en entornos reales.

Los controles a nivel de modelo son una capa defensiva útil. Complementan controles reales. No los sustituyen. Ningún regulador, auditor o investigador forense aceptará «le dijimos al modelo que no lo hiciera» como evidencia de control de acceso, validación de entrada o contención de procesos.

Cómo Kiteworks resuelve el patrón de acceso a datos — y dónde el reto va más allá

Kiteworks proporciona una capa de datos gobernada entre los sistemas de IA y los repositorios de datos empresariales a través de su Secure MCP Server y la puerta de enlace de datos IA. Cada solicitud de datos de IA — ya sea de un asistente interactivo mediante MCP o de un pipeline RAG vía API — se autentica con OAuth 2.0 usando credenciales almacenadas en el llavero del SO (nunca expuestas al modelo de IA), se evalúa contra políticas RBAC y ABAC en tiempo real en cada operación, se limita la tasa para evitar extracciones masivas y se registra en una auditoría inalterable que alimenta el SIEM con atribución completa.

Estos controles abordan directamente el patrón dos — las cinco vulnerabilidades donde los sistemas de IA operan en nombre de un usuario con acceso implícito amplio y sin control por operación. El ABAC por operación limita lo que la IA puede acceder en cada solicitud. El aislamiento de credenciales evita la recolección. Los registros de auditoría permiten la detección y cumplen con los requisitos de cumplimiento.

Para el patrón uno (entrada no confiable), el principio que implementa Kiteworks — controles que operan de forma independiente al modelo de IA y fuera del contexto accesible por la IA — se extiende al reto de la validación de entrada. Pero validar si el contenido que ingresa en formularios de Salesforce, Google Docs, emails de Microsoft o registros de eventos de Grafana contiene instrucciones adversarias para la IA es una responsabilidad de la capa de aplicación que la gobernanza de acceso a datos por sí sola no resuelve.

Para el patrón tres (contención de procesos), la implementación de MCP de Kiteworks demuestra el enfoque arquitectónico correcto: tokens OAuth en el llavero del SO, ABAC en cada operación MCP, validación de rutas de acceso. Extender estos principios al alcance funcional de procesos de back-end de terceros — limitando lo que esos procesos pueden hacer, no solo a qué datos pueden acceder — es el siguiente reto.

La evaluación honesta: Kiteworks reduce el alcance del daño y permite la detección para el patrón dos. Los patrones uno y tres requieren controles arquitectónicos adicionales que el sector aún está desarrollando.

Qué deben hacer los líderes de seguridad — los tres patrones

Primero, audita los límites de confianza de entrada en cada integración de IA. Identifica todas las fuentes de datos que procesa la IA — emails, documentos compartidos, formularios, registros de eventos, respuestas de API, campos de metadatos. Si datos externos llegan a cualquier sistema donde un componente de IA los procesa, trata esa entrada como adversaria sin importar lo profundo que esté almacenada en el sistema. Aplica la misma disciplina de validación que usas para entradas de usuario expuestas a la web.

Segundo, exige control de acceso por operación para cada sistema de IA que opere en nombre de un usuario. Autenticación en cada solicitud, no solo al iniciar la conexión. ABAC evaluado en cada operación. Credenciales almacenadas fuera del contexto accesible por la IA. Registros de auditoría inalterables con atribución completa alimentando tu SIEM. Si falta alguno de estos elementos, la integración de IA no tiene control de acceso a datos que sobreviva a la inyección de prompts.

Tercero, limita los procesos de IA de back-end solo a las capacidades funcionales que requieren. Puede ser necesario un acceso amplio de lectura a datos. La capacidad de renderizar contenido, generar solicitudes salientes, construir dashboards o invocar rutinas de salida no lo es. El mínimo privilegio aplica a lo que los procesos pueden hacer, no solo a qué datos pueden acceder. Este es el control que faltó en GrafanaGhost.

Cuarto, deja de tratar los controles a nivel de modelo como controles compensatorios. Fallaron en todos los casos de esta serie. Son una capa defensiva útil — pero no sustituyen ninguno de los tres patrones anteriores.

Quinto, realiza pruebas de red team en las integraciones de IA para los tres patrones. Prueba la inyección de prompts a través de canales de usuario (patrón dos) y mediante datos de eventos, registros, metadatos y fuentes de datos de back-end (patrones uno y tres). Todas las vulnerabilidades de esta serie fueron descubiertas por investigadores, no por las organizaciones que operaban las plataformas. Si no pruebas, dejas el descubrimiento en manos de alguien con otras intenciones.

Los parches ya están aplicados. Las tres brechas arquitectónicas no. La próxima variante explotará el patrón que dejes sin resolver.