Subiste una clave de API: los primeros diez minutos, en el orden correcto

Ejecutaste git push, miraste el diff en GitHub y ahí estaba tu clave de API, en texto plano. Lo instintivo es borrar el commit y hacer un force-push antes de que alguien lo vea. No empieces por ahí. Da la clave por comprometida desde el momento del push y dedica el primer minuto al proveedor, no a git.

Por qué borrar el commit no deshace la fuga

Un push copia tu historial a sitios que no controlas. Quien haya clonado o hecho fork del repositorio tiene el commit. Hay scrapers automáticos que vigilan los push públicos buscando cualquier cosa con forma de clave, y son rápidos. Las cachés y los espejos pueden conservar una copia aunque reescribas tu rama. Quitar el commit limpia una sola copia, la tuya, y la clave sigue siendo válida en todas las demás. Lo único que inutiliza todas las copias a la vez es revocar la clave.

El orden que limita el daño

Esto es una recomendación general, no una regla de un proveedor concreto, pero el orden importa más que la rapidez de cada paso.

1. Revoca o rota la clave en el proveedor. Crea una nueva, cámbiala en tu entorno desplegado y borra la antigua. Hasta que esto esté hecho, el resto es cosmético.

2. Revisa el panel de uso y facturación del proveedor en busca de llamadas que no reconozcas, desde el momento del push en adelante. Si las hay, ahora tienes un incidente que reportar, no solo un error que ordenar.

3. Saca el secreto del código. En Laravel la clave va en .env, se lee desde un archivo de configuración, y el código la obtiene con config():

// config/services.php
'anthropic' => ['key' => env('ANTHROPIC_API_KEY')],

// anywhere in the app
$key = config('services.anthropic.key');

No llames nunca a env() fuera de un archivo de configuración. Después de php artisan config:cache, que ejecutan la mayoría de los despliegues, env() devuelve null fuera de la configuración, así que una clave leída directamente en un controlador suele acabar escrita en el código "solo para que funcione". Comprueba que .env está en .gitignore y mantén un .env.example con valores falsos para que nadie necesite el archivo real para arrancar la aplicación.

4. Solo entonces, si quieres, limpia el historial con git filter-repo o BFG. Es higiene, no una solución: necesita un force-push, que cada persona del equipo vuelva a clonar, y no hace nada con las copias del primer diagrama.

5. Evita la siguiente. Activa el secret scanning y la push protection, añade un escáner pre-commit y dale a cada entorno su propia clave con permisos limitados y un tope de gasto, para que la próxima fuga sea pequeña. Después apunta lo que pasó mientras todavía lo recuerdas.

Lo que GitHub hace ahora por ti

GitHub anunció el 2026-10-13 que el secret scanning detecta nuevos tipos de secretos de Salesforce, Anthropic y Cloudsmith, y que los dos nuevos tipos de Anthropic, anthropic_service_api_key y anthropic_user_api_key, quedan bloqueados por defecto por la push protection. Según GitHub, en los repositorios con secret scanning activado, incluidos los públicos gratuitos, los commits que contienen esas claves se bloquean automáticamente. GitHub también dice que los secretos de socios encontrados en repositorios públicos se reenvían al emisor para que pueda revocarlos antes de que se abuse de ellos, y que los secretos de usuario generan alertas en repositorios públicos y privados. Es una red de seguridad que vale la pena activar, pero solo cubre los tipos que GitHub conoce, así que el orden de arriba sigue siendo cosa tuya cuando algo se escapa. Si todavía no has activado el secret scanning en tus repositorios, hazlo hoy, y luego añade un escáner pre-commit para que la clave nunca salga de tu máquina.

Fuente: GitHub Changelog, 2026-10-13.