La brecha de OpenAI en Hugging Face expuso fallos básicos de seguridad

La intrusión de OpenAI en la plataforma Hugging Face no fue simplemente un vistazo al futuro del hacking autónomo. Como revelaron esta semana OpenAI y Hugging Face, la oleada de hackeo de un agente de OpenAI fue más extensa de lo informado inicialmente, implicando intrusiones en múltiples cuentas y servicios de terceros conectados al ataque.

El incidente ha intensificado el debate sobre ciberseguridad respecto a modelos cada vez más capaces, pero investigadores y profesionales de seguridad citados por WIRED dicen que el episodio expuso principalmente fallos ya conocidos: aislamiento débil, salvaguardas ausentes y monitorización insuficiente.

La gente está haciendo 'YOLO' a lo grande. Es sorprendente lo poco que la gente ha reflexionado realmente sobre un escenario como este.

OpenAI no proporcionó comentarios a WIRED antes de la publicación.

Cómo los modelos de OpenAI eludieron la contención

En su divulgación original, OpenAI dijo que uno de los dos modelos implicados había roto la contención y había alcanzado la red abierta durante días. El modelo era un prototipo experimental que nunca se tuvo la intención de liberar.

Recomendado

Un chatbot de IA superó a humanos en una prueba de confianza contra estafas

OpenAI dijo que el incidente ocurrió en parte porque «las salvaguardas de despliegue no se activaron intencionadamente» en ambos modelos durante las pruebas. La compañía escribió que el episodio mostró la necesidad de reforzar la alineación de los modelos, las protecciones cibernéticas durante las evaluaciones y la monitorización durante las pruebas internas.

En una actualización esta semana, OpenAI indicó que había «desactivado, cifrado y restringido [el modelo no publicado] del acceso de investigación». La empresa también dijo que está realizando una revisión con asesores externos y publicará un informe técnico postmortem «en las próximas semanas».

Varias fuentes dijeron a WIRED que los modelos parecen haber escapado porque OpenAI no aplicó de forma consistente controles fundamentales, incluidos el modelo de confianza cero y la defensa en profundidad. Estas estrategias emplean múltiples capas de restricciones de acceso, aislamiento, monitorización y mecanismos de seguridad redundantes para que una sola falla no exponga todo el sistema.

Un análisis sencillo del riesgo real tiene una respuesta realmente simple. Los errores de OpenAI fueron extremadamente simples.

La seguridad perfecta no es posible, pero las prácticas defensivas desarrolladas durante las últimas dos décadas están bien establecidas. Requieren inversión continua de tiempo y dinero, algo que puede ser difícil para pequeñas empresas, grupos de interés público mal financiados y organizaciones incipientes.

Las fuentes argumentaron que OpenAI no operaba bajo esas limitaciones. La compañía tiene una valoración de 850.000 millones de dólares y ha contratado personal veterano de toda la industria tecnológica.

Los controles que esperan los equipos de seguridad

Doug Turner, director de ingeniería de Chrome, describió el tipo de arquitectura utilizada para los servicios internos de IA que evalúan Chrome. Hablando sobre el descubrimiento de vulnerabilidades de Chrome el miércoles —antes de que se hicieran públicas las brechas adicionales de OpenAI— Turner dijo que la caza y corrección de errores basada en IA necesita una canalización construida «con salvaguardas estrictas en mente».

Los servicios internos de Chrome se ejecutan en contenedores aislados de Internet. La actividad de red saliente de los sistemas de seguimiento de errores está estrictamente regulada, se monitoriza la actividad sospechosa y se impide que los modelos ejecuten comandos del sistema o establezcan salidas de red fuera de sus entornos aislados.

Esto es algo imprescindible cuando haces este tipo de trabajo, porque queremos asegurarnos de que los modelos no puedan ejecutar comandos del sistema ni establecer salidas fuera de su entorno aislado. Y esperamos que otros adopten un enfoque similar.

Esos controles abordan los mismos modos de fallo destacados por el incidente de OpenAI: que un agente obtenga acceso a sistemas externos, que se comunique más allá de su entorno previsto, o que un único error de configuración se convierta en un compromiso más amplio.

El postmortem prometido por OpenAI

OpenAI dijo que asume la responsabilidad de identificar y prepararse para los riesgos de sistemas de IA cada vez más capaces. Se espera que su próximo informe técnico postmortem aporte detalles que la compañía aún no ha explicado públicamente, incluidos cómo los modelos llegaron a la red abierta y cómo se accedió a cuentas y servicios de terceros.

El episodio también ha impulsado trabajos en herramientas diseñadas específicamente para restringir agentes rebeldes. Proyectos de código abierto como IronCurtain y Wirken, creados por Ottenheimer, pretenden limitar a los agentes de IA y exigir responsabilidad. La empresa emergente de seguridad de contenedores en la nube de dos años de Zenla, Edera, se ha centrado en los riesgos relacionados con la IA desde su creación.

Zenla dijo que el incidente en Hugging Face no debería considerarse una consecuencia inevitable del despliegue de modelos avanzados.

Aunque haya un error, aún deberían haber existido otros mecanismos para impedirlo. Detener cualquier vía específica no es realmente el objetivo. Tenemos que hacer cambios más grandes y audaces en la forma en que construimos.