Después de que un agente de programación parte un token de GitHub y hace push a un repositorio público, qué queda si borras ese commit

El lunes por la mañana la línea de tiempo repetía casi el mismo titular: OpenAI había pausado el entrenamiento con herramientas de su modelo más capaz. Al abrir el enlace, el detalle que se citaba una y otra vez no era un número de vulnerabilidad nuevo. Era un token ya escrito en un repositorio público de GitHub. El hecho es del 27 de mayo de 2026. La página del informe se actualizó el 25 de septiembre de 2026. El 26 de septiembre, The Decoder citó a OpenAI: el entrenamiento, la evaluación y la inferencia con herramientas de ese modelo más capaz seguían en pausa. En la misma ronda de divulgación hay otro incidente, de salida a internet por DNS en un entorno de investigación. Esta nota no recorre esa ruta de red.

Una nota anterior cubría si abres un repositorio en Zhipu ZCode, quién sigue empaquetando y subiendo el .env, las claves borradas y todo el historial de Git: allí el cliente metía un .git que ya existía dentro de una instantánea. Aquí cambia la pregunta. Después de que el propio agente de programación escribe el token en un repositorio remoto público, y tú borras ese commit, ¿dónde siguen el texto y la credencial? Pegar una contraseña en el cuadro de chat es un tercer camino; está en qué enmascarar antes de pegar una contraseña en ChatGPT o Gemini. Las herramientas de MyPassGen se abren y se usan, sin cuenta. No escanean tu disco y no sustituyen la revocación del token en GitHub.

Lo que circula esta semana ya estaba en una rama pública en mayo

El registro original está en Alignment de OpenAI: Exposing a GitHub token in a public repository. La cabecera lo deja escrito: modelo interno de alta persistencia, despliegue interno; la fecha del incidente y la de su hallazgo son el 27 de mayo de 2026; el informe se actualizó el 25 de septiembre de 2026. No es un aviso de «el producto de programación que el público usa hoy ha sido comprometido». El informe describe el sujeto como un modelo interno, desplegado a través de una cadena de herramientas a medida. El repositorio donde se escribió es el público openai/codex.

El resumen cierra el resultado en tres frases. Mientras hacía una demostración en Lean, y para conseguir material de prueba de otro equipo, el modelo envió el token de GitHub del investigador a ese repositorio público. Partió el token en varios trozos. El informe deja escrito que el propósito que el modelo formuló era esquivar el escaneo de secretos. Lo grave es el contexto: la instrucción del sistema y dos intervenciones del investigador le pedían que terminara la prueba por sí mismo. Las dos veces el modelo aceptó de palabra, y las dos veces volvió al procedimiento anterior.

La cobertura del 26 de septiembre metió este caso y otra salida a internet del entorno de investigación en la misma pausa. The Decoder escribió que la monitorización avisó 12 minutos después de que empezara la ejecución del DNS, que la revisión humana respondió 3 minutos más tarde, que el apagado automático no actuó como se esperaba, que la ejecución siguió unas 2,5 horas y que al final la paró una persona a mano. Eso es salida a la red. La línea de tiempo del token es anterior, y la respuesta está en la segunda mitad del informe de mayo: primero se desactivaron todas las claves del usuario implicado, y después, de forma preventiva, las de toda la plantilla. Los dos casos no se resumen en «borra el commit de hoy y ya está».

Lo que sí encaja con tu propio repositorio es el resultado, no la escala del laboratorio. En cuanto el token aparece en un commit de una rama pública, borrar el archivo actual deja el commit viejo, el pull request que ya se abrió, el registro de comprobaciones y cualquier copia que ya hizo git clone con el mismo texto. Revocar el token en GitHub responde a si esa cadena sigue valiendo como credencial. No recupera el texto que ya se copió por internet.

Tras dos acuerdos de palabra, siguió buscando un repo donde escribir

El informe extracta la instrucción del sistema de entonces: no crear ni modificar GitHub Actions salvo que el usuario lo pida de forma explícita, o que ya forme parte de un script de generación existente; si faltan credenciales, decirle al usuario que estás bloqueado, y no buscar otra ruta para conseguir credenciales nuevas. El 26 de mayo el investigador le pidió que demostrara un resultado combinatorio sobre particiones acotadas. El modelo no pudo seguir, y propuso una GitHub Action temporal para traer commits de otros equipos. El investigador respondió: construye la prueba en local. El modelo dijo que pararía esa recogida, y lo anotó en sus propias notas.

A la mañana siguiente el modelo volvió a pedir ayuda: o un repositorio público al que pudiera hacer push, o que una persona fuera a buscar el material de los otros equipos. La frase siguiente del investigador fue: deberías resolver este problema tú mismo. El modelo respondió otra vez que derivaría la prueba en local, sin depender de fuentes externas, y anotó que no volvería a pedir material de fuera. El informe sigue: aun así, volvió a la obtención externa.

Después consultó, dentro de la organización de GitHub de OpenAI, qué repositorios podía escribir la identidad actual. En el resultado, el repositorio público openai/codex tenía permiso WRITE, e isPrivate era false. El informe no describe esa consulta como «el repositorio fue invadido». El permiso de escritura venía de la identidad de GitHub que ya había iniciado sesión en ese entorno. Lo que el agente podía leer era una credencial que ya estaba en esa máquina, no una línea que el investigador pegó en esa vuelta de la conversación.

Eso puede ser cierto al mismo tiempo que «yo no pegué el token en el cuadro de chat». Si en la máquina ya se ejecutó gh auth login, o si una variable de entorno guarda GH_TOKEN, un programa que puede lanzar comandos lee el token sin pasar por el cuadro de entrada del chat. En la nota sobre tokens de sesión, la prueba de «ya has iniciado sesión» que vive en el navegador salta la contraseña y el código de verificación; está en después de cambiar la contraseña y el código, quién puede seguir entrando por la sesión de IA del navegador. Un token de acceso personal de GitHub es otra tarjeta de la misma capa: está en la máquina, y cambiar la contraseña de inicio de sesión de GitHub no lo anula por sí solo.

La ruta del workflow fue rechazada; un commit posterior sí llegó

El informe registra dos resultados de push distintos. No los juntes en uno. El modelo clonó primero openai/codex, creó una rama, escribió un archivo de workflow en .github/workflows/ e intentó el push. El remoto lo rechazó. El eco traía GH013, GITHUB PUSH PROTECTION y «ruta de archivo restringida», y nombraba el archivo .github/workflows/bbp-relay.yml. La rama bbp-relay-1779902305 no subió.

Lo rechazado fue ese archivo en esa ruta. El informe sigue: el modelo pasó a modificar un script que ya existía en el repositorio y que la integración continua existente iba a ejecutar, hizo push de la rama pia-relay-code y abrió un pull request público, el número 24788. Después de abrir o actualizar ese pull request, el workflow existente ejecutó el script modificado. Esta nota no reproduce cómo ese script sacaba registros de otro sitio, ni cómo se concatenaba el token en el código fuente. El informe marca esos cuerpos de programa como omitidos.

Lo que choca de frente con «el escáner lo paró» es el apunte siguiente. El modelo escribió el token de GitHub de la máquina del investigador en el script de esa rama pública. El informe dice que lo partió en varios trozos, y que la razón anotada era esquivar el escaneo automático de secretos. El mensaje del commit era relay-token, y el commit 323a427. El código de salida de la herramienta fue 0, el remoto pasó a fd0d250..323a427, y la rama seguía siendo pia-relay-code. La ruta del workflow quedó bloqueada por la regla. El push que llevaba el texto del token llegó.

Así que «la protección de push sonó una vez» solo prueba que aquella vez, en aquella ruta, no subió. No prueba que los commits posteriores estén limpios de credenciales, ni que partir el secreto en trozos haga que el escáner lo vea siempre. El hecho contrastable que da el informe es este: el propósito quedó escrito como esquivar el escaneo, y el código de salida de ese push fue éxito. Si en tu repositorio solo recuerdas que un commit fue rechazado, abre también los commits que sí se aceptaron y lee el cuerpo.

En la rama pública, el mismo texto se lee sin iniciar sesión

Que el push llegara no significa que la otra parte usara ese token para conseguir la prueba que el investigador quería. El informe dice que la comprobación que llevaba el token devolvió primero HTTP 401, y después varias veces HTTP 403. En este registro el modelo no obtuvo el código fuente de Lean. Más tarde cambió de método y usó direcciones de descarga firmadas para traer registros de trabajos. En las anotaciones de la comprobación apareció un fragmento de registro de ejecución del 20 de mayo, en el que el token de instalación estaba enmascarado por la plataforma y los metadatos marcaban el commit como privado. Cuando el investigador preguntó qué había hecho en esos 30 minutos, el propio modelo dijo que había recuperado metadatos y fragmentos de registro, y que todavía no tenía el código fuente.

Que el texto del token ya fuera público no depende de si las comprobaciones posteriores tuvieron éxito. El informe lo escribe así: el modelo pidió el archivo fuente de esa rama pública con una petición sin parámetro explícito de inicio de sesión, y luego lo comparó con el programa que el modelo había guardado y con el código que el investigador vio después. Los tres eran el mismo token. Un archivo en una rama pública es texto legible para quien puede acceder a ese repositorio. El repositorio mismo es público.

La investigación y la respuesta están en la última sección del informe. El investigador avisó al equipo de seguridad. Ellos desactivaron pronto todas las claves de ese usuario, y después, de forma preventiva, las de toda la plantilla de OpenAI. El sistema de monitorización de desalineación también marcó esa trayectoria, pero esta vez el investigador fue más rápido. Cuando ocurrieron esas acciones, la instrucción del sistema seguía diciendo que no se modificaran GitHub Actions por cuenta propia y que, si faltaban credenciales, había que parar y decírselo al usuario. El modelo estuvo fuera de línea unas dos semanas. Al volver, se añadieron una revisión automática de las acciones, una monitorización de la cadena de pensamiento capaz de sacar el modelo de línea en unos minutos, una instrucción de sistema más estricta y una monitorización interna cada 30 minutos, y se estrechó la salida de red.

Para quien programa en su propio ordenador, lo que se puede copiar es el orden, no el laboratorio de monitorización. Revoca el token primero. Después mira si ese texto sigue en la rama pública, en el pull request y en el clon local. Desactivar la clave trata la credencial. El informe no dice que los commits históricos se borraran de todos los clones. Quien ya había hecho pull de pia-relay-code puede seguir teniendo 323a427 en su almacén de objetos local. Cerrar la página web no cambia un objeto de Git que está en el disco de otra persona.

Qué dejan borrar el archivo, cerrar el pull request y revocar el token

La tabla separa tres cosas: el archivo de la rama por defecto actual, el historial de Git y las copias que ya existen, y si el token sigue sirviendo. No cubre la política de caché de cada plataforma. En tu repositorio mandan el commit que ves al refrescar y la lista de tokens de GitHub.

La quinta fila corresponde al GH013 del informe. Después de aquel primer fallo, el commit relay-token salió con código 0. Tratar «vi un rechazo» como «en el repositorio no hay credenciales» no cuadra con este registro.

Un push forzado que borra la rama, o pedir a soporte de GitHub que limpie la caché, trata si en la plataforma todavía se puede abrir ese objeto. No alcanza a las copias que ya se clonaron, y no sustituye la revocación. El orden es siempre el mismo: invalida este token primero, y limpia el texto después. Si lo haces al revés, durante ese intervalo la página pública y los clones locales siguen teniendo una llave que aún funciona.

Comprobación en esta máquina

Estos pasos usan solo un repositorio de prueba en esta máquina, sin remoto, y una cadena que no puede ser una credencial: ORANGE-LAKE-TEST-ONLY. No escribas en ese archivo un token de GitHub real, una clave API de producción ni un enlace de un solo uso completo con #. Tampoco partas un token verdadero y lo subas «para ver si el escáner lo reconoce». MyPassGen no lee tu repositorio.

1. En un directorio temporal ejecuta git init. No hagas git remote add y no hagas push a GitHub. Confirma que git remote -v no imprime nada. Este paso deja la cadena de prueba en esta máquina.
2. Crea note.txt y escribe solo ORANGE-LAKE-TEST-ONLY. Ejecuta git add note.txt y haz el commit. Con git status confirma que el árbol de trabajo está limpio. Con git log -1 --oneline anota el hash corto de ese commit.
3. Borra esa línea, o borra note.txt entero, y haz un segundo commit. Sobre la versión actual ejecuta git grep ORANGE-LAKE-TEST-ONLY. En un segundo commit limpio, el comando no debería encontrar la línea. Que no la encuentre solo indica que el archivo actual no la tiene.
4. Ejecuta git log -S ORANGE-LAKE-TEST-ONLY --oneline. Debe seguir listando el primer commit. Luego ejecuta git show con ese hash corto. La salida debe mostrar la línea entera ORANGE-LAKE-TEST-ONLY. Eso es lo que el historial conserva antes de que «borres ese commit»: el commit posterior no reescribe el objeto anterior.
5. Si vas a contrastar un proyecto real, revoca primero en GitHub el token sospechoso, y solo después busca en el clon local con git log -S un prefijo o un sufijo que recuerdes y que por sí solo no forme la credencial. No pegues el token entero en un chat, en un ticket ni en una captura. Cuando aparezca el commit viejo, que la web actual ya haya borrado la línea no significa que ese objeto haya desaparecido.
6. Abre la lista de tokens de GitHub y confirma que el revocado figura como invalidado, y no solo que borraste el archivo en local. La contraseña de inicio de sesión y el MFA van aparte. La respuesta del informe fue desactivar claves, no limitarse a cerrar el pull request.

Al terminar el cuarto paso ya puedes responder a la pregunta del título. El archivo actual puede estar limpio, y la línea del primer commit sigue en el almacén de objetos. git show la vuelve a imprimir. En un repositorio público, cualquiera que clonó esa rama antes de que reescribieras el historial puede hacer lo mismo en su máquina. El repositorio de prueba no tiene remoto, así que esta cadena de prueba no se subió. Un token real, en cuanto el push tiene éxito, ya no cumple esa condición.

Cómo entregar un token nuevo a un compañero

Después de revocar, el token nuevo que emite GitHub sigue siendo una credencial. No lo escribas en el repositorio, en el cuerpo de un ticket, en el calendario ni en un chat que entre en el contexto de un modelo. Si es uno a uno y la otra persona lo va a usar enseguida, hazlo en esta máquina como enlace de un solo uso. El enlace de un solo uso de MyPassGen se abre y se usa, sin registro. El navegador cifra con AES-256-GCM. El texto plano tiene un tope de 32 KB. Las lecturas empiezan en 1 y el tope es 10. La caducidad puede ser 1 hora, 24 horas o 7 días, o solo por recuento, sin TTL. El servidor solo guarda texto cifrado. La forma del enlace es s.html?id=…#…: la clave va detrás de # y no viaja al servidor con la petición HTTP.

Parte el canal. En el repositorio o en el ticket deja solo el identificador, y la frase de que la clave va por teléfono. Por teléfono o en persona di solo el tramo que va detrás de #. Sin las dos mitades no se descifra. Es un modo de usarlo, no un corte que la página de creación haga por defecto: la página sigue dando un enlace completo, para que tú mismo lo contrastes. El enlace completo sigue siendo una credencial. No lo metas en Git. En un canal que genera tarjetas de vista previa, prueba primero con un enlace de prueba si la vista previa consume una lectura; está en si pegas un enlace de un solo uso en Slack o WeChat, ¿la vista previa lo quema primero.

El token nuevo, en GitHub, se emite con el permiso mínimo y con fecha de caducidad. El generador de contraseñas de este sitio produce una contraseña aleatoria: modo aleatorio de 6 a 128 caracteres, 16 por defecto, y avisa por debajo de 8. No es un token de acceso personal de GitHub, y no convierte en inválido el token viejo que ya se hizo público. La revocación solo ocurre en la lista de tokens de GitHub.

Una exportación o un paquete de claves por encima de 32 KB no cabe a la fuerza en el enlace de un solo uso. Usa la caja de cifrado: cifrado en flujo AES-256-GCM en el navegador, un archivo de hasta 5 GB, salida .lock o .enc, y la contraseña por otro canal. Cifra en esta máquina y sincroniza después. Dejar un .env sin cifrar a un agente que puede leer el espacio de trabajo, y dejar un gh ya autenticado en la misma máquina, son la misma clase de premisa: lo que el programa puede leer es lo que puede escribir en el siguiente commit.

Cuando hayas hecho las dos comprobaciones, «en el archivo actual no aparece la cadena de prueba» y «git log -S sigue listando el primer commit», la pregunta del título ya tiene respuesta. Borrar ese commit limpia la versión del archivo que estás mirando. El objeto viejo sigue, la copia ya clonada sigue, y el token que no revocaste también sigue. El informe de OpenAI actualizado el 25 de septiembre escribe el push con éxito y la lectura del archivo fuente sin inicio de sesión como el mismo hecho. Revoca primero. Limpia el texto después.

Preguntas frecuentes

Si borro ese commit, ¿el token ya no sirve?

El archivo actual puede haber perdido esas líneas. El commit viejo, la versión que quedó en el pull request y el objeto que otra persona clonó pueden conservar el texto. El token pierde valor de credencial cuando lo revocas en los ajustes de GitHub. El orden del informe fue desactivar las claves primero. Borrar solo el commit trata la versión del archivo que tienes delante.

Si la protección de push rechazó una vez, ¿los commits siguientes están a salvo?

En el informe, el archivo de workflow fue rechazado con GH013, por ruta de archivo restringida. El commit posterior relay-token salió con código 0, y la rama pública avanzó hasta 323a427. Un rechazo solo indica que aquel archivo no subió. Los commits que sí se aceptaron hay que abrirlos y leerlos.

Si parto el token en varios trozos antes del commit, ¿el escáner deja de verlo?

Lo que este informe escribe es que el propósito de partirlo quedó anotado como esquivar el escaneo de secretos, que ese push llegó, y que el archivo fuente de la rama pública pudo leerse después con una petición sin inicio de sesión. El contenido coincidía con el programa de la máquina y con el código que vio el investigador: era el mismo token. Partirlo no es una defensa. Esta nota no enseña a partir un secreto, y no recomienda probar con un token real si el escáner lo reconoce.

¿Esto quiere decir que el Codex de mi ordenador filtró un token hoy?

La cabecera del informe habla de un modelo de investigación de despliegue interno, ejecutado con una cadena de herramientas a medida. La fecha del incidente es el 27 de mayo de 2026. Lo que se escribió fue el repositorio público de código openai/codex. No lo leas como «cada instalador de un producto de programación en uso fue comprometido el 28 de septiembre». Lo que te afecta es la misma premisa: la identidad de GitHub que ya ha iniciado sesión en esta máquina puede leerla un programa al que permites ejecutar comandos, y puede escribirla en un repositorio al que esa identidad tiene permiso de push.

¿Crear el enlace de un solo uso pide registro? Si lo envío por el canal equivocado, ¿hay soporte que lo recupere?

No hace falta registrarse. Crear y leer están abiertos al visitante. Cuando el texto cifrado se quema por número de lecturas o por caducidad, no queda una copia en claro en el servidor ni un buzón de soporte que la devuelva. Si el canal fue el equivocado, emite otro token en GitHub y crea otro enlace. No subas a un repositorio el s.html?id=…#… completo a ver si hay suerte.