Un desarrollador pega por accidente una clave de Claude en un archivo de configuración y hace git push. A partir del 13 de octubre de 2026, GitHub puede bloquear ese envío por defecto para dos tipos nuevos de credenciales Anthropic cuando la protección está activa. La noticia es pequeña, pero útil para equipos que conectan agentes y pruebas a APIs: un push rechazado es una oportunidad de corregir la exposición antes de que llegue al repositorio.

Qué añadió GitHub

El anuncio oficial indica nuevos detectores para anthropic_service_api_key, anthropic_user_api_key y cloudsmith_api_key. Los dos tipos de Anthropic entran en push protection por defecto en repositorios con secret scanning habilitado, incluidos repositorios públicos gratuitos. También se incorporó Salesforce como socio de secret scanning para salesforce_marketing_cloud_api_oauth2_token. Son cambios de detección y protección; no significan que GitHub pueda reconocer todo secreto posible.

GitHub distingue alertas de secretos «partner» y «user». Cuando encuentra un secreto de un socio en un repositorio público, puede reportarlo al emisor para que lo revoque o rote; los secretos de usuario generan alertas en repositorios públicos o privados según la cobertura. No dependas de que esa notificación sustituya tu propia respuesta a incidentes.

Si GitHub bloquea tu push

1. Lee la ruta y el commit señalados. No pegues el valor de la clave en un ticket, captura o chat para pedir ayuda.

2. Quita el secreto de los commits donde aparece, no solo del archivo actual. La guía de GitHub explica cómo corregir el último commit o reescribir los anteriores de tu rama.

3. Si la clave real estuvo expuesta o hay duda de acceso, rótala y revoca la anterior en el proveedor. Actualiza el entorno que la utiliza y comprueba que el servicio siga funcionando.

4. Guarda nuevas credenciales en el gestor de secretos o variables del servidor. Añade a .gitignore archivos locales que no deben versionarse, pero recuerda que ignorar un archivo ahora no lo borra de un commit anterior.

Dos comprobaciones antes de confiar en el bloqueo

Primero, confirma que secret scanning y push protection cubren el repositorio y la ruta de trabajo que usa tu equipo. GitHub advierte que un secreto ya detectado y con alerta existente puede no volver a bloquearse. Segundo, prueba el flujo con un valor ficticio de prueba autorizado por tu política, nunca con una clave real creada para provocar el detector. Mejor aún, inspecciona la configuración y haz una revisión de un pull request de ejemplo sin credenciales.

Si un miembro del equipo pide saltarse un bloqueo, averigua si se trata de un falso positivo o de una clave real antes de aprobarlo. La documentación de push protection explica que la herramienta no reemplaza la remediación: secretos reales expuestos deben revocarse. En aplicaciones con IA, esta revisión pertenece al mismo flujo que pruebas y despliegue; la API key suele dar acceso directo al gasto y a datos del proyecto.

El cambio más provechoso hoy es revisar dónde guardas credenciales de Claude en proyectos y automatizaciones. La protección de GitHub es una red adicional. Tu defensa principal sigue siendo no poner claves en código, limitar su alcance, rotarlas cuando corresponde y comprobar alertas.

Fuentes: GitHub Changelog, 13 oct 2026; documentación de push protection.