Qué hacer cuando una herramienta de IA filtra tus claves API

Hace unos meses, revisando mis propios proyectos, encontré archivos .env con tokens de producción de cinco proveedores distintos: el modelo de IA, el exchange, Cloudflare, el hosting y el panel de despliegue. Y no solo el archivo vivo: también copias de seguridad con fecha, cada una con las mismas claves adentro.
Nadie me hackeó. Nadie las publicó. Pero estaban ahí, en la carpeta de un agente de IA que lee y escribe archivos, a un comando de salir para cualquier lado.
Te lo cuento porque este artículo no lo escribe alguien que nunca se equivocó. Lo escribe alguien que conecta IA a sistemas reales todos los días, para su empresa y para clientes, y que aprendió que el riesgo no es usar IA, sino conectarla sin orden.
¿Qué hago primero si se filtró una clave API?
Revocarla en el proveedor. Ese es el primer paso, y el único urgente.
El instinto de casi todo el mundo es otro: borrar el archivo, hacer un commit que la quite, cerrar el chat donde la pegaste. Nada de eso la desactiva. La clave ya pudo copiarse, y mientras siga viva sirve para gastar tu saldo, leer tus datos o mover tu infraestructura.
El dato que más me impresionó del informe State of Secrets Sprawl 2026 de GitGuardian: de los secretos que se filtraron en 2022, más del 64 % seguían funcionando en enero de 2026. Casi cuatro años después. La gente borró, se olvidó, y nunca revocó.
El orden que seguimos: de la filtración al control
Esta es la secuencia que usamos en My Store Digital. El orden importa: cada paso supone que el anterior ya está hecho.
| Paso | Qué hacer | Por qué en este orden | Tiempo aproximado |
|---|---|---|---|
| 1. Revocar | Rotar o eliminar la clave en el panel del proveedor y generar una nueva | Mientras la clave viva, todo lo demás es secundario | 5 minutos |
| 2. Revisar consumo | Mirar uso, facturación y registros del proveedor desde la fecha de la filtración | Saber si alguien la usó antes de que la cortaras | 15-30 minutos |
| 3. Buscar copias | Historial de git, copias de seguridad, configuraciones de MCP, logs, chats con la IA | La clave casi nunca está en un solo sitio | 30-60 minutos |
| 4. Reemplazar bien | La clave nueva va en un gestor de secretos o en variables del servidor, nunca en el código | Si la vuelves a poner igual, se vuelve a filtrar | 15 minutos |
| 5. Limitar | Topes de gasto, permisos mínimos y una clave por cliente y por herramienta | Para que la próxima filtración cueste poco | 30 minutos |
| 6. Documentarlo | Qué pasó, dónde estaba la clave y qué cambió | La regla que no se escribe se olvida | 10 minutos |
Los tiempos son de un caso sencillo: una clave, un proveedor. Si la clave daba acceso a datos de clientes, el paso 2 se vuelve una investigación y probablemente una obligación legal de avisar.
¿Por qué la IA hace que esto pase más seguido?
Porque escribe código muy rápido, con acceso a todo lo que tiene alrededor, y nadie revisa línea por línea lo que produce.
Las cifras del mismo informe de GitGuardian, sobre commits públicos en GitHub durante 2025:
- 28,65 millones de secretos nuevos expuestos, un 34 % más que el año anterior.
- 1.275.105 secretos de servicios de IA, un 81 % más que en 2024.
- Los commits hechos con Claude Code mostraron una tasa de filtración del 3,2 %, frente al 1,5 % de base.
- 24.008 secretos únicos expuestos en archivos de configuración de MCP, el estándar con el que se conectan herramientas a los agentes.
Ese último número es el que más me toca, porque MCP es justo lo que todos estamos instalando. Cada servidor MCP que conectas suele pedir una clave, y la forma más cómoda de dársela es pegarla en un archivo de configuración. Ese archivo queda al alcance del agente, de las copias de seguridad y del próximo git add ..
Yo uso asistentes de código todos los días. No voy a decirte que no los uses. Te digo lo mismo que me dije a mí: si la clave está donde la IA puede leerla, tarde o temprano va a terminar donde no quieres.
¿Cómo manejamos las claves entre clientes?
Con una regla simple: una clave por cliente y por herramienta, y cada cliente en su propia instancia.
Esto no salió de un manual, salió de un error. Cuando montamos el agente de WhatsApp para un cliente, la primera versión reutilizaba mi clave de OpenRouter, la del modelo de IA. Funcionaba perfecto. Y cada respuesta automática que el agente le daba a los clientes de ese cliente se pagaba con mis tokens. Si esa clave se hubiera filtrado, el problema habría sido doble: mi saldo y el de su operación, mezclados en la misma llave.
De ahí salieron las reglas que aplicamos hoy:
- Instancia dedicada y aislada por cliente. Desde mayo de 2026, cada cliente que usa nuestro agente de WhatsApp tiene su propio despliegue, con volúmenes, usuario y credenciales propios. Las conversaciones de uno no tocan las de otro.
- Token por cliente y mensajes firmados. Cuando el agente habla con el Odoo de un cliente, lo hace con un token exclusivo de ese cliente, y los avisos que vuelven van firmados con HMAC. Si un token se filtra, revoco ese y los demás siguen funcionando.
- Agentes privados detrás de una puerta. Los agentes de IA privados que ofrecemos a clientes van en un contenedor por cliente, detrás de Cloudflare Tunnel y Cloudflare Access. No hay puerto abierto a internet esperando a que alguien adivine la dirección.
- Contraseñas del equipo en un gestor propio. Usamos Vaultwarden en
warden.mystoredigital.com, sobre infraestructura nuestra. Sirve para compartir un acceso sin revelarlo y para quitarlo al instante cuando alguien sale de un proyecto. - Los secretos nunca van como argumento de un comando. Quedan en el historial de la terminal y en la lista de procesos. Se leen ocultos y se escriben directo a un archivo con permisos restringidos. Esto lo conté con más detalle cuando monté un agente de IA autónomo en mi propio servidor.
¿Y los .env del principio? La recomendación que quedó escrita ese mismo día fue rotar todos los tokens expuestos, incluidos los de las copias con fecha, y pasar esas claves a un gestor de secretos. El agente que trabaja en esa carpeta puede leer todo lo que hay en ella, y con eso basta para tratarlas como expuestas.
¿Operar con infraestructura propia reduce la exposición?
Sí, porque te da control sobre tres cosas que en un SaaS no controlas: dónde vive cada secreto, quién puede verlo y cómo cortarlo.
Cuando la clave de tu CRM, tu modelo de IA y tu base de datos están pegadas en cinco plataformas distintas, cada una con su propio panel y su propio equipo de soporte, una filtración te obliga a recorrerlas todas sin saber bien cuál fue. Cuando la infraestructura es tuya, el mapa es tuyo. Sabes qué servidor habla con qué, con qué credencial, y puedes apagar una conexión sin abrir un ticket.
Pero seamos claros: tener servidor propio no te salva si guardas las claves igual de desordenadas. Mis .env estaban en mi propia máquina. La infraestructura propia reduce la exposición solo si viene con orden: inventario de claves, una por uso, permisos mínimos y un sitio único donde guardarlas.
Es la misma tesis que defiendo cuando hablo de soberanía digital: no se trata de desconfiar de todo, sino de saber qué es tuyo y poder llevártelo o cortarlo cuando quieras.
Lista corta para revisar tu operación hoy
Si conectas herramientas de IA a tu negocio, estas cinco preguntas te dicen en diez minutos dónde estás:
- ¿Sabes cuántas claves API tienes activas y en qué proveedores? Si la respuesta es "más o menos", empieza por ahí.
- ¿Alguna clave está compartida entre dos clientes, dos proyectos o dos herramientas?
- ¿Hay claves pegadas en archivos de configuración que un agente de IA puede leer?
- ¿Tus proveedores de IA tienen tope de gasto configurado?
- Si mañana se filtra una clave, ¿sabes en qué panel se revoca y cuánto tardarías?
Si alguna respuesta te incomodó, no es para asustarse. Es para poner orden antes de que el desorden te cueste.
Lo que me llevo
La IA está caminando a pasos agigantados y no me voy a bajar de ella. Pero cada herramienta que conecto es una puerta nueva, y una puerta sin llave propia es una puerta abierta.
Usa IA, todos los días si quieres. Solo conéctala sabiendo con qué llave, para qué y cómo la apagas.
¿Quieres que revisemos cómo están conectadas las herramientas de IA en tu operación y dónde viven tus claves? Hablemos.
Yoany Andrés My Store Digital
Preguntas frecuentes
¿Qué hago primero si una herramienta de IA filtró mi clave API?+
Revocar o rotar la clave en el panel del proveedor, antes que cualquier otra cosa. Borrar el archivo o el commit no sirve: la clave ya pudo copiarse, y mientras siga activa cualquiera puede usarla. Después revisas el consumo del proveedor para ver si alguien la usó y buscas en qué otros lugares estaba guardada.
¿Basta con borrar la clave de GitHub o del archivo .env?+
No. Una clave publicada hay que darla por comprometida aunque la borres a los cinco minutos, porque el historial de git, las copias de seguridad y los registros la conservan. Según GitGuardian, más del 64 % de los secretos filtrados en 2022 seguían siendo válidos en enero de 2026. Lo único que la neutraliza es revocarla.
¿Es más peligroso programar con asistentes de IA?+
Los datos dicen que sí, si no se pone orden. El informe State of Secrets Sprawl 2026 de GitGuardian encontró una tasa de filtración del 3,2 % en commits hechos con Claude Code, frente al 1,5 % de todos los commits públicos de GitHub. El asistente no filtra por sí solo: escribe rápido y con acceso a todo, y si las claves están a su alcance, terminan en el código.
¿Cómo deben manejarse las claves API cuando se trabaja con varios clientes?+
Una clave por cliente y por herramienta, nunca una compartida. Así, si una se filtra, revocas esa y no tumbas a los demás, y el consumo de cada cliente queda separado. En My Store Digital cada cliente tiene su instancia aislada y sus propias credenciales, y las contraseñas del equipo viven en un gestor propio que permite revocar acceso al instante.
¿Tener infraestructura propia elimina el riesgo de filtración?+
No lo elimina, lo reduce y lo vuelve controlable. Con servidor propio sabes dónde vive cada secreto, quién tiene acceso y puedes cortar una conexión sin depender de un tercero. Pero un archivo .env mal guardado en tu propio servidor es igual de peligroso: el orden importa más que la ubicación.
¿Listo para automatizar tu operación?
Auditamos tu stack en vivo y te decimos qué automatizar primero.
Agendar diagnóstico