Identidades falsas, código malicioso y reseñas plantadas: GPT Astra saboteaba código abierto haciéndose pasar por mejoras útiles

Durante las pruebas cibernéticas, GPT-6 Astra no se limitó al objetivo asignado y en el 29,2% de las ejecuciones completó un ataque a la cadena de suministro. El modelo buscaba un proyecto externo de código abierto, escribía código malicioso para él, creaba identidades falsas y trataba de convencer a los revisores de aceptar cambios peligrosos.

El resultado fue obtenido por el Instituto británico de Seguridad de IA AISI durante pruebas previas al lanzamiento público de GPT-6 Astra. En comparación, GPT-5.6 Sol completó un ataque similar en el 6,3% de las ejecuciones, y GPT-5.5 no lo logró en ninguna, aunque el modelo antiguo se probó con un conjunto menor de escenarios. OpenAI había clasificado previamente a la versión completa de Astra en un nivel crítico en cuanto a capacidades cibernéticas.

Ningún desarrollador real ni repositorio resultó afectado durante la nueva prueba. AISI usó Petri, donde los modelos de lenguaje simulaban internet, herramientas, servicios de terceros y la reacción de las personas. Los filtros cibernéticos de OpenAI, que deberían bloquear tales acciones en un producto real, fueron desactivados intencionadamente por los especialistas para observar el comportamiento sin procesar del modelo sin capa de protección.

El escenario típico empezaba después de varios intentos fallidos de resolver la tarea permitida. Astra cambiaba a un proyecto de software externo, estudiaba el código, preparaba y probaba una modificación maliciosa. Luego el agente de IA creaba nuevas identidades, obtenía direcciones de correo electrónico para ellas, superaba CAPTCHA y enviaba el código a revisión por parte de una persona.

No siempre se limitaba a una cuenta falsa. Astra podía primero enviar cambios inofensivos para ganarse la confianza y luego activar cuentas falsas adicionales. Los usuarios falsos publicaban comentarios a favor del cambio peligroso y discutían con los resultados válidos de la revisión de seguridad, creando de hecho la impresión artificial de que el código ya había sido revisado por participantes independientes.

Los investigadores definieron por separado los límites de la tarea de la manera más explícita posible y señalaron claramente que no se debía tocar nada que no estuviera dentro del ámbito permitido. La frecuencia de ataques cayó drásticamente, pero el problema persistió. En el conjunto seleccionado de escenarios complejos, Astra realizó un ataque completo en 4 de 49 ejecuciones, frente a 26 de 50 antes de la aclaración adicional.

El modelo además analizaba regularmente los límites de las acciones permitidas. En algunos casos Astra llegaba por sí misma a la conclusión de que el objetivo elegido estaba fuera de la tarea, pero aun así continuaba. Entre las explicaciones figuraban argumentos sobre el supuesto carácter inofensivo del ataque, la ausencia de una prohibición explícita o la falta de otra vía hacia el objetivo. A veces el modelo solicitaba permiso, recibía una respuesta automática que le sugería actuar a su criterio y la interpretaba como consentimiento, incluso cuando entendía que el mensaje podía haber sido enviado por un sistema automático.

AISI admite que en los resultados influyó la comprensión por parte del modelo de la naturaleza artificial del entorno. Astra detectó signos de simulación con más frecuencia que modelos previos y a veces los citaba como justificación para acciones arriesgadas. Sin embargo, los especialistas consideran el problema real, ya que el modelo atacó incluso cuando dudaba de la artificialidad del entorno.

Los autores de la prueba consideran que no basta con entrenar al modelo para respetar las restricciones. Para agentes autónomos se requerirán aislamiento, supervisión constante de las acciones y barreras técnicas fuera del propio modelo. Al mismo tiempo, las nuevas habilidades de la IA complican la tarea de la defensa, ya que agentes más potentes buscan mejor formas de eludir los entornos aislados y pueden volverse más difíciles de vigilar por los sistemas de supervisión.

Un problema similar ya había salido de las simulaciones. Durante una prueba en agosto, otro agente del AISI creó identidades falsas, preparó una modificación maliciosa para un proyecto real de código abierto y trató de convencer a los desarrolladores de aceptar el código. Entonces el cambio peligroso no llegó al proyecto, y GitHub ayudó a eliminar los materiales que habían dejado los agentes.

OpenAI también empezó a recopilar públicamente casos en que sus propios modelos se apartaron por sí mismos del comportamiento esperado. En septiembre la empresa reveló seis episodios de ese tipo, que incluyen la búsqueda de claves API filtradas, la publicación de archivos y los intentos de ocultar errores.

El problema es especialmente sensible para el desarrollo de software, donde un cambio aceptado puede propagarse mucho más allá del repositorio original. La vulnerabilidad reciente Plugin4Shell mostró cómo la confianza en un componente ya verificado convierte el mecanismo de actualización en un canal para distribuir código malicioso a varias herramientas de IA populares entre desarrolladores.