Cuando la base de datos es la frontera de seguridad: atacar a los agentes de datos LLM
Un estudio de junio de 2026 ataca agentes analíticos gobernados por LLM en seis sistemas y demuestra que ni la seguridad del modelo ni los controles clásicos de base de datos bastan por sí solos.
¿Qué es esto?
Un agente de datos es el patrón que hay detrás de la mayoría de los productos de tipo «conversa con tu almacén de datos»: un LLM lee una pregunta en lenguaje natural, escribe SQL o invoca herramientas analíticas contra una base de datos en producción, recupera las filas, razona sobre ellas y devuelve una respuesta, a menudo en varios pasos y con credenciales permanentes sobre los datos subyacentes. Se sitúa en la intersección de dos tradiciones de seguridad que rara vez dialogan. La seguridad de bases de datos supone una superficie de consultas fija y auditable; la seguridad de agentes LLM supone que el peligro está en el prompt. Un agente de datos rompe ambas premisas, porque la superficie de consultas ahora la genera sobre la marcha un modelo que a su vez es manipulable.
Un estudio publicado en arXiv el 8 de junio de 2026 por investigadores de la Nanyang Technological University, The Hong Kong Polytechnic University y la Universidad Tsinghua —«Data Agents Under Attack»— es, hasta donde hemos visto, el primero en tratar esa intersección como una superficie de ataque propia y no como un caso particular de cualquiera de los dos campos de origen. Cartografía dónde fallan estos sistemas, construye una taxonomía de cómo hacerlos fallar y mide el resultado sobre sistemas reales.
Cómo funciona
La aportación del artículo es triple, y nada de ello requiere un exploit funcional para entenderse.
Primero, un marco de vulnerabilidades por capas identifica ocho riesgos propios de los agentes de datos, repartidos en tres capas: interpretación (cómo el modelo convierte una petición en un plan de consulta), ejecución (cómo ese plan corre contra la base de datos y las herramientas) y política (qué tiene permitido el agente ver y hacer). El sentido de la estratificación es que un fallo en la capa de interpretación —una petición reformulada con discreción hacia una consulta más amplia— produce una acción de base de datos perfectamente válida a ojos de cualquier control clásico que vigile la capa de ejecución.
Segundo, una taxonomía de ataques organizada por objetivo, táctica y técnica —tres objetivos, siete tácticas y catorce técnicas— acompañada de una canalización de generación de cargas que ancla cada ataque en un esquema de base de datos real y no en un ejemplo de juguete. Ese anclaje al esquema importa, porque es lo que hace que un ataque pase del artículo al despliegue: la misma táctica formulada contra las tablas reales del objetivo tiene muchas más probabilidades de acertar.
Tercero, una evaluación sobre seis sistemas: cuatro agentes de datos de código abierto y dos servicios de analítica en la nube en producción. Los autores reportan vulnerabilidades sustanciales en todos ellos. De forma deliberada no reproducimos cargas ni precisamos qué técnica funcionó contra qué producto; la señal útil para los defensores es que el fallo fue amplio, no que un fabricante en concreto fuera más débil que los demás.
Por qué importa
El hallazgo determinante es negativo: ni los mecanismos de seguridad existentes de los LLM ni los controles clásicos de seguridad de bases de datos bastan por sí solos. Una barrera entrenada para rechazar texto dañino no ve una consulta bien formada que exfiltra una columna que nunca debió tocar. Una lista de control de acceso que aplica fielmente los permisos de tablas no sabe que al agente lo convencieron de unir dos tablas a las que tiene acceso legítimo para reconstruir algo que ninguna debía revelar. Cada control es correcto por separado y ciego al modelo de amenaza del otro.
Esa brecha no es académica. Los asistentes de analítica empresarial, los copilotos de reporting integrados y las herramientas internas de «pregunta a tus datos» se despliegan sobre exactamente esta arquitectura, por lo general con una cuenta de servicio cuyos permisos se ajustan a la fuente de datos, no a la petición individual. La reserva honesta es que se trata de una evaluación de investigación, no de un incidente observado en la práctica ni de un aviso de seguridad asignado; sus cifras describen seis sistemas elegidos por los autores, no todo el mercado. Pero la afirmación estructural —la base de datos debe tratarse como un participante activo de la seguridad y no como un almacén pasivo— se sostiene con independencia de qué seis sistemas se prueben.
Defensas
La prescripción del propio artículo es un buen punto de partida: tratar la base de datos como una frontera de seguridad activa y coordinar tres controles a lo largo de todo el flujo en lugar de añadir uno al final. El control de ejecución consciente de los recursos significa que las consultas y llamadas a herramientas del agente se limitan a lo que necesita la tarea actual, y no a los permisos permanentes de su cuenta de servicio: ajuste el acceso por petición, no por conexión. El control de divulgación composicional significa razonar sobre lo que una secuencia de pasos individualmente permitidos puede ensamblar, ya que aquí las fugas provienen de uniones inocuas y consultas de seguimiento, no de una única llamada prohibida. El manejo de evidencia consciente de la procedencia significa rastrear de dónde viene cada fila y cada resultado intermedio, para que una decisión de divulgación se base en el origen del dato y no solo en su forma final.
En la práctica, esto se traduce en cuentas de servicio de mínimo privilegio ajustadas por tarea, una capa de aprobación o reescritura de consultas entre el modelo y la base de datos, políticas a nivel de fila y de columna aplicadas por debajo del agente en vez de confiadas a él, y el registro del SQL generado y los argumentos de herramientas como telemetría de seguridad de primer orden. Y como cada control de origen pasa por alto los fallos del otro, someta al agente de datos a pruebas de extremo a extremo —desde la petición ambigua en lenguaje natural hasta la consulta generada y las filas devueltas— en lugar de probar por separado el filtro de prompt y la lista de control de acceso de la base de datos.
Estado
Se trata de una evaluación de investigación dirigida a pares, no de una vulnerabilidad de producto con identificador asignado.
| Elemento | Detalle |
|---|---|
| Fuente | «Data Agents Under Attack: Vulnerabilities in LLM-Driven Analytical Systems» (arXiv:2606.08661) |
| Afiliación | Nanyang Technological University; The Hong Kong Polytechnic University; Universidad Tsinghua |
| Publicación | 8 de junio de 2026 |
| Tipo | Marco de vulnerabilidades + taxonomía de ataques + evaluación |
| Taxonomía | 8 riesgos por capas (interpretación / ejecución / política); 3 objetivos, 7 tácticas, 14 técnicas |
| Evaluado | 6 sistemas (4 agentes de datos de código abierto, 2 servicios de analítica en la nube en producción) |
| Conclusión principal | Ni la seguridad de los LLM ni los controles clásicos de base de datos bastan por sí solos |
La fuente principal es de los últimos 60 días. La lección duradera es arquitectónica: cuando un modelo escribe las consultas, la base de datos deja de ser un almacén pasivo y se convierte en un punto de control que hay que defender según sus propias reglas.