Caja fuerte de secretos: su IA usa las claves sin verlas

Un pequeño ejercicio antes de empezar. Abra su correo, escriba «contraseña» en la barra de búsqueda y mire lo que aparece. Adelante, le espero.

¿Y bien? ¿Un acceso de administrador enviado hace dos años «mientras tanto», una clave de API pegada en un chat del equipo, una hoja de cálculo «Accesos» compartida con media empresa? Tranquilo, está usted en buena compañía. Según el informe 2026 de GitGuardian sobre la dispersión de secretos, el 28 % de las fugas de secretos se producen exclusivamente fuera de los repositorios de código, en las herramientas de colaboración y productividad. Los secretos, en la jerga, son todas esas contraseñas, claves de API y tokens de acceso que abren sus herramientas a una persona o a una máquina.

Hasta ahora, el problema era sobre todo humano. Con los agentes de IA, cambia de escala: se les confían claves para que trabajen solos, y un agente lo lee todo, lo copia todo y a veces obedece a cualquiera. Este texto de nuestra sección IA empresarial cuenta las fugas que hemos encontrado en los últimos meses, lo que la IA cambia en ellas y la solución que proponemos: una caja fuerte cuyas claves conserva usted y que su IA usa sin verlas nunca. Y que ni siquiera nosotros abrimos. Adelanto: la respuesta no es esconder la llave debajo del felpudo.

En resumen

• Los secretos se filtran por todas partes: 28,65 millones de nuevos secretos escritos en claro en GitHub público en 2025, un 34 % más en un año. Las claves de servicios de IA expuestas se dispararon un 81 %.
• Una clave expuesta lo sigue estando mucho tiempo: el 64 % de los secretos válidos detectados en 2022 seguían funcionando cuatro años después.
• Los agentes de IA cambian la escala del riesgo: un agente que lee una clave puede repetirla, copiarla o dejársela sonsacar por una instrucción trampa.
• La defensa cabe en un principio: el agente pide una acción, un relé añade la clave en el momento de la llamada y el modelo no la ve nunca.
• La caja fuerte está a su nombre, nuestros accesos desaparecen en la entrega y cada clave que hayamos podido ver durante el proyecto se cambia.

¿Dónde andan sus contraseñas y sus claves de API?

En todas partes donde resultaba práctico en el momento. Esa es toda la mecánica de la fuga: nadie decide publicar una clave. Acaba donde echa una mano, y se olvida.

Esto es lo que hemos encontrado en los últimos meses. Nada exótico, y eso es precisamente lo inquietante.

El triplete, en un solo proyecto. En julio, la auditoría de un proyecto que acompañamos sacó a la luz una clave de administración del CRM, con todos los permisos (leer, modificar, eliminar), escrita en claro en un script guardado en el repositorio de código. El script tenía un nombre que prometía borrarlo todo, y la clave caducaba dentro de unos cien años. Previsor. La misma auditoría encontró un archivo de configuración local, que debía quedarse en el equipo de un desarrollador, seguido por el historial del repositorio. Y este otoño, al rehacer el inventario técnico del mismo proyecto, dimos con la contraseña de administrador de una herramienta, escrita con todas sus letras en una guía de instalación guardada junto al código.

El remedio es siempre el mismo:

Recuerde la regla: una clave que ha sido visible es una clave muerta.

La cadena de publicación en verde que no publicaba nada. En otro cliente, a la cadena de publicación automática le faltaban sus secretos. Resultado: todo aparecía en verde, nada se publicaba y nadie se daba cuenta. Un secreto mal guardado no siempre hace ruido al caer.

¿Y en nuestra casa? El día en que decidimos ejecutar todos nuestros agentes en la nube en lugar de en un ordenador, algunas claves vivían todavía en un archivo en el equipo del fundador. Basta con que falle una sola máquina para que nadie sepa dónde están las claves ni cuáles cambiar. Los agentes, en cambio, ya no podían leerlas, y mejor así: una clave que el agente nunca ha visto es una clave que no puede filtrar. Todo lo que sigue parte de ahí.

La ANSSI, la agencia francesa de ciberseguridad, ya lo había dicho todo en una línea en octubre de 2021, en sus recomendaciones sobre autenticación y contraseñas:

Difícil ser más claro.

¿Por qué los agentes de IA cambian la escala del problema?

Una persona que tiene una contraseña delante no se la recita a un desconocido (por lo general). Un agente de IA, sí. No por malicia: lee todo lo que se le da, ejecuta instrucciones y no siempre distingue las suyas de las que algún listillo ha colado en un correo o un ticket. Si el funcionamiento de un agente todavía le resulta confuso, nuestro artículo sobre el bucle de un agente de IA lo desmonta pieza a pieza.

Tres historias reales, para situarse.

Cuando el ataque pone a trabajar a la IA de la víctima. El 26 de agosto de 2025 se publicaron versiones trampa de Nx, una herramienta de desarrollo muy extendida. Según el análisis de Wiz, el código malicioso pedía a los asistentes de programación instalados en la máquina, con las opciones que desactivan sus salvaguardas, que registraran el disco en busca de monederos de criptomonedas, claves SSH y archivos de configuración. El balance, en dos oleadas:

La IA no era la vulnerabilidad. Sirvió de perro trufero.

Cuando el agente copia las claves en un ticket. En julio de 2025, investigadores de General Analysis demostraron, y Simon Willison lo contó, cómo un agente de programación conectado a una base de datos con permisos de administrador podía ser engañado con un simple ticket de soporte. El ticket contenía instrucciones ocultas. Al leerlo, el agente podía copiar el contenido de una tabla de tokens de integración en una respuesta visible para el atacante. Es una demostración, no un incidente, pero el escenario es de una banalidad que da escalofríos. Simon Willison le dio un nombre:

Cuando una clave de IA robada puede costar 46 000 dólares al día. En mayo de 2024, el equipo de investigación de Sysdig describió el «LLMjacking»: atacantes que roban credenciales de nube para usar modelos de IA alojados, y revender el acceso, a costa de la víctima. En el peor caso calculado por Sysdig, la factura supera los 46 000 dólares de consumo al día. Una clave de IA que anda por ahí es una tarjeta bancaria pegada con cinta en el escaparate. Y la IA de gama alta no va camino de abaratarse: la suscripción más cara de ChatGPT ha pasado de 20 a 500 dólares al mes en tres años y medio.

Las cifras apuntan en la misma dirección. También según GitGuardian, los commits coescritos por un asistente de programación muy extendido filtran secretos aproximadamente el doble de veces que la media (sí, nosotros también usamos uno: razón de más para no confiarle nunca una clave). La OWASP, la fundación de referencia en seguridad de aplicaciones, saca la conclusión en su clasificación 2025 de los riesgos de las aplicaciones de IA: ninguna clave de API en las instrucciones de un modelo, y los controles críticos, como la separación de privilegios, «must not be delegated to the LLM» (no deben delegarse en el LLM). Dicho de otro modo: no le pida a la IA que guarde un secreto. Haga que no tenga ninguno.

¿Cómo puede una IA usar una clave sin verla?

Es la clave del asunto (perdón), y es más sencillo de lo que parece.

Piense en el conserje de un edificio. Usted le dice «deje subir al repartidor al cuarto». Él abre con su llave maestra, el repartidor deja el paquete y se va: nunca ha tenido la llave maestra en la mano. Y si insiste muy educadamente en visitar el quinto, el conserje se niega.

Con un agente de IA, el conserje se llama relé, y todo ocurre en cuatro tiempos:

1. El agente pide una acción: «envía este presupuesto por correo».
2. El relé, situado entre el agente y el servicio, comprueba que ese agente tiene derecho a hacerlo.
3. El relé toma la clave de la caja fuerte y la añade a la solicitud en el momento en que sale, únicamente hacia la dirección del servicio previsto.
4. El servicio responde. El agente recibe el resultado, nunca la clave, y el registro anota quién hizo qué, con qué clave y cuándo.

El modelo de IA solo ve pasar la acción y el resultado. La clave solo hace el trayecto de la caja fuerte al servicio.

Resultado: aunque lo engañe una instrucción oculta en un documento, el agente no tiene nada que repetir. Tampoco puede enviar la clave a otro sitio, ya que el relé solo la añade hacia el servicio previsto. El trío letal pierde una pata. Y no es ciencia ficción: así trabajan ya nuestros propios agentes cuando publican código. La clave la añade por el camino la capa de red, y nunca entra en su entorno de trabajo.

Lo que proponemos, en concreto

No vendemos un software más. Instalamos en su casa una caja fuerte probada, conectamos a ella sus herramientas y su IA, y luego le entregamos las llaves. Con estos compromisos:

• La caja fuerte está a su nombre. En su servidor o en un proveedor de alojamiento en Europa, pero siempre a su nombre. Usted es el administrador, y si cambia de proveedor, la caja fuerte y todo su contenido siguen siendo suyos.
• Ni siquiera nosotros tenemos acceso. Es lo que más sorprende. En la entrega se retiran nuestros accesos, y cada clave que hayamos podido ver durante el proyecto se cambia: lo que vimos ya no vale nada. ¿Nos necesita más adelante? Usted abre un acceso limitado en el tiempo, y el registro lo deja anotado.
• Su IA las usa sin verlas. El principio del conserje, aplicado a sus agentes y a sus automatizaciones.
• Cada uno solo ve lo que le concierne. Una identidad por persona, por automatización y por agente, con sus propios permisos. ¿Se va un proveedor? Usted corta su acceso sin tocar los demás.
• Una clave cambiada una vez está actualizada en todas partes. La caja fuerte alimenta sus herramientas, su alojamiento y sus cadenas de publicación. Se acabó la caza de copias en diez archivos.
• Un registro que responde en pocos minutos. Quién usó qué clave, cuándo y desde qué herramienta. El día que surja una duda, tendrá una respuesta en lugar de una investigación.
• Nada de cifrado casero. El núcleo de la caja fuerte es un software libre probado, cuyo código es público. Nuestro trabajo es la instalación, las conexiones y la entrega de llaves. No reinventamos la cerradura.
• Un plan de emergencia. Si pierde el acceso, un procedimiento escrito y probado con usted confía la recuperación a dos personas que usted designa. No guardamos ninguna copia: sería precisamente el acceso que le prometemos no tener.

El proyecto se desarrolla en cuatro etapas: el inventario de sus secretos y de las fugas ya existentes, la apertura de la caja fuerte a su nombre, la conexión de sus herramientas y sus agentes uno por uno, y la entrega de llaves. El alcance, los plazos y los precios están en nuestra página Caja fuerte IA. Y para que cada agente tenga también su presupuesto y sus límites, existe nuestro pack IA a su justo coste.

¿Por dónde empezar, incluso sin nosotros?

No hace falta esperar a un proyecto para detener la hemorragia. Cuatro gestos, en orden:

1. 01Haga el inventario.

   Correo, hojas de cálculo, repositorios de código, herramientas de automatización, equipos de trabajo: anote dónde viven sus contraseñas y sus claves, y quién tiene acceso a ellas.

2. 02Cambie toda clave que ya haya sido visible en algún sitio.

   No «ya veremos»: ahora. GitGuardian comprobó que el 64 % de los secretos válidos detectados en 2022 seguían funcionando cuatro años después. Los atacantes no los han olvidado.

3. 03No le dé nunca una clave a un modelo de IA.

   Ni en sus instrucciones ni en sus documentos. Dé a cada agente su propia identidad, con los permisos más estrechos posibles: nuestra guía sobre la gobernanza de la IA en la empresa detalla cómo repartir esos permisos.

4. 04Active la autenticación de dos factores en todas partes donde exista.

   Una contraseña robada ya no basta para entrar.

La caja fuerte forma parte de lo que todo nuevo proyecto debería encontrar al llegar, junto con las cuentas, los accesos y las copias de seguridad: nuestra guía sobre la base de una infraestructura en la nube hace el recorrido. Y para saber dónde deben funcionar sus modelos de IA según la sensibilidad de sus datos, nuestra comparativa de los cuatro niveles de IA privada presenta las opciones, desde la API del mercado hasta el servidor en su casa. Las demás decisiones, desde la tarea que confiar hasta el control humano, están en nuestra guía para integrar la IA en la empresa, en el orden en que se toman.

En resumen: el mejor secreto es el que nadie necesita conocer, ni siquiera su IA. Si quiere que revisemos cómo están los suyos, escríbanos.

Preguntas frecuentes

Fuentes

1. El informe 2026 de GitGuardian sobre la dispersión de secretos (nueva pestaña)gitguardian.com
2. Sus recomendaciones sobre autenticación y contraseñas (nueva pestaña)messervices.cyber.gouv.fr
3. El análisis de Wiz (nueva pestaña)wiz.io
4. Simon Willison lo contó (nueva pestaña)simonwillison.net
5. «LLMjacking» (nueva pestaña)sysdig.com
6. Su clasificación 2025 de los riesgos de las aplicaciones de IA (nueva pestaña)genai.owasp.org