En el interior de cada desarrollador se libra una guerra. Por un lado, el ello: la fuerza creativa e impulsiva que quiere codificar a la velocidad del pensamiento y prefiere desplegar primero y preguntar después. Por otro, el superyó: la voz que quiere probar cada línea de código y retrasaría un lanzamiento un mes si con ello se detectara un error más. Los desarrolladores experimentados actúan como árbitros entre ambas fuerzas, pero los novatos o sobrecargados suelen dejar que el ello tome el volante, lo que provoca, entre otras cosas, la filtración accidental de secretos de desarrollador: claves API y SSH, credenciales sin cifrar y tokens de autenticación. Llamar a estos secretos "las llaves del reino" es un cliché, pero no hay otra expresión que capture mejor su poder.

Quienes más aprecian ese poder son los actores maliciosos. Atacantes rastrean continuamente la web en busca de estos secretos, y su popularidad crece: Dark Reading reportó picos recientes en el escaneo de archivos de entorno y configuración de Git. Los secretos no tienen que estar en repositorios públicos para verse comprometidos; los desarrolladores los comparten a través de mensajes directos en Slack o tickets de Jira, y las claves SSH sin cifrar son lo primero que los atacantes buscan en un portátil corporativo comprometido. Con ellos pueden exfiltrar datos, moverse lateralmente, implantar ransomware o alterar código.

Los secretos expuestos son uno de los riesgos más peligrosos basados en credenciales, y el problema ya era epidémico antes de la llegada de los asistentes de código con IA. Ahora empeora a un ritmo que debería encender todas las alarmas. Según el informe 'The State of Secrets Sprawl 2025' de GitGuardian, se encontraron casi 24 millones de secretos hardcodeados en repositorios públicos de GitHub, un 25% más que el año anterior. No toda la culpa es de la IA; hay más personas aprendiendo a programar y cometiendo errores de novato. Sin embargo, los asistentes de IA tienen una conocida tendencia a exponer secretos, y los desarrolladores que dependen de ellos pueden estar presionados para entregar rápido y demostrar que aprovechan la productividad de la IA. GitGuardian señala que los repositorios donde está presente Copilot tienen un 40% más de probabilidades de contener secretos filtrados que los repositorios sin IA.

Como profesional de seguridad y entusiasta de la IA, el autor está personalmente comprometido con abordar este problema. En sus más de dos años experimentando con LLMs, los entiende como un acelerador de su ello creativo: por fin puede trabajar a la velocidad de sus pensamientos, lo que encuentra liberador y estimulante. Pero tiene suerte: cuenta con años de experiencia y una cultura laboral que no le presiona para producir commits más rápido de lo que se siente cómodo. Su equipo prueba todo rigurosamente y fomenta la transparencia sobre el uso de IA generativa para estar alerta ante alucinaciones y errores.

Muchos otros ingenieros no tienen esa suerte. No han desarrollado ese superyó vigilante que les advierte que traten con cautela el código generado por IA, y quizá no tienen desarrolladores seniors que les recuerden que 'el código en tu repositorio privado está a una mala configuración de hacerse público'. Sin estas salvaguardas, el goteo constante de secretos filtrados se convierte en un torrente.

¿Cómo frenar la marea?

Desarrollando un superyó de seguridad tan potente y empoderado como el ello de la IA. Parte de la solución está en usar herramientas automatizadas de detección de secretos ya disponibles; las pruebas pre-commit detectan muchos secretos antes de que se expongan. Pero muchos secretos no tienen una estructura fácilmente identificable. GitGuardian encontró que en 2024, el 58% de los secretos detectados eran los llamados 'secretos genéricos', que pueden eludir las herramientas automatizadas.

Para impedir que esos secretos salgan, las soluciones son tanto culturales como técnicas. Por ejemplo, es vital desalentar firmemente que los ingenieros almacenen secretos en sus discos duros o los compartan a través de plataformas como Slack, y ofrecerles alternativas seguras y cifradas para almacenar y compartir credenciales. Asimismo, hay que proporcionar a los desarrolladores las mejores herramientas de IA propiedad de la empresa para incentivar su uso transparente, en lugar de que experimenten con IA no autorizada. En el caso de la IA agente, la seguridad de las credenciales debe estar integrada para que los agentes tengan aprovisionados de forma segura los secretos que necesitan, pero esos secretos estén ofuscados para que los agentes nunca interactúen directamente con ellos.

Por último, los desarrolladores seniors y los líderes de ingeniería deben actuar como los egos arbitrales de sus organizaciones e insistir en una revisión rigurosa del código para identificar credenciales expuestas, incluido (pero no limitado a) el código generado por IA. Tomar estas medidas es cómo abrazamos la IA sin servir a los actores maliciosos una cornucopia de credenciales expuestas. También es cómo formamos a la próxima generación de talento desarrollador para que sueñen a lo grande mientras prestan atención a los detalles. Al final, tanto los desarrolladores como las organizaciones necesitan tanto su ello como su superyó para prosperar, así que desarrollemos las herramientas y las culturas para nutrir a ambos.

Jason Meller, vicepresidente de producto en 1Password, fundador de Kolide y autor de 'honest.security': 'Los secretos de desarrollador expuestos son uno de los riesgos más peligrosos basados en credenciales, y la IA los está empeorando exponencialmente. Necesitamos un superyó de seguridad tan potente como el ello de la IA.'