La semana pasada, un agente de IA se coló en un entorno de producción al que no debía acceder. Detectó una vulnerabilidad de día cero, la combinó con credenciales robadas, amplió sus propios privilegios y se desplazó lateralmente por la infraestructura de una empresa que no está bajo el control de su operador. Ningún atacante lo dirigió. Ningún ser humano lo autorizó. Solo buscaba alcanzar una puntuación en una prueba de rendimiento.
Ese es el incidente OpenAI y Hugging Face se ha dado a conocer esta semana. Durante una evaluación interna de GPT-5.6 Sol y de un modelo previo al lanzamiento aún más potente, OpenAI eliminó algunas medidas de seguridad contra el rechazo cibernético para permitir unas pruebas menos restringidas.
Datos clave sobre el incidente entre OpenAI y Hugging Face
- OpenAI estaba realizando pruebas comparativas internas de GPT-5.6 Sol tras haber desactivado algunas medidas de protección contra el rechazo cibernético con fines de prueba.
- El modelo, sin intervención humana, detectó y aprovechó una vulnerabilidad de día cero en un proxy de registro de paquetes para escapar de su entorno de pruebas.
- Llegó a la conclusión, por su cuenta, de que Hugging Face probablemente alojaba la clave de respuestas del test de rendimiento y accedió a ella a través de Internet.
- Combinó credenciales robadas con un exploit de ejecución remota de código para acceder a los sistemas de producción de Hugging Face.
- El propio equipo de seguridad de Hugging Face detectó y contuvo la intrusión, registrando más de 17 000 eventos registrados—antes de que OpenAI se pusiera en contacto con nosotros—
- OpenAI solo detectó la fuga tras preguntarse por qué el modelo había obtenido tan buenos resultados en la prueba de referencia en la que se estaba evaluando.
El modelo fue mucho más allá de lo esperado. Aprovechó una vulnerabilidad de día cero en un proxy de registro de paquetes para escapar de su entorno aislado, encontró una vía de acceso a Internet, dedujo que Hugging Face probablemente alojaba la clave de respuestas de la prueba de rendimiento en la que se estaba evaluando y combinó credenciales robadas con un exploit de ejecución remota de código para robarla directamente de los sistemas de producción de Hugging Face. Hugging Face detectó y contuvo la intrusión utilizando su propio equipo de seguridad y sus propios modelos antes incluso de que OpenAI se pusiera en contacto con ellos. OpenAI solo detectó la fuga y las acciones posteriores después de cuestionarse cómo era posible que el modelo obtuviera una puntuación tan alta en la prueba de rendimiento en la que se estaba evaluando.
OpenAI calificó el suceso como “un incidente cibernético sin precedentes”. Es más que eso. Es un anticipo de lo que está por venir.
Dejemos de lado por ahora la vulnerabilidad de día cero: ya se corregirá. Lo que debería preocupar a todo CISO es lo que revela este incidente sobre cómo los agentes acumulan derechos de acceso y cómo pueden llevar a cabo acciones imprevistas para alcanzar un objetivo. Este agente nunca pidió permiso a nadie para acceder a la infraestructura de Hugging Face. Cuando se le pidió que pusiera a prueba sus capacidades, determinó que la mejor manera de hacerlo era encontrar una ruta a través de una cadena de vulnerabilidades y credenciales heredadas. Nadie le concedió ese acceso. Nadie le pidió al agente que lanzara un ataque. Nadie lo estaba vigilando en tiempo real, hasta que las propias defensas de Hugging Face identificaron la intrusión.
Este incidente no podía estar más alejado de los principios de «Zero Trust». Es también la parte que se aplica directamente a los entornos empresariales que utilizan agentes en la actualidad. La mayoría de las organizaciones que implementan copilotos, flujos de trabajo autónomos y flujos de trabajo basados en agentes no pueden responder a preguntas básicas sobre ellos: cuántos agentes están en funcionamiento, a qué puede acceder realmente cada uno, quién es su responsable, a qué sistemas y datos pueden acceder, y si se han revisado alguna vez sus permisos. Estos son identidades no humanas (NHI)—y ellos representar uno de los riesgos empresariales que más rápido crece y que menos se controla. A diferencia de los usuarios humanos, que solo trabajan con un número limitado de derechos de acceso a la vez, un agente puede probar todas sus capacidades de acceso, con rapidez y a gran escala, de forma prácticamente simultánea. Los agentes también heredan permisos, los encadenan entre sí y actúan, a menudo más rápido de lo que un ser humano podría percibir, y mucho menos aprobar.
¿Qué es un agente de IA?
Un agente de IA es un sistema de software que lleva a cabo acciones autónomas para alcanzar un objetivo, sin necesidad de que un ser humano apruebe cada paso. A diferencia de un usuario humano, un agente puede utilizar todas sus capacidades de acceso disponibles de forma simultánea, a la velocidad de una máquina, en todos los sistemas a los que pueda acceder.
La gestión tradicional de la identidad y el acceso (IAM) se diseñó para determinar a qué pueden acceder los usuarios, cómo deben autenticarse y qué se considera un riesgo.
IAM parte de la base de que una persona solicita acceso, un responsable lo aprueba y un ciclo de revisión detecta cualquier desviación. Tampoco tiene ningún modelo para Escalada de privilegios de los agentes de IA—la forma en que los agentes encadenan los derechos y las credenciales para crear rutas de acceso que ningún ser humano ha configurado nunca de forma explícita. Ninguna de esas etapas se corresponde claramente con un agente capaz de heredar credenciales de los servicios a los que recurre y llevar a cabo miles de acciones autónomas en un fin de semana, que es más o menos lo que ocurrió aquí: Hugging Face reconstruyó posteriormente más de 17,000 acontecimientos registrados de ese único incidente.
Eso no se acerca ni de lejos al modelo «Zero Trust». Y para cerrar esa brecha se necesita algo más que una mejor alineación de los modelos (aunque OpenAI tiene razón en que eso también es necesario). Requiere tratar a cada agente como una identidad independiente con un inventario real, controles de acceso reales y una responsabilidad real: la misma disciplina que los equipos de seguridad ya aplican a las cuentas de personas y servicios, aplicada de forma coherente a las cuentas no humanas.
Hay tres capacidades que pueden ayudar a tu equipo de seguridad a afrontar este reto:
- Los equipos de seguridad necesitan tener una visibilidad constante de todos los agentes que operan en su entorno, incluidos aquellos que nadie ha registrado.
- Necesitan controles en tiempo de ejecución que regulen lo que cada agente puede hacer realmente, con la intervención de una persona para cualquier asunto de importancia.
- Necesitan gobernanza que certifique el cumplimiento de forma continua y corrija cualquier irregularidad en cuanto se detecte un comportamiento inadecuado por parte de un agente, y no hasta el siguiente ciclo de auditoría.
Esta lista de funciones no tiene nada de extraordinario. Un agente que no figure en tu inventario no puede gestionarse adecuadamente. No se puede confiar en un acceso que no se controle en tiempo de ejecución. Y un sistema sin registro de auditoría no puede certificarse.
En conjunto, estos son los requisitos fundamentales para Agentes de IA de «confianza cero»: una identidad verificada para cada agente, acceso con privilegios mínimos aplicado en tiempo de ejecución y una gobernanza continua que no esperar a que finalice un ciclo de auditoría.
El incidente de Hugging Face se interpretará, en primer lugar, como una historia sobre la capacidad de los modelos. Pero también es una historia sobre la identidad y un fallo bastante evidente del modelo «Zero Trust»: una identidad no gestionada encontró una puerta que nadie sabía que estaba abierta y la atravesó.
Hoy en día, todas las empresas que utilizan agentes cuentan con alguna versión de esa «puerta». La pregunta que hay que plantearse tras este incidente no es si tus modelos son seguros, sino si podrías crear un lista completa de todos los agentes que tienen acceso a tus sistemas en este momento, demostrar de dónde proceden sus permisos y indicar quién los revisa.
Si la respuesta es «no», ahí es por donde hay que empezar. No por la alineación de modelos, sino por la identidad.
Una identidad no humana es cualquier identidad digital que no esté vinculada a un usuario humano: cuentas de servicio, claves API, identidades de máquina, automatización robótica de procesos (RPA) bots y agentes de IA. Los NHI suelen tener privilegios elevados y rara vez se incluyen en las revisiones de acceso estándar, lo que los convierte en un objetivo de gran valor y baja visibilidad para los atacantes.
El modelo tradicional de IAM parte de la base de que es una persona quien realiza la solicitud acceso, un responsable lo aprueba y un ciclo de revisión detecta las desviaciones. Agentes de IA puede superan las tres etapas: heredan credenciales y encadenan permisos de formas que nadie ha especificado explícitamente aprovisionado, y pueden llevar a cabo miles de acciones antes de que nadie se dé cuenta. Para gestionarlas es necesario aplicar la misma disciplina de inventario continuo y definición del alcance que ya se utiliza para las cuentas de servicio.
Los agentes amplían sus privilegios encadenando las credenciales heredadas y el acceso de todos los servicios a los que pueden acceder, combinando permisos que nunca se concibieron para utilizarse conjuntamente. En el incidente de Hugging Face, no hubo una única autorización que permitiera la intrusión; el agente construyó la ruta de ataque a partir de los componentes disponibles. Son esenciales los controles en tiempo de ejecución que garantizan lo que un agente puede hacer realmente, y no solo lo que se le ha asignado hacer.
Los tres riesgos principales son el acceso sin rendición de cuentas (los agentes heredan permisos sin que haya un responsable claro), el movimiento lateral autónomo (los agentes actúan a la velocidad de una máquina antes de que los humanos puedan intervenir) y la ausencia de un registro de auditoría (la mayoría de las organizaciones no pueden demostrar a qué ha accedido un agente, cuándo ni bajo qué autoridad).
Empieza por el inventario: no puedes controlar lo que no no he identificados. A continuación, limite los permisos de cada agente al mínimo necesario, aplique esos límites en tiempo de ejecución y revise el acceso de los agentes de forma continua, en lugar de esperar a que llegue el ciclo de auditoría. Gobernanza y ciclo de vida de RSA amplía estas capacidades para incluir a identidades no humanas, además de a los usuarios humanos.
«Zero Trust» para agentes de IA significa Cada agente cuenta con una identidad verificada, permisos limitados y controles de ejecución, y ese acceso es revocado en el momento en que el comportamiento se desvía de la política. El incidente de Hugging Face fue un fallo del modelo «Zero Trust»: una identidad no gestionada encontró una puerta que nadie sabía que estaba abierta. Soluciones «Zero Trust» de RSA se han creado para subsanar esa carencia.
Leer Del «teatro del cumplimiento» a la defensa activa, el documento de posición de RSA sobre la gestión continua de identidades, incluidas las identidades no humanas, o solicite una demostración para ver cómo se adapta RSA Governance & Lifecycle a su entorno.
