Cada trimestre, el Proyecto de SeguridadOWASP publica un resumen de los Seguridad IA más significativos del periodo, relacionando cada uno de ellos con el OWASP 10 OWASP para LLM y el nuevo Top 10 para aplicaciones agenticas. La edición del primer trimestre de 2026 merece la atención de todos los responsables de seguridad, no por ninguna brecha en concreto, sino por el patrón que se repite en todas ellas.
El propio resumen OWASP lo deja claro: este ámbito ha pasado de ser risk teórico risk una explotación en el mundo real, y la acción ha dejado de centrarse en el modelo en sí. Los atacantes y los fallos se centran ahora en las identidades de los agentes, las capas de orquestación y las cadenas de suministro, y no solo en los resultados de los modelos. El mérito de la investigación subyacente corresponde a OWASP a los autores de los informes que cita; lo que sigue es mi análisis de los cuatro incidentes más relevantes para las empresas sujetas a regulación, y lo que cada uno de ellos exige de sus controles.
«Para garantizar la seguridad de la IA es necesario pasar de las medidas de protección a nivel de modelo a controles de seguridad integrales que abarquen el sistema, la identidad y las operaciones». — Proyecto de Seguridad OWASP , resumen del primer trimestre de 2026
Esa frase podría ser la declaración de principios de todo lo que creamos en OneCompliant. A continuación, cada incidente va acompañado de la OneCompliant : el control que lo habría detectado o contenido.
1. GrafanaGhost: cuando tu panel de control se convierte en la vía de exfiltración
Según el OWASP (que cita un estudio de Noma Security), los atacantes podían introducir instrucciones ocultas en contenido externo que el asistente de IA de Grafana incorporaba. El contexto malicioso llevó al asistente a renderizar una imagen externa, y esa llamada de renderizado filtró datos de la empresa hacia un servidor controlado por el atacante en forma de parámetro de URL. Grafana corrigió la ruta de renderización de imágenes en Markdown y señaló que la explotación requería una interacción significativa por parte del usuario. Pero lo que importa es la naturaleza del ataque : una capa de observabilidad de confianza, que albergaba datos de telemetría, infraestructura, clientes y financieros, se convirtió en una fuga de información.
Considera todo lo que ingiere un AI —registros, enlaces, paneles de control, tickets— como información no fiable, y controla lo que puede enviar al exterior. Se trata de una inyección indirecta de comandos; analízala como si fuera una amenaza de tipo XSS o SSRF. Un asistente con amplio acceso a la telemetría nunca debería tener, además, una vía de salida sin restricciones. Inspecciona el contexto que entra en el modelo; controla lo que se permite que salga.
2. Vertex AI Double Agent»: la identidad es el nuevo perímetro
Según el resumen (que cita a la Unidad 42 de Palo Alto), un agente implementado en Vertex AI Engine de Google Cloud heredó muchos más permisos de los que necesitaba a través de una cuenta de servicio gestionada por Google. Los investigadores utilizaron esa identidad con un alcance excesivo para extraer credenciales, actuar como agente del servicio, acceder a los recursos de los proyectos de los clientes e incluso acceder a imágenes y código fuente internos restringidos. Google revisó posteriormente sus directrices. La lección no es que «Vertex no sea seguro», sino que la configuración predeterminada de la plataforma gestionada concedió a un agente más acceso del que nadie había previsto.
La identidad de los agentes merece el mismo escrutinio que el acceso administrativo con privilegios. Se debe aplicar el principio de «mínimo privilegio» por defecto, establecer un ámbito de aplicación específico para cada implementación, utilizar credenciales de corta duración y mantener un inventario actualizado de todas las identidades de servicio vinculadas a la ejecución de los agentes. No te fíes de los valores predeterminados de la plataforma: comprueba explícitamente si un agente puede moverse entre proyectos, buckets, registros o la infraestructura de modelos.
3. La filtración del agente interno de Meta: el alcance de una respuesta peligrosa
Según el resumen (que cita a The Guardian), un ingeniero de Meta pidió ayuda en un foro interno, un agente AI propuso una solución y el ingeniero la implementó, lo que dejó expuesto brevemente un gran volumen de datos confidenciales de usuarios y de la empresa a los ingenieros durante unas dos horas. No hubo ningún atacante externo y Meta afirmó que no se gestionaron indebidamente los datos de los usuarios, pero aun así se desencadenó una importante respuesta interna en materia de seguridad. Es un claro ejemplo de cómo una sola recomendación insegura de un agente puede convertirse en un incidente de control de acceso a escala empresarial.
Debe existir una capa de control entre el asesoramiento de la IA y la ejecución. Cualquier recomendación que pueda modificar los permisos, la visibilidad de los datos o policy someterse a una validación determinista y a una revisión humana antes de aplicarse, especialmente en los flujos de trabajo de ingeniería y seguridad. Se debe considerar que la salida del agente no es fiable hasta que se haya verificado.
4. Mercor / LiteLLM: tu cadena AI es más amplia que tus modelos
Según el resumen (que cita a WIRED), Meta suspendió su colaboración con el proveedor AI Mercor tras una filtración relacionada con versiones maliciosas de la herramienta de código abierto LiteLLM. Dado que Mercor se encarga de la generación de datos de entrenamiento propietarios para los principales laboratorios, el incidente planteó la posibilidad de que se hubieran visto expuestos métodos de datos de entrenamiento confidenciales y operaciones de subcontratistas, lo que provocó una reevaluación en varios laboratorios. La brecha se produjo a través de una dependencia de software en la pila AI, no en el modelo.
Tu cadena AI incluye las bibliotecas de orquestación, las integraciones con MCP y los proveedores que generan tus datos. Identifica y verifica las dependencias, exige a AI pruebas al estilo SBOM y madurez en la respuesta ante incidentes, y trata a los proveedores de datos como proveedores críticos dentro de tu programa de gobernanza, no como meras notas al pie en el proceso de adquisición.
El hilo que los une
OWASP una segunda observación que debería replantear tu forma de ver risk de la IA: la mayoría de estos incidentes no tienen CVE. No se trata de errores de código aislados, sino de configuraciones erróneas, autonomía excesiva, límites de confianza débiles y manipulación del flujo de datos. Solo un fallo clásico de software integrado, como el problema de ejecución remota de código de Flowise (CVE-2025-59528), que se está explotando activamente, encaja perfectamente en la gestión tradicional de vulnerabilidades.
Ahí radica la brecha. Si tu risk de IA se basa en la detección de CVE, es estructuralmente incapaz de detectar la mayor parte de los fallos reales de la IA. Se trata de riesgos sistémicos y arquitectónicos, y exigen controles que actúen en tiempo de ejecución —en los ámbitos de la identidad, la agencia y el flujo de datos— y que generen pruebas.
«La atención se ha desplazado de los resultados de los modelos a las identidades, la coordinación y las cadenas de suministro. La gobernanza debe adaptarse a este cambio: pasar de los documentos a los controles operativos».
Esa es precisamente la capa OneCompliant : OASF los ámbitos de control, OASAT en qué medida se cumplen y Aegis los Aegis en el punto de uso —inspeccionando las solicitudes y el contexto, regulando qué datos pueden salir, delimitando lo que los agentes están autorizados a hacer y registrando cada decisión como prueba. Informes como OWASP son el campo que nos indica, incidente tras incidente, por qué esa capa ya no es opcional.
Lee el resumen completo: es un recurso trimestral realmente valioso, y OWASP las colaboraciones al respecto: Resumen de vulnerabilidadesOWASP , 1.º trimestre de 2026 →
Estos incidentes se corresponden con medidas de control. ¿Las tienes?
OASAT tu AI en función precisamente de estos modos de fallo —identidad, agencia, cadena de suministro y flujo de datos— y Aegis los controles en tiempo de ejecución. Descubre tus vulnerabilidades antes de que se conviertan en tu tema principal.