Alerta: agentes de IA cazan tus claves en GitHub
Este artículo analiza un patrón, no una noticia de última hora: entre el 5 y el 7 de noviembre de 2026 han coincidido tres informes que apuntan al mismo problema. Los atacantes ya usan agentes de IA para rastrear GitHub en busca de claves, y los desarrolladores siguen dejando esas claves a la vista, a veces sin saberlo. La seguridad de tus credenciales depende hoy de lo rápido que las rotes.
Tres informes en tres días, una sola historia
El 6 de noviembre, Cybersecurity Dive resumió el informe del jueves de Microsoft Threat Intelligence: hay atacantes que usan Artex y otros marcos de IA agéntica para escanear repositorios públicos de GitHub en busca de credenciales y claves de API, que luego emplean en ataques contra organizaciones concretas. Desde el 28 de octubre, Microsoft detectó una única dirección IP que iniciaba sesión en inquilinos ajenos con credenciales de aplicación robadas pero todavía válidas.
El 5 de noviembre, Check Point Research publicó su análisis de ARTEX con datos de consolas de operador expuestas. Según el resumen de Gridinsoft del 7 de noviembre, un operador lanzó agentes contra diez tiendas grises de certificados de firma de iOS entre el 14 y el 29 de octubre, reunió más de 300 certificados con sus contraseñas y solo tres superaron las comprobaciones de validez. Ese dato tiene su lección: los agentes trabajan mucho, pero no siempre aciertan.
El tercer informe viene del otro lado de la mesa. El 7 de noviembre, The Hacker News recogió la investigación que Apiiro había publicado un día antes sobre el archivo .claude/settings.local.json de Claude Code: en repositorios públicos hay 1.122 copias con al menos un secreto. Un lado busca claves con máquinas; el otro las deja caer por descuido. Eso es el patrón.
Qué ha encontrado Apiiro exactamente
Conviene separar lo confirmado de lo que no lo está. Cuando un usuario elige «Yes, and don't ask again», Claude Code guarda una regla de permiso en ese archivo. Si la regla es un patrón, como npm test *, no hay problema. Si es el comando exacto, y el usuario había escrito en él una contraseña o un token, el secreto se guarda en texto plano.
Apiiro localizó 104.185 copias del archivo en 103.617 repositorios públicos. Un 1,1 % de ellas, las 1.122 citadas, contiene al menos un secreto, y en conjunto suman 1.379 secretos distintos. Si se añaden versiones antiguas del archivo, el archivo compartido settings.json y registros de chat de agentes, el total sube a 2.539 secretos en 1.994 repositorios. Más de un tercio de los secretos abre una base de datos; entre ellos hay una clave de nube de alto nivel y la contraseña de propietario de una base de datos de historiales médicos.
Lo que Apiiro no hizo es comprobar cuántos siguen funcionando. Tampoco hay evidencia publicada de que alguien los haya usado. Una empresa notificada esta semana confirmó que su clave estaba activa. Los investigadores señalan, además, que de 16 agentes de programación cuya documentación compararon, Claude Code es el único confirmado que guarda por defecto el comando completo aprobado en un archivo del proyecto.
El mecanismo de protección existe pero es frágil: según la documentación citada, Claude Code añade el archivo a las exclusiones globales de git del usuario. Esa exclusión vive en un ordenador y no viaja con el proyecto, porque nunca se añade al .gitignore del propio repositorio. En 539 de los 1.105 repositorios rastreados, un commit con Claude como coautor modificó el archivo, lo que sugiere que el agente lo confirma por su cuenta con frecuencia.
Borrar el archivo no arregla nada
Este es el punto que más gente entenderá mal. Las versiones antiguas permanecen en el historial de git y en los forks. Apiiro encontró 734 secretos adicionales en 509 repositorios que ya no aparecen en ninguna copia actual, normalmente porque el archivo se borró. Y 211 forks de 74 repositorios arrastran los mismos secretos que los originales.
Los datos de permanencia son todavía más incómodos. A fecha del lunes, todos los archivos con secretos seguían en la rama principal de su repositorio, y en la mitad de esos repositorios llevaban allí al menos 217 días. Nadie estaba mirando. Y ahí enlaza con el informe de Microsoft: las consultas de los atacantes buscan nombres de organizaciones objetivo junto con palabras clave de secretos, de servicios en la nube y de proveedores de IA.
Los escáneres habituales tampoco salvan la situación. Apiiro pasó gitleaks y TruffleHog sin su paso de verificación: de los 1.122 archivos con secretos, gitleaks marcó 564, TruffleHog 643 y ninguno de los dos detectó 215. Las contraseñas escritas dentro de comandos, como las que siguen a PGPASSWORD= o a mysql -p, parecen una palabra cualquiera.
Por qué el agente cambia la economía del ataque
Buscar secretos en GitHub no es nuevo. Lo que cambia es el coste de actuar sobre cada hallazgo. Según Microsoft, hay marcos agénticos escaneando GitHub en busca de secretos desde agosto. Gridinsoft, que cita otro informe de Microsoft del 5 de noviembre, recoge un caso en que pasaron cinco minutos entre la búsqueda de secretos de cliente y el robo de datos de Azure Key Vault. Ese dato procede de ese resumen y no lo he podido contrastar en el informe original.
Mi lectura, que es análisis propio y no un hecho documentado: la ventana entre «se publica una clave» y «alguien la prueba» se ha reducido de días a minutos, y esa ventana se mide hoy en tiempo de máquina. Si tu proceso de respuesta depende de que alguien revise un correo de alerta el lunes por la mañana, llegas tarde. Microsoft lo dice sin adornos: si una organización encuentra secretos expuestos en un repositorio público, debe asumir que están comprometidos.
Esto también es OSINT puro. Rastrear código público con términos de empresa, de proveedor y de servicio es una técnica de investigación en fuentes abiertas que los equipos de inteligencia competitiva y de seguridad ofensiva conocen bien. Lo nuevo es que la automatiza un agente que no se cansa ni cobra horas extra.
Qué hacer esta semana si usas agentes de programación
La lista de Apiiro y de Microsoft es corta y accionable. Estas son las medidas, en orden de prioridad:
- Rota primero, limpia después. Cambia toda contraseña, token y clave que el archivo haya contenido alguna vez. Eliminar el archivo sin rotar deja la credencial viva en el historial.
- Busca en tus repositorios públicos y en los de tu equipo la carpeta
.claude/, incluido el historial y los forks, con una búsqueda de texto sencilla en lugar de depender solo de un escáner. - Aprueba patrones, no comandos sueltos, como
Bash(npm run:*), y pasa los secretos por variables de entorno para que la regla guardada contenga el nombre de la variable y no su valor. - Añade
.claude/settings.local.jsonal.gitignoredel proyecto. La exclusión global del usuario no protege a sus compañeros ni al repositorio. - Revisa los registros de acceso de los servicios cuyas claves estuvieron expuestas, sobre todo inicios de sesión de aplicación desde IP desconocidas.
Para una pyme sin equipo de seguridad, el primer punto basta para recortar el riesgo con un par de horas de trabajo. Y conviene repetirlo con cualquier otro agente que guarde comandos o historiales: Apiiro solo confirmó este comportamiento por defecto en Claude Code, pero eso no significa que los otros 15 agentes estén libres de otras fugas.
Lo que no demuestran estos informes
Tampoco hay que exagerar. Apiiro no probó que los secretos fueran válidos ni que nadie los usara, y Cybersecurity Dive subraya que no está claro quién escanea GitHub. El caso de los certificados de iOS acabó con tres piezas útiles de más de 300, y según Check Point una campaña distinta entró en servicios de criptomonedas sin que llegara ni un céntimo al operador. Los agentes ofensivos fallan mucho, y sus informes de éxito necesitan verificación independiente, también para los atacantes.
La asimetría sigue favoreciendo al atacante, porque le basta con acertar una vez entre miles de intentos baratos. Al defensor le toca acertar siempre. Por eso la defensa seria no es escanear mejor, sino quitar el premio: claves de vida corta, permisos mínimos y rotación automática.
Valoración
El mensaje de la semana es incómodo para todos. Los proveedores de herramientas de IA deben proteger por defecto lo que el usuario escribe en una terminal, y los usuarios deben tratar cada repositorio público como un escaparate que otros máquinas leen en tiempo real. Mi posición: quien use agentes de programación y no haya rotado sus claves esta semana está apostando contra un adversario que ya no duerme.
En DAVMAC desarrollamos herramientas de inteligencia, análisis de datos y monitorización para empresas e instituciones; si quieres vigilar qué exposición pública tienen tu marca y tus repositorios, escríbenos.