API key filtrada: qué hacer ahora mismo y cómo evitar que vuelva a pasar

Si se ha filtrado tu API key, lo primero es revocarla en el panel del proveedor y crear otra; después, pon un límite de gasto y revisa el uso de los últimos días. Borrar el archivo y hacer otro commit no sirve: la clave sigue en el historial de git, y quien la haya copiado puede usarla hasta que la revoques.

Esta guía va en orden de urgencia: los diez primeros minutos, la limpieza del repositorio y, al final, cómo trabajar para que no vuelva a pasar. Las rutas de los paneles y las cifras son de la documentación oficial de cada proveedor, consultada el 8 de octubre de 2026.

Los primeros diez minutos

1. Revoca la clave

Revocar es lo único que corta el acceso. Todo lo demás (borrar el archivo, limpiar el historial, hacer privado el repositorio) llega tarde si la clave ya está copiada.

En OpenAI, la clave se revoca en Settings, API keys. Según OpenAI, la revocación surte efecto en unos segundos.

En Anthropic (Claude), entra en Settings, API keys y abre el menú de tres puntos junto a la clave. Disable la desactiva y se puede revertir; Delete la elimina para siempre.

En Google (Gemini), desactiva o elimina la clave comprometida desde la página de API keys de AI Studio o desde la de credenciales de Google Cloud.

Si la clave está en una aplicación en producción, el orden depende de cómo se haya filtrado. Google recomienda crear la nueva, desplegarla y solo entonces desactivar la vieja, para no dejar el servicio caído. Pero si la clave está a la vista de todo el mundo (un repositorio público, una web), revócala ya: un rato de servicio caído sale más barato que una factura ajena.

2. Crea una clave nueva y cámbiala donde haga falta

Crea la sustituta en el mismo panel y actualízala en tu servidor o en las variables de entorno de tu plataforma. No la pegues en ningún archivo que vaya al repositorio; en el último apartado verás dónde sí.

3. Pon un tope de gasto

Una clave robada se usa deprisa. Los límites de gasto son tu red de seguridad para la próxima vez y, si todavía queda alguna copia activa, también para esta:

• OpenAI: en Limits, un límite duro mensual para la organización o para cada proyecto. Al llegar, las peticiones fallan con error 429. Y revisa la recarga automática del crédito, que viene activada al configurar el pago: es la vía por la que la factura sigue creciendo.
• Anthropic: en Settings, Billing, un límite de gasto por debajo del tope de tu nivel. También se pueden poner límites por espacio de trabajo.
• Google: un tope mensual por proyecto en la página Spend de AI Studio. Google avisa de que es experimental y de que los datos de facturación llegan con unos 10 minutos de retraso, así que puedes pasarte un poco.

4. Revisa el uso y la facturación

Busca picos de gasto, modelos que tu aplicación no usa y actividad a horas en que no trabaja. En OpenAI, la página Usage desglosa el consumo por clave. Si encuentras cargos que no son tuyos, escribe a soporte con fechas, importes y modelos. Anthropic, en su centro de ayuda, recomienda contactar con su equipo de soporte si la actividad sospechosa continúa después de borrar la clave.

Por qué borrar el archivo no basta

Git guarda cada versión de cada archivo. Si subiste un .env con la clave y en el commit siguiente lo borraste, la clave sigue en el historial y cualquiera puede verla navegando por los commits antiguos. Y aunque reescribas el historial, la documentación de GitHub avisa de que los commits pueden seguir accesibles en clones y forks, en vistas en caché de GitHub y en las pull requests que los referencian.

Además, hay quien rastrea internet buscando claves de forma sistemática. Truffle Security analizó en 2026 el archivo de Common Crawl de noviembre de 2025 (unos 700 TiB de páginas web públicas) y encontró 2.863 claves de Google activas incrustadas en webs, algunas de grandes empresas. Si una clave ha estado publicada, aunque sea un rato, hay que darla por copiada.

Por eso el orden es siempre el mismo: primero revocar, luego limpiar. La propia GitHub reconoce que, una vez revocada la clave, reescribir el historial puede no merecer la pena.

Cómo borrar la clave del historial de git

Si aun así quieres limpiar el repositorio (por ejemplo, porque había más datos sensibles o porque es un proyecto público con muchos clones), GitHub recomienda git filter-repo en una versión con la opción --sensitive-data-removal (la 2.47 o posterior).

Trabaja sobre un clon nuevo del repositorio. Para borrar un archivo de toda la historia, con su ruta completa dentro del repositorio:

git-filter-repo --sensitive-data-removal --invert-paths --path config/.env

Para sustituir la clave por otro texto en todos los archivos y commits, escribe la clave en un archivo fuera del repositorio (por ejemplo ../claves.txt, una por línea) y ejecuta:

git-filter-repo --sensitive-data-removal --replace-text ../claves.txt

Comprueba que ha desaparecido y sube el resultado forzando todas las ramas y etiquetas:

git push --force --mirror origin

Lo que sigue, según la guía de GitHub: pedir a su soporte que borre las vistas en caché y las referencias de las pull requests, y avisar a quien tenga clones para que los borre y vuelva a clonar. Si alguien hace git pull y git push con un clon antiguo, la clave vuelve. Los forks no los puedes limpiar tú.

La alternativa clásica es BFG Repo-Cleaner, que necesita Java 11 o superior. Se trabaja sobre un clon espejo (git clone --mirror), se ejecuta java -jar bfg.jar --replace-text claves.txt mi-repo.git, se limpia con git reflog expire --expire=now --all && git gc --prune=now --aggressive y se hace git push. Una advertencia: BFG no toca el último commit, así que tienes que quitar tú la clave de la versión actual antes de pasarlo.

Reescribir el historial cambia los identificadores de todos los commits posteriores, rompe las firmas y deja huérfanas las pull requests abiertas. Haz una copia del repositorio antes de empezar.

GitHub ya vigila tus repositorios públicos

GitHub tiene un sistema de escaneo de secretos que, en los repositorios públicos, funciona solo y gratis: revisa todo el historial de todas las ramas, además de issues, pull requests y wikis. Para los proveedores que forman parte de su programa de socios, cuando encuentra una de sus claves en un repositorio público se la envía al proveedor para que actúe. Así queda en la tabla oficial de patrones a 8 de octubre de 2026:

Con su producto de pago, GitHub puede comprobar además si siguen activas las claves de OpenAI, las de Anthropic y las Google API Key. Con las Google Gemini API Key solo genera una alerta en el propio repositorio.

En el caso de Anthropic, GitHub anunció en agosto de 2024 que reenvía las claves expuestas a Anthropic, que las revoca y avisa al usuario. Si una clave de Claude deja de funcionar de repente, mira si la has subido a algún repositorio público.

El bloqueo al hacer push (push protection) para usuarios viene activado por defecto en GitHub.com y frena los secretos que intentas subir a repositorios públicos. Si te salta el aviso, no lo saltes: quita la clave del commit. En repositorios privados de organizaciones, todo esto requiere el producto de pago GitHub Secret Protection.

El caso que todo el mundo cita: 82.314 dólares en 48 horas

En marzo de 2026, The Register contó el caso de una startup mexicana de tres personas que solía gastar unos 180 dólares al mes en Google Cloud. Entre el 11 y el 12 de febrero de 2026 alguien usó su clave comprometida y generó 82.314,44 dólares en cargos, sobre todo con Gemini 3 Pro Image y Gemini 3 Pro. Según el medio, un representante de Google se remitió al modelo de responsabilidad compartida: asegurar las herramientas es cosa del cliente.

El caso coincidió con la investigación de Truffle Security citada arriba, que explica por qué tantas claves de Google eran vulnerables. Las claves con el prefijo AIza se usaban desde hacía años en webs públicas (para mapas, por ejemplo) y no se consideraban secretas. Al activar la API de Gemini en un proyecto, esas mismas claves ganaban acceso a Gemini sin ningún aviso.

Google ha cambiado las reglas desde entonces, según su documentación de claves de Gemini: desde el 28 de mayo de 2026, las claves nuevas de AI Studio se crean restringidas a la API de Gemini y con detección rápida de filtraciones, y la API de Gemini rechaza las claves estándar sin restricciones. Si tienes claves antiguas de Google, revisa que estén restringidas.

Cómo proteger una API key para que no se escape

La clave nunca va en el navegador ni en la app

Todo lo que llega al navegador o se instala en un móvil se puede leer. Vite lo advierte en su documentación: las variables con prefijo VITE_ acaban dentro del código del cliente y no deben contener claves de API. En Next.js pasa lo mismo con el prefijo NEXT_PUBLIC_, que se incrusta en el JavaScript que recibe el navegador. Y OpenAI pide en su referencia que no expongas la clave «en ningún código de cliente, como navegadores o apps».

La solución es un servidor intermedio: el navegador llama a tu backend (o a una función serverless) y es el backend el que llama al proveedor con la clave. Es un error muy fácil de cometer en webs hechas con IA, y lo explicamos con detalle en cómo publicar gratis una web hecha con IA y en cómo integrar IA en una aplicación.

.env fuera de git desde el primer commit

En local, la clave va en un archivo .env que nunca entra en el repositorio. Añade esto a .gitignore antes del primer commit:

.env
.env.*
!.env.example

Y sube un .env.example con los nombres de las variables pero sin valores, para que quien clone el proyecto sepa qué necesita.

Un detector antes de cada commit

Gitleaks es un escáner de secretos de código abierto que puedes ejecutar en cada commit con el framework pre-commit. Su README propone este .pre-commit-config.yaml (usa la versión que indique en ese momento):

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Después, pre-commit install. Para revisar un repositorio que ya existe, gitleaks git analiza su historial.

En producción, un gestor de secretos

En el servidor, la clave se lee de una variable de entorno que configuras en el panel de tu plataforma, o de un gestor de secretos (Google recomienda Secret Manager en su documentación de Gemini; AWS y Azure tienen los suyos). Así nunca existe en un archivo del proyecto.

Claves con caducidad, permisos y una por uso

• Caducidad. En Anthropic eliges al crear la clave cuánto dura: 3 horas, 1 día, 7 días, 30 días, una duración a medida o nunca; te avisan por correo antes de que caduque. OpenAI recomienda poner fecha de caducidad a las claves de proyecto y permite a los administradores imponer una vida máxima.
• Una clave por aplicación y entorno. Si se filtra la de pruebas, la revocas sin tumbar producción. OpenAI organiza esto con proyectos, cada uno con sus claves y su límite de gasto; Anthropic, con espacios de trabajo.
• Restricciones. En Google, restringe cada clave a la API que usa (y, si puedes, a las IP de tu servidor).
• Sin claves fijas, mejor. Anthropic y OpenAI admiten federación de identidad: tu servidor en AWS, Google Cloud o GitHub Actions obtiene credenciales temporales y no hay ninguna clave que robar. Para apps de iOS y macOS, Anthropic ofrece App Attest, con tokens que caducan en una hora.

Lista rápida

Si se acaba de filtrar:

1. Revoca la clave en el panel del proveedor.
2. Crea otra y cámbiala en tu servidor.
3. Pon un límite de gasto y revisa la recarga automática.
4. Revisa el uso de los últimos días y escribe a soporte si hay cargos ajenos.
5. Limpia el historial de git solo si hace falta, y después de revocar.

Para que no vuelva a pasar:

1. La clave solo vive en el servidor.
2. .env en .gitignore desde el primer commit.
3. Gitleaks u otro escáner antes de cada commit.
4. Una clave por aplicación y entorno, con caducidad y tope de gasto.

Por dónde seguir

• Cómo integrar IA en una aplicación: dónde va la clave en una arquitectura bien hecha.
• Primeros pasos con la API de OpenAI y de Claude: crear la clave y usarla desde variables de entorno.
• Precio de la API de OpenAI, Claude y Gemini: los límites de gasto de cada proveedor, comparados.