GrafanaGhost expone tres patrones de fallos de seguridad en IA, no solo uno

La URL de un atacante, un proceso back-end y tus datos financieros en un servidor externo

El 7 de abril de 2026, investigadores de Noma Security revelaron GrafanaGhost: un ataque que convirtió los propios procesos internos confiables de Grafana en un canal inadvertido de exfiltración de datos. El sector lo describió como un fallo en el control de acceso a datos de IA. Pero esa descripción es incompleta, y la diferencia tiene consecuencias para cualquier organización que implemente herramientas con IA.

Puntos clave

1. El ataque ocultó prompts en los datos de monitoreo de eventos. Los atacantes crearon URLs cuyos parámetros de consulta quedaban registrados en los logs de entrada de Grafana. Los procesos de enriquecimiento back-end, con privilegios a nivel de sistema, ejecutaron después las instrucciones de IA ocultas: crearon un dashboard no solicitado e incrustaron datos sensibles en etiquetas de imagen salientes.
2. Grafana tiene RBAC para el acceso a datos de cara al usuario. El ataque nunca lo activó. GrafanaGhost operó mediante procesos back-end a nivel de sistema, no sesiones de usuario. Los controles de acceso a nivel de usuario eran irrelevantes porque el ataque evitó por completo la capa de usuario.
3. No es un solo patrón de fallo, sino tres. Fallo en el límite de confianza de entrada (datos externos procesados sin validación), fallo de contención de procesos (un proceso back-end con un alcance funcional para el que nunca fue diseñado) y fallo en los guardarraíles a nivel de modelo (derribados por una sola palabra clave). Cada uno requiere una solución diferente.
4. El mismo fallo de confianza en la entrada aparece en todas las vulnerabilidades de IA importantes del último año. EchoLeak, GeminiJack, ForcedLeak, Reprompt y GrafanaGhost empiezan con datos externos no confiables que entran en un sistema y son procesados por IA sin validación.
5. La gobernanza de acceso a datos aborda un patrón. La validación de entradas y la contención de procesos abordan los otros dos. Mezclarlos garantiza que al corregir uno, los otros quedan expuestos.

Un atacante envió solicitudes web manipuladas a una instancia de Grafana. Las solicitudes eran normales, pero los parámetros de consulta de la URL contenían instrucciones ocultas para IA. El monitoreo de eventos de Grafana registró esas solicitudes como tráfico entrante legítimo. La carga maliciosa quedó almacenada en lo profundo del sistema, indistinguible de los datos operativos legítimos.

Grafana está en el centro de la observabilidad empresarial, conectado a bases de datos, infraestructura en la nube, sistemas financieros y backends de datos de clientes. Lo que ocurrió después es lo que hace que GrafanaGhost sea relevante a nivel arquitectónico.

Cómo funcionó realmente el ataque

Se ejecutaron procesos de enriquecimiento back-end confiables, diseñados para correlacionar, analizar y preparar datos de eventos para dashboards y alertas. Estos procesos operan con privilegios a nivel de sistema porque necesitan acceso a casi todos los datos. Leen de múltiples fuentes y escriben información enriquecida de nuevo en la base de datos. No están diseñados para trabajar datos para usuarios. No están sujetos a RBAC a nivel de usuario.

Cuando el proceso de enriquecimiento analizó el evento del atacante, encontró el prompt oculto de IA y lo ejecutó. El componente de IA, operando dentro del contexto privilegiado del proceso back-end, construyó un dashboard no solicitado, incrustó datos sensibles (métricas financieras, telemetría de infraestructura, registros de clientes) en etiquetas de imagen y dejó esas imágenes accesibles externamente.

Los investigadores de Noma descubrieron que la palabra clave «INTENT» hacía que los guardarraíles de la IA colapsaran. Un fallo separado de validación de URL —URLs relativas al protocolo con formato //attacker.com— engañó a las protecciones del lado del cliente para clasificar un dominio externo como interno. Los datos salieron como parámetros de URL en lo que parecía ser un renderizado de imagen.

Cada SIEM, herramienta DLP y agente de endpoint vio un proceso back-end haciendo lo que suelen hacer estos procesos. Nada se activó.

Tres patrones de fallo, no uno

La conversación en el sector ha agrupado GrafanaGhost con otras vulnerabilidades de IA bajo la narrativa de «la IA necesita mejores guardarraíles». Esa simplificación es peligrosa. GrafanaGhost —junto con la serie más amplia de vulnerabilidades de IA reveladas el último año— muestra tres patrones de fallo distintos. Cada uno requiere una respuesta arquitectónica diferente.

Patrón uno: Entrada no confiable tratada como contexto de IA confiable

Datos externos entraron al sistema por un canal legítimo y después fueron procesados por un componente de IA sin validación. En GrafanaGhost, los datos externos eran parámetros de consulta de URL almacenados en los logs de eventos. El proceso de enriquecimiento back-end trató esos datos como internos y confiables.

Este es el mismo fallo detrás de todas las vulnerabilidades de IA importantes del último año. La carga de EchoLeak era un correo electrónico manipulado que Copilot procesó como contexto. La de GeminiJack era un Google Doc manipulado e indexado por RAG. La de ForcedLeak era texto oculto en un campo Web-to-Lead de 42,000 caracteres. En todos los casos, el principio de que toda entrada externa debe validarse antes de que cualquier sistema la procese —el mismo principio detrás de la validación de entradas en aplicaciones web y los WAF— no se aplicó a los datos procesados por IA.

El hecho de que los datos del mundo exterior se almacenen internamente no los hace confiables. Este es un problema de validación de entrada de confianza cero, y requiere soluciones a nivel de aplicación y arquitectura de IA, no controles de acceso a datos.

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

Cinco de las vulnerabilidades reveladas el último año —EchoLeak, Reprompt, GeminiJack, ForcedLeak y un ataque a la cadena de suministro en el ecosistema de plugins de OpenAI— involucran sistemas de IA que operan en nombre de un usuario con acceso amplio e implícito a datos y sin control de políticas por operación. La IA se autenticó una vez a nivel de sesión y después accedió a todo lo que pudo alcanzar.

El control de acceso por operación —evaluar cada solicitud de datos contra la política— habría limitado el alcance del daño en cada uno de esos casos. Aquí es donde RBAC, ABAC, aislamiento de credenciales y registros auditables aplican directamente.

GrafanaGhost no es este patrón. El ataque operó mediante procesos back-end a nivel de sistema, no sesiones de usuario. Grafana tiene RBAC para el acceso a datos de cara al usuario, y nunca se activó. Aplicar controles del patrón dos a GrafanaGhost aborda el fallo equivocado.

El informe «Kiteworks Data Security and Compliance Risk: 2026 Forecast Report» identificó una brecha de 15–20 puntos entre controles de gobernanza y controles de contención. La brecha en la aplicación por operación es real y urgente —para las cinco vulnerabilidades donde aplica.

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

El proceso de enriquecimiento back-end en GrafanaGhost necesitaba acceso amplio de lectura a datos. Eso es justificable. Lo que no necesitaba era la capacidad de llamar rutinas para renderizar dashboards, generar etiquetas de imagen o hacer solicitudes salientes a servidores externos. Esas son capacidades de salida que el proceso nunca fue diseñado para usar, pero nadie evitó activamente que pudiera acceder a ellas.

Esto es un fallo de contención. El principio de mínimo privilegio debe aplicarse al alcance funcional —qué APIs, rutinas de renderizado y canales de salida puede invocar un proceso—, no solo al acceso a datos. Un proceso de enriquecimiento de datos que lee y escribe datos no debería poder invocar rutinas que se comunican con el exterior.

El ataque a la cadena de suministro de plugins de OpenAI también es un fallo de patrón tres: las credenciales de los agentes eran accesibles para código de plugins comprometidos porque los tokens de autenticación no se almacenaban fuera del contexto accesible para la IA. Seis meses de acceso en 47 empresas porque no existía aislamiento de credenciales.

El colapso de los guardarraíles a nivel de modelo — la tercera capa, no la primera

Grafana implementó defensas contra prompt injection. Una sola palabra clave las derribó. Esto es consistente con investigaciones más amplias: todos los LLM importantes han sido jailbreakeados con tasas de éxito casi perfectas. El estudio Agents of Chaos de febrero de 2026 documentó agentes de IA destruyendo infraestructura y revelando información personal identificable en entornos reales.

Los guardarraíles a nivel de modelo son una capa de defensa útil. No sustituyen la validación de entrada (patrón uno), la aplicación de controles de acceso por operación (patrón dos) ni la contención de procesos (patrón tres). Incluso si los guardarraíles hubieran funcionado, la arquitectura subyacente de GrafanaGhost —entrada no confiable llegando a un proceso privilegiado con alcance funcional excesivo— seguiría rota.

El papel de Kiteworks — y sus límites

Es importante ser preciso sobre lo que enseña GrafanaGhost y qué controles abordan cada patrón.

Kiteworks proporciona una capa de datos gobernada con aplicación de políticas RBAC y ABAC, autenticación OAuth 2.0 con credenciales en el llavero del sistema operativo, limitación de velocidad y registros auditables a prueba de manipulaciones que se envían al SIEM. Para sistemas de IA que solicitan datos a través de Kiteworks —ya sea mediante su Secure MCP Server o la puerta de enlace de datos IA— cada solicitud se autentica, autoriza y registra de forma independiente al modelo de IA.

Estos controles abordan el patrón dos: acceso a datos de IA en nombre de un usuario. Para las cinco vulnerabilidades donde un sistema de IA tenía acceso implícito amplio y sin control por operación —EchoLeak, Reprompt, GeminiJack, ForcedLeak, el ataque a plugins de OpenAI— el ABAC por operación, el aislamiento de credenciales y los registros auditables reducen directamente el alcance del daño y permiten la detección.

GrafanaGhost es patrón uno más patrón tres. El ataque operó mediante procesos back-end a nivel de sistema, no solicitudes de IA de cara al usuario. Los controles de acceso a datos —incluidos los de Kiteworks— abordan la cuestión del acceso a datos. No abordan el fallo de validación de entrada (datos de eventos no confiables procesados sin validación) ni el fallo de alcance funcional (el proceso de enriquecimiento con capacidades de salida para las que nunca fue diseñado).

Lo que Kiteworks sí aporta a la lección de GrafanaGhost es el principio de independencia: controles de seguridad que operan por debajo del modelo de IA, fuera del contexto de la IA y de manera independiente a las instrucciones que reciba la IA. Extender ese principio a los límites de confianza de entrada y al alcance funcional de los procesos es el reto arquitectónico que define GrafanaGhost.

Qué deben hacer los responsables de seguridad — Abordar los tres patrones

Para el patrón uno (confianza en la entrada): audita todas las fuentes de datos que procesa la IA —logs de eventos, correos electrónicos, documentos compartidos, formularios, respuestas de API—. Si cualquier entrada externa alimenta un sistema donde un componente de IA la procesa, trata esa entrada como adversaria. Aplica la misma disciplina de validación a los datos procesados por IA que aplicas a la entrada de usuarios en la web.

Para el patrón dos (alcance de acceso a datos): exige autenticación por operación y ABAC para cada solicitud de datos de IA. Almacena las credenciales fuera del contexto de la IA. Genera registros auditables a prueba de manipulaciones con atribución completa que se envíen a tu SIEM.

Para el patrón tres (contención de procesos): limita los procesos de IA back-end solo a las capacidades funcionales que realmente requieren. Puede ser necesario un acceso amplio de lectura a datos. La capacidad de renderizar contenido, generar solicitudes salientes o construir dashboards de cara al usuario no lo es. Restringe lo que los procesos pueden hacer, no solo los datos a los que pueden acceder.

Para los tres: haz pruebas de red team a tus integraciones de IA. GrafanaGhost fue descubierto por investigadores, no por defensores. Prueba la prompt injection a través de datos de eventos, entradas de logs y metadatos, no solo mediante canales de cara al usuario.

GrafanaGhost ya está parcheado. Las tres lecciones arquitectónicas —validar la entrada no confiable antes del procesamiento por IA, aplicar políticas de acceso a datos por operación y contener los procesos al alcance funcional para el que fueron diseñados— aún no lo están.