GitHub presentó el 7 de octubre de 2026 un clasificador basado en ModernBERT para detectar secretos por el contexto del código. Según el anuncio de GitHub, el modelo clasifica candidatos sin generar código ni texto y evalúa lotes en menos de dos milisegundos. Esa cifra procede del fabricante; no es una medición nuestra ni el tiempo total de una subida.
La incorporación a la protección antes del envío está en vista previa privada. GitHub prevé ofrecerla más adelante en octubre a organizaciones con GitHub Secret Protection en Enterprise Cloud y Team, con consumo de créditos de IA. Las organizaciones con detección de secretos por IA reciben el nuevo modelo en los análisis posteriores al envío.
El contexto permite buscar algo más que un prefijo
Muchos tokens de proveedores tienen una estructura que ayuda a reconocerlos. Una contraseña creada dentro de una empresa puede parecer una cadena cualquiera. GitHub plantea utilizar el código que rodea al valor para distinguir una credencial de un marcador de ejemplo.
El interés para un equipo de desarrollo es claro: si una IA genera más cambios, también necesitamos revisar esos cambios antes de que se incorporen al historial. No basta con que el programa funcione; hay que comprobar qué información contiene.
Detectar después y bloquear antes son procesos distintos
La documentación de push protection explica que esta protección bloquea envíos cuando encuentra secretos compatibles con su detección. El desarrollador debe revisar el cambio, retirar la información sensible y volver a enviarlo.
Por su parte, secret scanning busca credenciales en el historial del repositorio y genera avisos para las filtraciones detectadas. Si una credencial ya se ha expuesto, la recomendación de GitHub es rotarla inmediatamente: sustituirla y dejar de aceptar la anterior. Borrar la línea del último archivo no invalida por sí solo la clave.
Conviene comprobar el plan, los ajustes y el repositorio concreto. La protección asociada a un repositorio necesita habilitarse; la protección personal, activada por defecto, se dirige a envíos a repositorios públicos. Un repositorio privado no implica que todos los controles estén activos.
Un ejemplo que cambia la revisión de un agente
Imaginemos que un agente prepara un pequeño servicio y añade al código la dirección de una base de datos con usuario y contraseña. Es un ejemplo hipotético, no una incidencia ni una prueba realizada por Puntoes.
Nuestra revisión pediría que el archivo contuviese únicamente la referencia a la configuración necesaria, mientras la credencial real se proporciona desde el sistema de secretos del entorno. Después revisaríamos el cambio completo, incluidos archivos de ejemplo y configuración.
Si el envío queda bloqueado, el objetivo sería corregir la causa. No enseñaríamos al agente a eludir el bloqueo para terminar su tarea. Si el valor es un marcador ficticio, lo comprobaríamos antes de tratarlo como falso positivo; si es una credencial real ya expuesta, la sustituiríamos.
Qué no garantiza este anuncio
GitHub documenta límites de cobertura para el escaneo y la protección de envíos. Que un cambio no produzca una alerta no demuestra que esté libre de secretos. Además, la latencia que comunica el fabricante no acredita por sí sola la exactitud del detector en los archivos de una empresa.
Para valorar la incorporación, revisaríamos tres cosas: qué controles están disponibles y habilitados, quién puede gestionar las excepciones y cómo se responde a una credencial expuesta. También probaríamos el proceso con datos ficticios, sin introducir claves reales como material de prueba.
Para nuestro equipo, el siguiente paso sería evaluar el proceso completo: desde la configuración de credenciales hasta la respuesta a un aviso. Añadir un detector requiere saber cómo se gestionarán sus resultados.
Anuncio del 7 de octubre de 2026. Esta edición se incorporó al blog el 8 de octubre.