El domingo 1 de noviembre, Trigger.dev —una plataforma de background jobs y automatización en la nube que usan muchos equipos de producto y agencias para correr workflows, cron jobs y pipelines— confirmó que un atacante obtuvo acceso no autorizado a las environment variables de un subconjunto de sus clientes. La empresa dice que ya bloqueó el exploit, que mandó correos a los account owners afectados con pasos de mitigación, y que irá publicando actualizaciones en su status page. Hasta ahí, es un incidente de seguridad más, de los que salen casi todas las semanas.
Lo que lo vuelve relevante hoy no es el hackeo en sí —Trigger.dev todavía no ha dicho cuántas organizaciones fueron afectadas ni cuál fue la causa raíz exacta, y no vamos a especular sobre eso— sino que llega literalmente días después de que GitGuardian publicara su reporte anual "State of Secrets Sprawl 2026", que documenta con números por qué este tipo de exposición se está volviendo la norma, no la excepción, justo en el momento en que más equipos escriben código con ayuda de agentes de IA.
Qué sabemos (y qué no) del incidente de Trigger.dev
Lo confirmado hasta ahora, directo del propio aviso de la empresa:
- Qué se expuso: environment variables —las credenciales, API keys y connection strings que una app necesita en tiempo de ejecución— de un subconjunto de organizaciones clientes.
- Qué hizo la empresa: bloqueó el exploit usado en el ataque, notificó por correo a los dueños de cuenta afectados con instrucciones de mitigación, y abrió una página de status (status.trigger.dev) para seguir publicando novedades.
- Qué todavía no sabemos: el número exacto de organizaciones afectadas y la causa raíz del exploit. Si Trigger.dev publica un post-mortem más detallado en los próximos días, vale la pena revisarlo —la mayoría de incidentes de este tipo terminan siendo un token con permisos demasiado amplios, una dependencia de terceros comprometida, o un endpoint interno expuesto por error de configuración.
El patrón detrás: los coding agents están acelerando la fuga de secrets
Aquí es donde el reporte de GitGuardian deja de ser una estadística más de ciberseguridad y se vuelve relevante para cualquiera que esté usando IA para escribir o desplegar código en 2026:
- Se detectaron 28.6 millones de secrets nuevos en commits públicos de GitHub durante 2025 —un crecimiento del 34% año contra año, y 152% más que en 2021.
- De los secrets válidos detectados en 2022, el 64% seguía activo y explotable cuatro años después en repositorios públicos. Esa proporción sube con cada año más reciente: 66%, 70%, hasta 77% para los detectados en 2025.
- Y el dato que más debería preocupar a cualquier agencia o equipo de producto que use Claude Code, Copilot o un agente similar: se expusieron 1,275,105 secrets de servicios de IA, un salto de 81% año contra año, y los commits asistidos por agentes de IA filtran secrets al doble de la tasa del resto de los commits en GitHub público.
El reporte también encontró 24,008 secrets únicos expuestos específicamente en archivos de configuración de MCP (Model Context Protocol) —el estándar que conecta agentes de IA con herramientas externas—, con API keys de Google (19.2%) y connection strings de PostgreSQL (14%) como los tipos más comunes.
Las pipelines de CI/CD, no las laptops, son el nuevo blanco
El mismo reporte, analizando el ataque a la cadena de suministro conocido como Shai-Hulud 2, encontró algo que cambia dónde debería estar la alerta de cualquier equipo técnico: 59% de las máquinas comprometidas eran CI/CD runners, no laptops de desarrolladores. Y 44% de esas máquinas comprometidas tenían guardados más de 10 secrets distintos; 5% tenía más de 100.
Eso importa porque la mayoría de los equipos —agencias incluidas— siguen tratando la seguridad de secrets como un problema de "no subas tu .env a GitHub", cuando el riesgo real ya se mudó a la infraestructura compartida: el runner de CI/CD que despliega para cinco proyectos de clientes distintos, la cuenta de automatización que corre workflows de un lado a otro, el servicio tipo Trigger.dev que orquesta jobs en nombre de decenas de organizaciones.
Por qué casi nadie rota sus secrets, aunque sepa que debería
GitGuardian también midió algo que casi ningún equipo quiere admitir: la tasa de rotación de secrets expuestos se mantiene entre 23% y 36%, dependiendo del año. Es decir, la gran mayoría de las credenciales que se filtran nunca se cambian después. El reporte lo resume sin rodeos: "Teams can't rotate secrets without risking production outages—so they don't" ("los equipos no pueden rotar secrets sin arriesgar caídas en producción —así que no lo hacen"). Un dato adicional conecta directo con el incidente de Trigger.dev: los repositorios internos (no públicos) tienen 6 veces más probabilidad de contener secrets hardcodeados que los públicos —32.2% contra 5.6%—, precisamente porque nadie los está vigilando con la misma atención.
Lo que esto significa para agencias, developers y tu producto
Si tu equipo —interno o de cliente— usa agentes de IA para escribir código, o depende de plataformas de automatización tipo Trigger.dev, Vercel, GitHub Actions o similares, esto no es una nota de ciberseguridad ajena a tu trabajo del día a día:
- Audita qué vive en texto plano. No solo en tu código: en los archivos de configuración de MCP, en los secretos que tus agentes de IA pueden leer o escribir, y en cualquier servicio de automatización que corra en nombre de un cliente.
- Trata la rotación de secrets como mantenimiento, no como respuesta a incidente. Si tu única política de rotación es "rotar cuando algo se hackea", ya vas tarde —el 70%+ de los secrets filtrados sigue vivo años después.
- Dale el mismo escrutinio a tu infraestructura compartida que le das a tu código. El runner de CI/CD o la plataforma de orquestación que usas para automatizar entregas a varios clientes es, hoy, un blanco más atractivo que cualquier laptop individual.
- Si usas AI coding agents en proyectos de clientes, dilo en tu propuesta de seguridad. No para asustar a nadie, sino porque el dato de GitGuardian (2x más fugas en commits asistidos por IA) es exactamente el tipo de riesgo que un cliente regulado va a preguntar tarde o temprano —mejor que la respuesta ya esté lista.
Ninguna de estas prácticas es nueva. Lo que cambió en 2026 es la velocidad: con agentes de IA escribiendo y desplegando código más rápido que nunca, un mal hábito de manejo de secrets que antes tardaba meses en volverse un problema ahora puede volverse un incidente en una tarde.
¿Quieres que auditemos cómo tu equipo o tu stack de automatización maneja secrets y credenciales antes de que se vuelva un problema? Escríbenos a hello@geekvibes.agency.
