Dónde acaban las contraseñas, claves y tokens de tus agentes de IA y automatizaciones, qué piden ISO 27001, ISO 42001, NIS2 y ENS y cómo controlarlas.
Por Alex Fernández, Auditor Líder ISO/IEC 27001 e ISO/IEC 42001 · Actualizado el
Las credenciales de tus agentes de IA y automatizaciones (claves de API, tokens y contraseñas de cuentas de servicio) acaban en ficheros de configuración, dentro de las plataformas de automatización o en el portátil de quien las montó, muchas veces sin dueño, sin caducidad y fuera de cualquier inventario. Se controlan como cualquier identidad: inventariadas, en un gestor de secretos, con permisos mínimos, rotación, baja y registro. Aquí va dónde las busco, qué piden las normas y un método.
No es un problema nuevo: los gestores de secretos llevan más de una década en el mercado (HashiCorp Vault y Azure Key Vault salieron en 2015). Lo nuevo es la escala y quién las crea: cualquiera que conecte un asistente o monte un flujo, sin pasar por sistemas.
Un secreto es cualquier dato que da acceso por sí solo: una clave de API, un token OAuth, la contraseña de una cuenta de servicio, una cadena de conexión o una clave privada. Quien lo copia, entra con sus permisos.
Una identidad no humana es la cuenta con la que entra una máquina: una integración, un script, una automatización o un agente de IA. OWASP les dedicó un Top 10 propio en diciembre de 2024.
| Dónde | Por qué preocupa | Cómo lo busco |
|---|---|---|
| Ficheros .env y código | Viajan con el proyecto y quedan en el historial | Un escáner de secretos sobre los repositorios, historial incluido |
| Configuración de los clientes MCP | El servidor local toma la clave del entorno y suele quedar escrita en claro | Abro esos ficheros en los equipos de quien usa agentes |
| Plataformas de automatización (n8n, Make, Zapier, Power Automate) | Las de cada flujo, normalmente de quien lo montó, y todas en un sitio | La lista de credenciales o conexiones, con su propietario |
| Instrucciones de asistentes personalizados (GPT, Copilot Studio) | La clave queda en un contexto que se puede sacar con preguntas | Abro cada asistente y busco key, token o password |
| Historial del chat y registros | Quien pega una clave para depurar un error la deja guardada | Patrones de claves en chats y tickets exportados |
| Variables de la integración continua | Claves de nube y tokens de publicación: un objetivo en sí | Qué secretos tiene cada repositorio y quién puede leerlos |
| Hojas y documentos compartidos | Las encuentra cualquiera con acceso, persona o asistente | Busco password, api key o token en el almacenamiento |
| El gestor personal de quien lo montó | Si se va, la integración se rompe o sigue con su acceso | Quién creó cada integración, cruzado con las bajas |
Según el informe de GitGuardian de marzo de 2026, en 2025 aparecieron 28,65 millones de secretos nuevos en GitHub público (un 34 % más), los de servicios de IA crecieron un 81 % y en ficheros de configuración de MCP contó 24.008, 2.117 de ellos válidos. Y cerca del 28 % de sus incidentes nació fuera del código, en Slack, Jira o Confluence.
La especificación de MCP deja la autorización como opcional e indica a los servidores locales que lean las credenciales del entorno: de ahí tantas claves en configuraciones. Y un asistente conectado puede buscarlas por orden de otro: en la prueba de concepto AgentFlayer (Zenity, agosto de 2025), un documento con instrucciones ocultas llevó a ChatGPT a sacar claves de API de un Google Drive.
Estas normas son anteriores a MCP, pero sus controles valen para cualquier identidad. El cruce es mío, de auditor, no un mapeo oficial.
| Norma | Referencia | Qué pide, en una línea | Qué evidencia enseñaría |
|---|---|---|---|
| ISO/IEC 27001:2022 | 5.16 Gestión de identidades, 5.17 Información de autenticación y 5.18 Derechos de acceso | Cada identidad, también de máquina, con alta, revisión y baja, y sus secretos custodiados | Inventario de identidades no humanas con dueño, secreto y última revisión |
| ISO/IEC 27001:2022 | 8.2 Derechos de acceso privilegiados, 8.5 Autenticación segura, 8.15 Registro de eventos, 8.24 Uso de la criptografía y 8.28 Codificación segura | Permisos altos restringidos, autenticación robusta, registros sin credenciales, claves gestionadas y ningún secreto en el código | Alcance de cada token, muestra de registros e informe del escáner de secretos |
| ISO/IEC 42001:2023 | A.4.2, A.4.4 y A.4.5 (recursos); A.6.2.5, A.6.2.6 y A.6.2.8 (despliegue, operación y registro de eventos) | Documentar herramientas y conectores, y operar y registrar el sistema con control | Ficha de cada agente con conectores, credenciales y registros |
| ISO/IEC 42001:2023 | A.10.2 Asignación de responsabilidades y A.10.3 Proveedores | Repartir responsabilidades con proveedores de modelos, conectores y servidores MCP | Quién responde de cada conector de terceros |
| NIS2, Directiva (UE) 2022/2555 | Art. 21.2 i) y j) | Control de acceso y gestión de activos; autenticación multifactor o continua cuando proceda | Política de acceso que nombre las identidades no humanas |
| Reglamento de Ejecución (UE) 2024/2690 | Anexo, 11.5 y 11.6 | Solo ciertas entidades digitales: identidades únicas, información de autenticación secreta gestionada y cambio de credenciales ante sospecha de compromiso | Aprobación de identidades compartidas y procedimiento de cambio |
| ENS, Real Decreto 311/2022 | op.acc.1 Identificación, op.acc.5 y op.acc.6 Mecanismo de autenticación y op.exp.10 Protección de claves criptográficas | Identificador singular para cada entidad, procesos incluidos; credenciales revocables; claves protegidas en todo su ciclo | Cuentas de servicio con identificador y dueño, y una revocación documentada |
| AI Act, Reglamento (UE) 2024/1689 | Art. 15.5 | Solo alto riesgo: resistir a terceros que intenten alterarlo aprovechando vulnerabilidades | Sus medidas, desde el 2 de diciembre de 2027 (anexo III) o el 2 de agosto de 2028 (anexo I) |
El ENS no tiene una medida propia para cuentas de servicio ni claves de API: entran como «procesos». El Reglamento 2024/2690 solo concreta estas medidas para ciertas entidades digitales, como los proveedores de DNS, nube, centros de datos y servicios gestionados o de seguridad gestionados, los mercados en línea o los servicios de confianza. Y el AI Act no habla de credenciales: unir su artículo 15.5 con los secretos es una interpretación, y las fechas son las del Ómnibus, el Reglamento (UE) 2026/1744.
¿NIS2 te alcanza? Lo explico en la guía para pymes; el ENS tiene la suya. Estos controles se justifican en la declaración de aplicabilidad y, si te los pregunta un cliente, se contestan como en la guía del cuestionario de seguridad.
Empresa ficticia: una asesoría de unas 40 personas, con un técnico de sistemas. Cuatro credenciales de su inventario:
| Credencial | Dónde estaba | Riesgo | Dónde va | Controles | Evidencia |
|---|---|---|---|---|---|
| Permiso del asistente sobre SharePoint | Lo concedió una empleada, con acceso a todos los sitios | Ve todo lo que ve ella, incluida la hoja de accesos | Consentimiento del administrador y acceso solo a las bibliotecas que necesita | 5.18 y A.4.4 | Permisos concedidos, con alcance y dueño |
| Correo y CRM en un flujo de Make | Cuentas del comercial que lo montó; clave del CRM de administrador | Si se va, el flujo se rompe o sigue con su acceso | Buzón de servicio de solo lectura y clave del CRM que solo crea contactos | 5.16, 5.17, 8.2 y A.6.2.6 | Credenciales de la plataforma con dueño y fecha de rotación |
| Token del servidor MCP del técnico | En claro en su configuración, con acceso a toda la herramienta de tickets | Un infostealer lo copia; una instrucción oculta en un ticket lo usa | Token de corta duración y alcance mínimo, desde el gestor | 8.2, 8.5, A.4.4 y A.10.3 | Configuración sin claves en claro y caducidad del token |
| Clave de API del proveedor de modelos | En un script que resume expedientes, subido al repositorio | Fuga por el repositorio y gasto sin límite | En el gestor, una por proyecto, con límite de gasto | 8.28, 5.17 y A.4.5 | Informe del escáner y límite configurado |
La fila 2 es la que más trabajo da: la credencial era de una persona y, con un buzón de servicio, su baja ya no rompe el flujo ni deja una puerta abierta.
Opciones, sin orden de preferencia: Keeper Secrets Manager, con servidor MCP oficial desde julio de 2025 en el que el agente solo ve las carpetas asignadas; 1Password, que en marzo de 2026 lanzó Unified Access para descubrir agentes y secretos expuestos; Bitwarden Secrets Manager, de código abierto; HashiCorp Vault, y las bóvedas de Azure, AWS y Google Cloud. No recomiendo marca: si todo vive en una nube, empieza por la suya.
Salvik no guarda secretos, pero en su inventario de sistemas de IA puedes anotar cada agente con su responsable; entra en la prueba de 7 días.
Si quieres hacerlo acompañado, en la consultoría de IA dejo agentes y automatizaciones con permisos mínimos y registro desde el primer día, y el resto de lo que hago está en servicios. Cómo reviso un agente, en la guía para auditar un agente de IA, y el marco completo, en qué es la ISO 42001 y cómo se certifica.
En tu equipo, para desarrollar y fuera del repositorio, sí. En producción, no: el .env no cifra nada, viaja con el proyecto y lo lee cualquier programa que corra con tu usuario, también un infostealer. Que guarde referencias al gestor, no valores.
Ningún control es solo para máquinas, pero estos valen para cualquier identidad: 5.16 (identidades), 5.17 (información de autenticación), 5.18 (derechos de acceso), 8.2 (accesos privilegiados), 8.5 (autenticación segura) y 8.28 (codificación segura). El auditor pedirá ver dónde están las credenciales, quién responde de cada una y cuándo se revisaron.
Si el servidor es remoto y lo admite, con OAuth: la especificación exige tokens emitidos para ese servidor y prohíbe reenviarlos a otras API. Si es local, lee las credenciales del entorno: que salgan del gestor al arrancar, con alcance mínimo, y nunca escritas en la configuración.
El de contraseñas es para personas; el de secretos, para máquinas que piden una credencial sin nadie delante, con API, rotación y registro. Si tus agentes leen claves del gestor personal de alguien, te falta el segundo.
La ISO 27001 no fija plazo: lo decides por riesgo y lo escribes. Rota en el acto si la clave se expone o se va quien la conocía, y prefiere credenciales que caducan solas: OWASP cuenta los secretos de larga duración entre los diez riesgos de identidades no humanas (NHI7).