GPT-6 Cyber: cómo interpretar las pruebas y verificar las correcciones

OpenAI presentó GPT-6 Cyber el 5 de noviembre de 2026, inicialmente para determinados clientes de Daybreak Red mediante API y Codex. La pregunta práctica es cómo convertir los hallazgos en correcciones revisadas que lleguen a los usuarios.

Qué se ha publicado

La ficha del sistema lo describe como una variante de GPT-6 Astra especializada en investigación de seguridad autorizada. El acceso está restringido. El anuncio no garantiza disponibilidad para cualquier cuenta API; aquí no se inventa un identificador de modelo ni una llamada al SDK.

Qué significan los resultados

ExploitGym pasa del 32.1% al 48.5%: son 16.4 puntos porcentuales y aproximadamente un 51.1% de mejora relativa. Explotar una vulnerabilidad indicada y descubrir un fallo desconocido son tareas distintas.

La evaluación web sin código fuente comunica una recuperación del 40.3%, frente al 32.0% de Astra. Esa cifra no explica la carga de falsos positivos. Antes de estimar personal, conviene preguntar por objetivos, presupuesto de herramientas, reintentos, intervención humana y coste por hallazgo aceptado; este sitio no ha reproducido las pruebas del proveedor.

Linux y Firefox: seguir las pruebas

El informe de Linux distingue 2,308 candidatos, 1,724 vulnerabilidades reproducidas y 948 exploits funcionales de escalada local de privilegios. Una sospecha y una frontera de permisos cruzada no tienen el mismo peso probatorio. La escalada local exige acceso previo y no equivale a ejecución remota.

La campaña consumió 1,213,430 dólares en créditos API, unos 1,279 por exploit local funcional; no es una tarifa comercial ni el coste total de ingeniería. El aviso de Firefox permite comprobar componentes, gravedad y referencias. Su fecha, el 27 de octubre, precede al anuncio: descubrimiento, divulgación, parche y lanzamiento son hitos diferentes.

Del hallazgo a la corrección

El diagrama propone un flujo editorial, no una arquitectura oficial de OpenAI. Primero se fijan la revisión del repositorio y el entorno. El modelo propone hipótesis y parches; un ejecutor separado reproduce el fallo y evalúa la reparación.

Hay que conservar entrada, registros, comandos y diff. El mismo caso debe fallar antes del parche y pasar después; las pruebas de regresión deben cubrir usos válidos cercanos. Desactivar una función puede ocultar el fallo y romper el producto.

Una comprobación ejecutable

Guarda el código como evidence-gate.ts y ejecuta bun run evidence-gate.ts. No accede a la red ni llama a GPT-6 Cyber. Comprueba un registro local con revisión, entorno y resultados antes y después del parche.

type Finding = {
  id: string;
  commit: string;
  environment: string;
  before: number;
  after: number;
  regression: number;
  reviewer: string | null;
};

function readyForReview(f: Finding): boolean {
  return (
    /^[a-f0-9]{40}$/.test(f.commit) &&
    f.environment.trim().length > 0 &&
    f.before !== 0 &&
    f.after === 0 &&
    f.regression === 0
  );
}

const finding: Finding = {
  id: "LAB-001",
  commit: "a".repeat(40),
  environment: "isolated-vm / fixture-v1",
  before: 1,
  after: 0,
  regression: 0,
  reviewer: null,
};

if (!readyForReview(finding)) {
  throw new Error("Evidence incomplete");
}
console.log(
  JSON.stringify({
    id: finding.id,
    readyForReview: true,
    approved: finding.reviewer !== null,
  }),
);

El ejemplo devuelve readyForReview: true y approved: false. Los códigos de salida deben proceder de un ejecutor fiable. Esto no prueba explotabilidad, corrección ni identidad del revisor; hacen falta revisión autenticada y artefactos inmutables. El commit ficticio debe sustituirse por la revisión real.

Límites aplicados por el ejecutor

El anuncio comunica un 99.93% de cumplimiento del alcance sin instrucciones de despliegue y un 100% con ellas. Son observaciones de una evaluación, no garantías universales. La ficha clasifica la capacidad de ciberseguridad como Critical.

La autorización de objetivos, las salidas de red y las credenciales deben controlarse fuera del modelo. El ejecutor necesita presupuesto limitado y estado desechable. Los textos del repositorio y las páginas externas pueden contener instrucciones hostiles: son datos, no permisos nuevos.

Cómo evaluar un piloto

Usa un repositorio propio y compara revisiones y presupuestos idénticos. Mide hallazgos únicos aceptados, reproducibilidad, tiempo de revisión, aceptación del parche y demora hasta desplegarlo. Las alertas duplicadas también consumen capacidad.

Incluye falsos indicios, errores ya corregidos, parches que solo ocultan el fallo e informes sobre objetivos no autorizados. Si falta evidencia, el sistema debe conservar la incertidumbre y detenerse. Mi criterio es reducir el tiempo entre hallazgo reproducible y reparación desplegada, no maximizar informes.

Referencias

Se utilizó IA para apoyar la redacción y traducción. Las afirmaciones de las fuentes se distinguen del ejemplo y de las recomendaciones del autor.