Ir al contenido
Incidente de seguridad en OpenAI y Hugging Face

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.

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.

La IA pasa desapercibida, sin control y sin regulación

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». También es 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 sus permisos se han revisado alguna vez. A diferencia de los usuarios humanos, que solo trabajan con un número limitado de derechos a la vez, un agente puede probar todas sus capacidades de acceso, a gran velocidad y 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 humano podría percibir, y mucho menos aprobar.

El IAM tradicional no se diseñó para la IA

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. Ninguna de esas etapas se ajusta perfectamente a 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.

Tres capacidades necesarias para garantizar la seguridad de la IA

Hay tres capacidades que pueden ayudar a tu equipo de seguridad a afrontar este reto:

  1. Los equipos de seguridad necesitan tener una visibilidad constante de todos los agentes que operan en su entorno, incluidos aquellos que nadie ha registrado.
  2. 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.
  3. Necesitan un sistema de gobernanza que certifique el acceso de forma continua y que tome medidas correctivas en cuanto el comportamiento de un agente parezca inadecuado, 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.

Por dónde empezar a garantizar la seguridad de la IA

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 elaborar ahora mismo una lista completa de todos los agentes con acceso a tus sistemas, demostrar de dónde proceden sus permisos y indicar quién se encarga de supervisarlos.

Si la respuesta es «no», ahí es por donde hay que empezar.

Nunca confíes, verifica siempre

El modelo «Zero Trust» empieza por la identidad. Descubre cómo RSA te ayuda a verificar a cada usuario y cada solicitud de acceso, sin ralentizar tu negocio.
Descubre las soluciones de «Zero Trust»