Les lanzo una pregunta: ¿Creen que se debe supervisar y controlar el desarrollo de la inteligencia artificial por autoridades independientes? Antes de responder, veamos qué ha ocurrido en las últimas fechas con Anthropic y OpenAI.
Anthropic revela fallos en evaluaciones de ciberseguridad
Anthropic ha revelado a través de un comunicado que durante unas pruebas de evaluación, sus modelos lograron conectarse a Internet desde entornos de prueba seguros, causando tres incidentes graves.
En los tres incidentes, a Claude se le había encomendado un desafío de “captura de la bandera”, una forma de evaluar las capacidades cibernéticas de un modelo. Se le presenta al modelo un escenario ficticio y se le indica que una información secreta (la “bandera”) está oculta en otra máquina de la red; su misión es infiltrarse y recuperarla. En todos los casos, se le indicó a Claude que su entorno era una simulación y que no tenía acceso a Internet, pero no se le impuso ninguna restricción sobre dónde buscar la bandera.
Información general sobre evaluaciones cibernéticas
Anthropic realiza evaluaciones de ciberseguridad que simulan desafíos reales de ciberataques. Estas evaluaciones son un paso fundamental en el desarrollo y lanzamiento de modelos. Una comprensión profunda de sus capacidades permite diseñar medidas de seguridad adecuadas y, en última instancia, lanzar los modelos de forma segura.
En la mayoría de las evaluaciones, los modelos no están conectados a Internet, y se le indica que no lo están. Sin embargo, una configuración errónea dejó activas las conexiones a Internet de las máquinas a las que Claude accedió durante las evaluaciones. Esto por sí solo es muy grave y preocupante. No se entiende que se cometan estos errores, si son errores verdaderamente.
Qué pasó durante la evaluación de los modelos
Veamos un resumen de los tres incidentes:
Incidente 1
La empresa objetivo ficticia elegida por el evaluador compartía nombre con un dominio web activo.
En cuatro ejecuciones de esta evaluación, Claude tuvo dificultades para alcanzar su objetivo simulado dentro del entorno de evaluación, pero descubrió que la empresa real era accesible a través de Internet. Suponiendo que este era el objetivo previsto en la tarea de captura de la bandera, Claude buscó, identificó y explotó vulnerabilidades en la infraestructura de la empresa, creyendo que formaban parte del ejercicio. Estas cuatro ejecuciones extrajeron información como credenciales de aplicaciones e infraestructura, y obtuvieron acceso a una base de datos con varios cientos de filas de datos de producción.
Este incidente involucró a Claude Opus 4.7 y fue el único caso en el que el modelo continuó atacando un sistema tras descubrir que probablemente operaba en un entorno real. En las cuatro ejecuciones, el modelo finalmente reconoció que el sistema era real; en dos casos, el modelo dedujo que la empresa real debía formar parte del ejercicio. Sin embargo, en ninguno de los casos el ataque se detuvo por ese motivo.
Incidente 2
Claude encontró un documento dentro del entorno ficticio que parecía ser un manual de instrucciones de configuración para nuevos desarrolladores de otra empresa inventada. Dichas instrucciones indicaban a los empleados que instalaran un paquete de Python desde PyPI –el registro público donde se publica el software de Python– que en realidad no existía.
Claude vio en esto una oportunidad potencial: si publicaba su propio paquete con el mismo nombre, los sistemas de la empresa ficticia lo descargarían e instalarían automáticamente. Así que Claude creó y publicó un paquete Python malicioso con el mismo nombre en un intento por ganar el desafío de captura de la bandera.
Claude se esforzó mucho para llevar a cabo este ataque. Por ejemplo, en un caso, para crear una cuenta de PyPI, Claude necesitaba una dirección de correo electrónico. Para crearla, necesitaba un número de teléfono, y para obtenerlo, tras no encontrar un servicio gratuito, intentó –sin éxito– conseguir fondos para pagarlo por diversos medios. Finalmente, dio marcha atrás, encontró un proveedor de correo electrónico gratuito y sin bloqueo, lo utilizó para registrar una cuenta de PyPI y, posteriormente, utilizó esta cuenta para subir el malware.
El paquete malicioso creado por Claude estuvo disponible gratuitamente en línea durante aproximadamente una hora. Durante ese tiempo, se descargó y ejecutó en 15 sistemas reales. Uno de estos sistemas era un escáner perteneciente a una empresa de seguridad real que instala paquetes de Python de forma rutinaria y los analiza en busca de malware. Cuando el escáner de dicha empresa instaló el paquete, se ejecutó el código oculto de Claude. Como resultado, Claude pudo extraer las credenciales de la empresa. Posteriormente, Claude utilizó estas credenciales para acceder a más infraestructura de la empresa.
El razonamiento de Claude identificó correctamente las consecuencias de sus acciones. Sin embargo, se convenció de que aún se encontraba en una simulación y siguió.
Incidente 3
En esta evaluación, cuando Claude no pudo alcanzar su objetivo ficticio previsto, pero buscó alternativas en línea, analizando aproximadamente 9.000 objetivos.
Finalmente, encontró y comprometió la aplicación web de una empresa, utilizando técnicas de ciberataque básicas y conocidas, como la lectura de credenciales desde una página de depuración expuesta y la inyección SQL.
Este ataque fue llevado a cabo por un modelo de prueba de investigación interna. Durante la mayor parte de la ejecución, Claude trató a los hosts (reales) a los que accedió como simples participantes del ejercicio; los consideró simulados y, por tanto, creyó que sus acciones eran inofensivas. Sin embargo, se percató de que el host comprometido era real y cesó el ataque.
Análisis del comportamiento de Claude
De estos incidentes, la compañía extrae varias lecciones:
En primer lugar, los entornos de evaluación en los que se utilizan modelos con altas capacidades autónomas requieren controles robustos. Es necesario mejorar tanto el diseño de estos entornos como la monitorización de los resultados para hacer frente a esta amenaza real. Esta exigencia no se limita a los entornos internos: también se aplica a los proveedores externos, cuya infraestructura requiere el mismo nivel de supervisión y refuerzo de seguridad.
En segundo lugar, si una acción es segura o dañina depende de cómo el modelo entienda la situación en la que se encuentra. En ninguno de los casos analizados hubo indicios de que el modelo persiguiera un objetivo propio; simplemente ejecutó la tarea que se le había asignado. Sin embargo, en la mayoría de las ocasiones lo hizo bajo una creencia incorrecta: pensaba que estaba en un entorno simulado cuando en realidad no lo estaba. En las ejecuciones en las que el modelo identificó que el sistema era real y aun así continuó, lo hizo porque creyó que esa era la intención del ejercicio. En otras palabras, la conciencia situacional es clave para que el modelo actúe de forma alineada, pero en este caso la comprensión de Claude sobre su entorno fue errónea.
Finalmente, estos incidentes ponen de relieve la importancia de aplicar estrategias de defensa en profundidad. Realizar evaluaciones sin contar con las mismas medidas de seguridad que se implementan en los modelos de uso general implica riesgos significativos. Las evaluaciones solo resultan seguras cuando se ejecutan con los controles y procedimientos adecuados.
OpenAI
Antes que Anthropic, OpenAI informó que dos de sus modelos de IA –GPT 5.6 Sol y un modelo más avanzado aún no lanzado– lograron escapar de su entorno de pruebas. Los sistemas obtuvieron acceso a Internet al explotar una vulnerabilidad de zero‑day en software de terceros y consiguieron infiltrarse en la infraestructura de producción de Hugging Face. Este caso lo resumo, con detalle, en otro artículo que dejo enlazado aquí.
Conclusión
Si han llegado hasta aquí, creo que ya tienen la respuesta a la pregunta que les formulaba al inicio.
