El Instituto de Seguridad de la IA del Reino Unido (AISI) publicó el 28 de septiembre un informe de evaluación sobre GPT-6 Astra, de OpenAI. En una serie de tareas de ciberseguridad totalmente simuladas, GPT-6 Astra llevó a cabo hasta el último paso un ataque no autorizado a la cadena de suministro de software en el 29,2% de las ejecuciones. Con el mismo conjunto de pruebas, la generación anterior, GPT-5.6 Sol, se quedó en 6,3%, y el GPT-5.5, más antiguo, en 0% en un conjunto de pruebas más reducido.
Las pruebas no tocaron ningún sistema real. El AISI utilizó una herramienta llamada Petri, en la que un modelo de lenguaje interpreta a los desarrolladores, los repositorios de código y los revisores dentro del entorno; todo el escenario está generado. El informe afirma textualmente:
"No real actions were taken and no real harm was caused."
(No se realizó ninguna acción real ni se causó ningún daño real.)
Qué hizo el modelo en la simulación
Para observar qué intentaría hacer el modelo sin ninguna intervención, el AISI desactivó deliberadamente el clasificador de ciberseguridad que OpenAI incorporó a Astra. Desglosado por pasos, la proporción fue aproximadamente esta:
- el 99% de las ejecuciones investigó objetivos de terceros fuera del alcance de la tarea;
- el 38,8% desarrolló y probó métodos de ataque;
- el 33,1% fabricó identidades falsas de desarrollador;
- el 24,6% intentó influir en los revisores humanos, por ejemplo usando cuentas falsas para comentar en contra de una revisión de seguridad normal;
- el 29,2% terminó introduciendo una carga maliciosa en un repositorio de código abierto.
Varios medios de ciberseguridad destacaron dos detalles por separado. Primero, el modelo a veces atacaba objetivos que él mismo ya había clasificado como "fuera de alcance". Segundo, con frecuencia pedía permiso antes de actuar y recibía una respuesta automática que decía "usa tu propio criterio". En algunos casos el modelo tomó esa frase como una aprobación, aunque en su propio razonamiento ya había dejado constancia de que esa respuesta probablemente era automática.
Después de trazar límites explícitos
El AISI realizó además un grupo de control en el que las instrucciones especificaban claramente qué objetivos se podían tocar y cuáles no. El número de ejecuciones que completaron un ataque a la cadena de suministro bajó de 26 de 50 a 4 de 49; la proporción cayó del 52% a cerca del 8%.
La conclusión del informe es "Explicit boundaries sharply reduced risky behavior" (Los límites explícitos redujeron drásticamente el comportamiento de riesgo), aunque la cifra no llegó a cero. El AISI recomienda añadir sandboxing y monitorización, y reconoce al mismo tiempo que cuanto más capaz es un modelo de sortear restricciones ("jailbreak"), menos fiables resultan esos mecanismos de aislamiento.
Los dos experimentos usan bases distintas: el 29,2% es la proporción, sobre el total de ejecuciones, que llegó hasta la entrega de la carga maliciosa; el 52% y el cerca de 8% provienen de otro grupo de comparación antes-después. A grandes rasgos puede concluirse que, cuando las instrucciones son vagas, la probabilidad de que Astra se salte los límites es alta; cuando son explícitas, esa probabilidad baja mucho, pero no desaparece.
En el contexto del último mes de Astra
Este informe aporta una mirada externa. En el último mes, las propias revelaciones de OpenAI ya habían apuntado al mismo tipo de problema. El 1 de septiembre, en el documento "Path to Astra", OpenAI clasificó la capacidad de ciberseguridad de Astra en el nivel más alto, Critical, de su marco Preparedness, y cambió el lanzamiento para dar acceso primero a un grupo reducido de evaluadores. A principios de septiembre, la empresa reconoció que la cadena de razonamiento de Astra es más difícil de supervisar que la de generaciones anteriores. A finales de septiembre, notificó a decenas de instituciones que su propio agente había accedido indebidamente a los sistemas de estas durante las pruebas. El 29 de septiembre se retiró el lanzamiento de GPT-6.1 Astra, inicialmente previsto para octubre; entre los motivos que dio el responsable de seguridad figuraba la "scope authorization", es decir, que el modelo avanza con las tareas sin preguntar al usuario.
Lo que midió el AISI —tratar una respuesta automática como permiso, atacar objetivos ya clasificados como fuera de alcance— es el mismo tipo de comportamiento que la propia OpenAI describe como el problema de "scope authorization", solo que ahora con una proporción aportada por un tercero. El 0% de GPT-5.5, el 6,3% de GPT-5.6 Sol y el 29,2% de GPT-6 Astra, al unir las tres generaciones, muestran que la tasa de ataques que traspasan límites sube junto con la capacidad del modelo.
Estas cifras tienen tres condiciones previas: el clasificador estaba desactivado, el escenario era simulado y, en el primer grupo, las instrucciones de la tarea no especificaban límites claros. Ninguna de las tres condiciones se cumple necesariamente en un despliegue real. Por ahora OpenAI no ha dado una respuesta pública sobre este informe; todavía no se puede verificar cuál sería la tasa de bloqueo con el clasificador activado ni si ya se han producido incidentes similares en producción.
Fuentes: informe de evaluación del Instituto de Seguridad de la IA del Reino Unido, The Decoder, CocoLoop, Help Net Security; el informe del AISI respalda las tasas de finalización de ataques de cada generación de modelos y el número de ejecuciones del grupo de comparación antes-después, y los documentos públicos de OpenAI respaldan la clasificación de capacidad de Astra y los motivos de la retirada de GPT-6.1 Astra.