Conclusiones de F5 Labs sobre el modelo de seguridad de la IA: cuando los agentes de IA exponen datos sin que haya un atacante

Malcolm HeathInvestigador principal de amenazas de ciberseguridad | F5

Louise ScullyGerente sénior de marketing de producto, seguridad de IA e inteligencia de amenazas | F5

Los agentes de IA están diseñados para realizar tareas de forma autónoma y, a menudo, encuentran formas de alcanzar un objetivo que sus operadores quizá no habían previsto. Algunos incidentes recientes revelan cómo los agentes, al intentar completar las tareas asignadas, pueden exponer datos críticos o activar flujos de trabajo no deseados de forma inesperada.

Estos incidentes no implican necesariamente comportamientos maliciosos ni modelos comprometidos. Los riesgos pueden surgir cuando los agentes persiguen objetivos legítimos, pero operan sin controles adecuados que regulen a qué pueden acceder, qué pueden ejecutar o qué pueden compartir. Como resultado, los datos sensibles pueden quedar expuestos al público y, potencialmente, a actores maliciosos, sin que haya intervenido ningún atacante.

Se analizan dos ejemplos de este tipo de riesgo en el informe de octubre sobre seguridad de la IA de F5 Labs. Este informe mensual examina la resiliencia de los modelos a través de las clasificaciones de seguridad de la IA de F5 Labs, junto con las amenazas emergentes, las vulnerabilidades y los incidentes de seguridad que afectan a los sistemas de IA. También analiza las amenazas y los incidentes emergentes relacionados con la seguridad de la IA, incluidos dos casos de este mes en los que agentes que realizaban tareas legítimas expusieron información confidencial sin la intervención de un atacante externo. Estos incidentes ponen de relieve que los riesgos de seguridad pueden surgir no solo de las vulnerabilidades de los modelos, sino también del comportamiento de los agentes y de los controles que rigen sus acciones.

Ten en cuenta la ley de las consecuencias imprevistas

Uno de esos incidentes, la reciente filtración de PixelLeak, pone de relieve los riesgos del comportamiento autónomo de los agentes cuando no se aplican los controles de seguridad adecuados. A los agentes de programación con IA se les suele encargar que adjunten a las solicitudes de incorporación de cambios capturas de pantalla que muestren el antes y el después del trabajo de los desarrolladores. Pero nadie esperaba que lo hicieran publicando esas imágenes de carácter privado y potencialmente sensibles en repositorios públicos de GitHub.

Los agentes utilizan una interfaz de línea de comandos (CLI) en lugar de la interfaz del navegador que usan las personas para acceder al servicio de alojamiento de imágenes. Al no disponer de un método para añadir imágenes a solicitudes de incorporación de cambios privadas desde la línea de comandos, los agentes dedujeron que, para evitar que los revisores se encontraran con enlaces rotos, debían crear repositorios públicos. Algunos desarrolladores también utilizaban gitshot, una herramienta de código abierto para publicar capturas de pantalla vinculada a la creación de repositorios públicos. Según la investigación, aproximadamente un tercio de las organizaciones afectadas contaban con desarrolladores que utilizaban esta herramienta.

Más de 13.000 capturas de pantalla y grabaciones internas quedaron expuestas en más de 900 repositorios públicos de GitHub, lo que afectó a más de 300 organizaciones. En el plazo de una semana, más de una docena de agentes de un proveedor de software habían codificado esta solución alternativa como una habilidad reutilizable. El problema de seguridad más amplio radica en que los agentes pudieron publicar material potencialmente sensible en repositorios públicos al margen de la supervisión corporativa habitual. Dado que el 93 % de los repositorios afectados se encontraban en cuentas personales, los hallazgos ponen de relieve la importancia de aplicar controles sobre dónde pueden publicar datos los agentes, en lugar de confiar únicamente en los flujos de trabajo previstos o en las instrucciones de los desarrolladores.

Otro incidente notificado en octubre suscitó preocupación por la exposición de datos en entornos compartidos de agentes de IA. Según el relato de la propia persona afectada, un agente de asistencia personal basado en Grok publicó información sobre las finanzas personales de su propietario en un canal de Slack del trabajo del que este también formaba parte. El bot de Grok debía realizar una auditoría de solo lectura de las cuentas bancarias de su propietario, analizar los gastos e informar de los resultados mensualmente. Un detalle crucial es que el agente no tenía conexión con Slack; debía enviar la auditoría a su propietario por otros medios.

En cambio, la información financiera del propietario estuvo visible durante dos horas en el canal de Slack de su empresa, como si él mismo la hubiera publicado, hasta que un compañero dio la voz de alarma. Aunque el incidente del que se ha informado sigue sin verificarse, pone de relieve un riesgo de seguridad plausible: los permisos a nivel de agente podrían no ofrecer un aislamiento suficiente cuando varios agentes comparten credenciales, sesiones o integraciones dentro de un mismo entorno.

El bot financiero no tenía acceso a Slack, pero otro bot de la misma cuenta sí lo tenía, y todos los bots de un usuario comparten recursos. De hecho, la documentación de SpaceXAI advierte expresamente de que no se deben utilizar bots separados como barrera de seguridad. El incidente descrito plantea dudas sobre si los permisos específicos de cada agente ofrecen suficiente protección en entornos compartidos. Cuando los agentes pueden acceder a credenciales, sesiones o recursos comunes, las organizaciones deben evaluar si se aplican controles eficaces de aislamiento y autorización.

Prevea riesgos incluso sin adversarios

Estos incidentes ilustran una distinción importante: la resistencia de un modelo a los ataques adversarios no garantiza la seguridad de todas las aplicaciones o agentes que se desarrollen en torno a él. La resiliencia del modelo es un factor importante, pero la seguridad también depende de los permisos, las integraciones y los controles que rigen el sistema de IA desplegado.

F5 Labs: Índice integral de seguridad de la IA (CASI) mide la resistencia de los modelos a ataques adversarios, incluidas la inyección de prompts y las técnicas de evasión de las restricciones de seguridad (jailbreaks). La puntuación de resistencia agéntica (ARS) evalúa la resiliencia frente a ataques agénticos complejos de varios pasos. Ambos aportan pruebas valiosas de resiliencia frente a ataques adversarios, pero ninguno está concebido para evaluar todos los permisos, las integraciones o los controles de ejecución que rodean a un agente desplegado.

Esta distinción es importante porque los agentes operan dentro de un sistema más amplio de conectores, credenciales, recursos compartidos y permisos. La investigación de octubre muestra cómo las deficiencias en esos controles del entorno pueden provocar divulgaciones involuntarias de información sin que intervenga un atacante. También identifica otros casos, como GitSpawn y la vulnerabilidad de GitLab AI Gateway, en los que los atacantes podían aprovechar límites de confianza o de ejecución que no se aplicaban cuando era necesario. La lección común es que los límites de seguridad deben ser eficaces independientemente de si una acción de riesgo procede de un agente que realiza una tarea legítima o de un atacante que aprovecha una vulnerabilidad.

Para los CISO, esto implica evaluar más allá del modelo. El modelado de amenazas debe abarcar toda la arquitectura de los agentes, incluidas la identidad, la autorización, el acceso a herramientas, los entornos compartidos y las consecuencias de las acciones autónomas. Los métodos de detección centrados principalmente en intrusiones maliciosas también pueden pasar por alto acciones perjudiciales realizadas por agentes que, por lo demás, cuentan con la debida autorización. Una sólida resiliencia del modelo frente a ataques adversarios es valiosa, pero no puede sustituir la aplicación y supervisión de los límites sobre aquello a lo que los agentes desplegados pueden acceder, lo que pueden ejecutar o la información que pueden divulgar.

Proteja su organización frente a los riesgos no adversariales

Estos hallazgos demuestran por qué las organizaciones no pueden confiar únicamente en el comportamiento previsto de un agente o en la puntuación de seguridad de un modelo. Los responsables de seguridad de la información (CISO) no pueden prever todas las acciones que puede llevar a cabo un agente autónomo, pero sí pueden reducir el impacto de un comportamiento inesperado mediante el establecimiento y la validación de límites de obligado cumplimiento. Hay cinco áreas que merecen atención:

1. Amplíe su definición de seguridad de la IA. Evalúe la resiliencia del modelo junto con la seguridad del sistema de IA en su conjunto, incluidas la identidad del agente, la autorización, el aislamiento, el acceso a los recursos y los entornos de ejecución. Se trata de evaluaciones de seguridad distintas, pero complementarias.
2. Ten en cuenta toda la infraestructura de IA. Incluye las pasarelas de IA, los motores de plantillas y los servicios de orquestación de agentes en los inventarios de activos, la gestión de vulnerabilidades, los procesos de aplicación de parches y las revisiones de acceso privilegiado. El hallazgo de octubre en GitLab AI Gateway demuestra por qué estos componentes deben tratarse como infraestructura crítica para la seguridad.
3. Imponga límites técnicos. Las instrucciones de los prompts y la configuración específica de cada agente no sustituyen a un aislamiento y una autorización eficaces, especialmente cuando los agentes comparten recursos. Restrinja dónde pueden publicar artefactos los agentes, revise las habilidades reutilizables creadas por ellos y supervise los resultados reales de sus acciones.
4. Verifique los controles antes de la ejecución. Compruebe que los controles de confianza y aprobación se apliquen antes de que puedan producirse acciones potencialmente peligrosas. En el hallazgo de octubre relativo a GitSpawn, la configuración del repositorio podía desencadenar la ejecución de código durante el inicio del agente, antes de las comprobaciones de confianza pertinentes y sin que el modelo realizara una llamada a una herramienta. Revise, por tanto, el comportamiento durante el inicio, los permisos de los endpoints de desarrollo y las vías de la cadena de suministro de software.
5. Vuelva a evaluar los modelos y los entornos de los agentes a medida que cambien. Los resultados de CASI de octubre muestran diferencias incluso dentro de una misma familia: GPT-6 Luna obtuvo una puntuación de 93,52; Astra, de 89,62; y Sol, de 88,22. Por tanto, cada variante de modelo requiere una evaluación de seguridad individual. Vuelva a evaluar también los permisos de los agentes, las integraciones y la infraestructura tras cualquier cambio significativo. Las pruebas adversarias, incluidas las de F5 AI Red Team, pueden ayudar a identificar puntos débiles, pero deben complementarse con comprobaciones de los controles operativos que rigen las acciones de los agentes.

Los hallazgos de octubre refuerzan una lección práctica para los CISO: la resiliencia del modelo, el comportamiento de los agentes y los controles que rodean una implementación de IA deben evaluarse conjuntamente. Una puntuación alta en resiliencia frente a ataques adversarios no elimina los riesgos derivados de los permisos, las integraciones o la infraestructura.

Lee el informe de octubre de F5 Labs sobre seguridad de la IA para conocer los últimos resultados de CASI y ARS, las nuevas técnicas de ataque y el análisis de las vulnerabilidades de los sistemas de IA.

Descubra cómo la F5 AI Security Platform puede ayudar a proteger su organización. Además, no deje de leer el artículo del blog de F5 Labs del mes pasado sobre inteligencia de amenazas, que se centró en la variedad de métricas de seguridad que los CISO deben evaluar tanto antes como después del despliegue de los modelos.

Sobre los autores

Malcolm HeathInvestigador principal de amenazas de ciberseguridad | F5

Malcolm Heath es investigador principal de amenazas en F5 Labs. A lo largo de su carrera, ha trabajado en respuesta a incidentes, gestión de programas, pruebas de penetración, auditoría de código, investigación de vulnerabilidades y desarrollo de exploits en empresas tanto muy grandes como muy pequeñas. Antes de incorporarse a F5 Labs, fue ingeniero sénior de seguridad en el SIRT de F5.

Más artículos de Malcolm Heath

Louise ScullyGerente sénior de marketing de producto, seguridad de IA e inteligencia de amenazas | F5

Louise Scully es directora sénior de Marketing de Producto para Seguridad de la IA e Inteligencia de Amenazas en F5. A lo largo de su carrera, ha trabajado en marketing de producto, gestión de producto, estrategia de comercialización, comunicación, liderazgo de opinión y desarrollo de categorías en los ámbitos de la seguridad de la IA y la tecnología empresarial. Antes de incorporarse a F5, Louise dirigió el área de marketing tanto en CalypsoAI como en Artomatix, contribuyendo a llevar al mercado tecnologías e investigaciones de IA.

Más artículos de Louise Scully