Claves de Anthropic en GitHub: cómo evitar filtrarlas en un commit

GitHub ahora detecta dos tipos de claves de Anthropic y puede bloquear el push antes de que la credencial llegue al repositorio. Si aparece el aviso, no conviene omitirlo de inmediato: localiza la clave, elimínala del archivo y del commit, muévela a una variable de entorno o gestor de secretos y vuelve a intentar. Si la clave ya estuvo en un repositorio remoto, un registro o un canal compartido, debes revocarla desde Claude Console y crear otra. El bloqueo reduce filtraciones accidentales, pero no reemplaza la rotación, el control de permisos ni la revisión del historial.

Qué cambió en GitHub Secret Scanning

El 13 de octubre de 2026, GitHub anunció que Secret Scanning reconoce dos patrones nuevos de Anthropic: anthropic_service_api_key y anthropic_user_api_key. Ambos quedaron incluidos de forma predeterminada en Push Protection para repositorios con Secret Scanning habilitado, incluidos repositorios públicos gratuitos.

El anuncio también incorpora detectores para una clave de Cloudsmith y un token de Salesforce Marketing Cloud, pero la protección preventiva predeterminada descrita por GitHub se aplica específicamente a los dos tipos de Anthropic citados.

Se trata de un anuncio de producto y seguridad preventiva. GitHub no informó un incidente, una filtración concreta ni una vulnerabilidad de la API de Anthropic.

Qué hace Push Protection y qué no hace

La documentación de GitHub explica que Push Protection inspecciona cambios en busca de patrones de credenciales compatibles y detiene el push antes de que lleguen al repositorio remoto. También puede actuar cuando una persona crea, edita o sube archivos desde la interfaz de GitHub.

Esto aporta una barrera temprana, pero tiene límites:

• Solo reconoce patrones compatibles y suficientemente identificables.
• Una persona puede disponer de opciones de bypass según la configuración del repositorio.
• El bloqueo no demuestra que una clave detectada siga activa.
• No corrige secretos filtrados anteriormente en historial, registros, artefactos, mensajes o sistemas externos.
• No determina por sí solo qué permisos tenía la clave ni si fue utilizada.

Qué hacer cuando GitHub bloquea una clave de Anthropic

1. No elijas el bypass como primera respuesta

Revisa el archivo, la línea y el tipo de secreto indicado. El bypass está pensado para falsos positivos o casos controlados, no para conservar una credencial real en el código. En repositorios con Secret Scanning habilitado, GitHub exige justificar determinados bypass y puede generar alertas para responsables del repositorio.

2. Retira la clave del código y del commit

Sustituye el valor por una referencia a una variable de entorno o a un gestor de secretos. Si el push fue bloqueado antes de llegar al servidor, modifica o reconstruye el commit local que contiene la clave. Borrar únicamente la línea en un commit posterior puede dejar el valor dentro del historial anterior.

3. Decide si debes revocar la credencial

Si la clave ya apareció en un repositorio remoto, registro de CI, captura, ticket, chat, artefacto descargable o cualquier espacio compartido, trátala como comprometida. Anthropic recomienda revocar inmediatamente una clave sospechosa desde la página de API keys de Claude Console, utilizando la opción para eliminarla.

Crear una clave nueva sin desactivar la anterior deja vigente el riesgo. Primero revoca o elimina la credencial expuesta, después genera el reemplazo y actualiza los servicios que dependen de ella.

4. Guarda el reemplazo fuera del repositorio

Para desarrollo local, utiliza variables de entorno cargadas desde un archivo excluido del control de versiones. Para automatizaciones y despliegues, usa GitHub Actions Secrets, un gestor del proveedor de nube o una solución centralizada con permisos y auditoría.

Anthropic también recomienda no compartir claves, almacenarlas mediante variables o gestores de secretos y rotarlas regularmente.

5. Comprueba posible uso no autorizado

Revisa consumo, facturación, registros disponibles, fechas y servicios que utilizaron la clave. Documenta cuándo pudo quedar expuesta, quién tenía acceso y qué sistemas necesitan el reemplazo. Una subida de uso no prueba por sí sola un abuso, pero una actividad no reconocida debe investigarse.

6. Verifica que el secreto ya no exista

Busca el valor en ramas, historial, archivos de configuración, artefactos, variables impresas por CI y copias compartidas. Evita volver a escribir la credencial completa en tickets o informes. Cuando sea necesario identificarla, utiliza una referencia interna o solo una porción no sensible.

Cómo almacenar claves sin incorporarlas al código

La regla práctica es separar código, configuración y secretos. El repositorio puede contener el nombre de la variable requerida, pero no su valor real.

• Desarrollo local: variable de entorno y archivo local ignorado por Git.
• GitHub Actions: secretos del repositorio, entorno u organización, con acceso limitado al flujo que los necesita.
• Producción: gestor de secretos, identidad de servicio y rotación documentada.
• Equipos: claves distintas por servicio o entorno, evitando una credencial compartida por todas las personas.

La guía de gestión de secretos de OWASP recomienda controlar el ciclo de vida completo: creación, distribución, uso, rotación, revocación y auditoría.

Aplicación práctica para pequeñas empresas

Una empresa pequeña puede usar la API de Anthropic desde un chatbot, automatización, sistema interno o integración de atención. Aunque el código lo mantenga un proveedor externo, la organización debería conocer quién controla las claves, dónde se almacenan y cómo revocarlas.

Una revisión mínima debe responder:

• ¿Cada entorno tiene una clave distinta?
• ¿Quién puede leer o reemplazar la credencial?
• ¿Las claves aparecen en archivos, tutoriales internos o capturas?
• ¿Existe un procedimiento para rotarlas sin detener el servicio?
• ¿Se puede asociar el consumo con una integración concreta?

Este control complementa otras medidas de aislamiento. Por ejemplo, el sandbox local de GitHub Copilot limita el acceso de agentes a archivos, red y credenciales, mientras que las protecciones para flujos de GitHub Actions reducen la exposición al ejecutar código procedente de contribuciones externas.

Hechos, análisis y recomendaciones

Hechos confirmados

• GitHub añadió detectores para claves de servicio y usuario de Anthropic.
• Los dos patrones están incluidos en Push Protection por defecto para repositorios con Secret Scanning habilitado.
• GitHub describe Push Protection como una barrera previa a la llegada del secreto al repositorio remoto.
• Anthropic recomienda revocar inmediatamente una clave cuando se sospecha que fue comprometida.

Análisis

El cambio es especialmente útil para equipos que incorporan IA con rapidez y copian ejemplos entre entornos. La causa más frecuente no suele ser una falla criptográfica, sino una credencial pegada en código, configuración, notebooks o pruebas.

Sin embargo, una detección automática no convierte el repositorio en un almacén seguro. La protección debe combinarse con permisos mínimos, rotación y telemetría proporcional. La guía de GitCoders sobre telemetría de agentes sin capturar contenido explica por qué observar un sistema no obliga a recopilar información sensible.

Recomendaciones

• Habilita Secret Scanning y Push Protection donde estén disponibles.
• Configura revisión o bypass delegado en lugar de permitir excepciones informales.
• Utiliza credenciales separadas por entorno y servicio.
• Revoca antes de reemplazar cuando exista exposición real o posible.
• No publiques la clave para pedir ayuda ni la copies en herramientas de soporte.
• Prueba la rotación y documenta quién puede ejecutarla.

Limitaciones y contexto internacional

GitHub no anunció una restricción geográfica. La disponibilidad concreta depende del tipo de repositorio, plan, configuración de Secret Scanning y políticas de la organización. Los repositorios públicos también cuentan con protecciones para usuarios, pero el comportamiento de alertas y bypass puede variar.

La revocación desde Claude Console y la sustitución en servicios deben seguir las políticas de cada organización. Empresas reguladas pueden necesitar requisitos adicionales de registro, custodia, notificación o respuesta a incidentes.

Preguntas frecuentes

¿GitHub bloqueará todas las claves de Anthropic?

Bloqueará los patrones compatibles indicados por GitHub cuando Push Protection sea aplicable. No debe asumirse que detectará cualquier formato, transformación o ubicación posible.

¿Debo revocar la clave si el push fue bloqueado?

Si la clave nunca salió del equipo y no estuvo expuesta por otra vía, puede bastar con retirarla del commit y almacenarla correctamente. Si existe cualquier duda razonable sobre exposición, la opción segura es revocarla y reemplazarla.

¿Eliminar el archivo borra la clave del historial?

No necesariamente. Si la clave fue confirmada en un commit anterior, puede permanecer en el historial aunque el archivo se borre después.

¿Puedo usar el bypass para una clave de prueba?

Solo si está confirmado que no es una credencial real y la política del repositorio lo permite. Es preferible usar valores ficticios claramente inválidos en ejemplos y pruebas.

¿Push Protection sustituye un gestor de secretos?

No. Evita algunas filtraciones antes del push; el gestor controla almacenamiento, acceso, rotación y auditoría durante la operación.

Fuentes

• GitHub Changelog: nuevos detectores y protección para claves de Anthropic, 13 de octubre de 2026.
• GitHub Docs: Push Protection, consulta del 14 de octubre de 2026.
• Anthropic Support: qué hacer ante una clave posiblemente comprometida.
• Anthropic Support: buenas prácticas para claves API.
• OWASP: Secrets Management Cheat Sheet.

Información verificada el 14 de octubre de 2026 a las 11:10, America/Lima.