Tu agente de IA tiene más permisos que tu becario. Y nadie le ha hecho un contrato.

Llevo más de diez años trabajando en seguridad e identidad, y últimamente hay una escena que se me repite en casi todas las conversaciones con equipos que están metiendo agentes de IA en producción. Alguien enseña una demo impresionante: el agente lee el correo, consulta la base de datos, cruza los datos, genera el informe, lo envía al destinatario correcto. Aplausos merecidos, porque la demo suele estar muy bien. Y entonces pregunto con qué credenciales ha hecho todo eso.

Silencio. La respuesta, cuando llega, suele ser alguna variante de “con las del usuario” o “con una API key que pusimos en la configuración al principio y ahí sigue”. El agente ha heredado la identidad completa de una persona, o lleva encima un secreto que se creó hace meses y que nadie ha rotado desde entonces. Funciona, claro que funciona. También funcionaba dejar la llave debajo del felpudo.

Quiero dedicar este artículo a explicar por qué eso que funciona es una bomba de relojería, qué arquitectura la desactiva, y por dónde empezaría yo mañana si tuviera que arreglarlo en una organización real, con su directorio corporativo de hace veinte años y sus equipos que ya han desplegado agentes sin esperar a que seguridad les diera permiso.

Los viejos problemas, con un actor nuevo

Los que venimos del mundo IAM conocemos de sobra el concepto de standing access: permisos que existen de forma permanente, se usen o no. Llevamos años peleando por reducirlos en identidades humanas, con resultados desiguales, revisiones de entitlements que se aprueban en bloque un viernes por la tarde, y recertificaciones que nadie lee. Todo eso es viejo. Lo que ha cambiado es quién ejerce esos permisos.

Con humanos existía un factor mitigante que nunca aparecía en la pizarra de riesgos, aunque todos contábamos con él en silencio: un empleado con permisos de más rara vez los descubre. Casi nunca sabe que puede leer esa carpeta de finanzas a la que le dieron acceso por error en 2019, y aunque lo sepa, tiene cosas mejores que hacer. La oscuridad ejercía de control compensatorio. A ninguno nos gusta admitirlo en voz alta, pero media industria del IAM ha vivido cómodamente sobre esa asunción durante dos décadas.

Un agente de IA se carga esa asunción en la primera tarea que le encargas. Un agente recorre sus permisos, los prueba, los encadena y los agota, a velocidad de máquina, cada vez que el objetivo que le has dado lo requiere. Si le pediste “consígueme todos los datos relevantes para este informe” y tiene acceso de más, va a usar el acceso de más, con la mejor de las intenciones, porque para eso lo has entrenado.

Y hay una segunda diferencia que me parece todavía más seria que la primera. En una aplicación tradicional, la lógica que decide qué hacer con una entrada es código determinista. Alguien lo escribió, alguien lo revisó, alguien lo testeó, y tiene un número finito de caminos que se pueden auditar. En un agente, la capa de decisión es un modelo de lenguaje interpretando texto. Cualquier texto. El documento que le has pedido que resuma. La página web que ha consultado para verificar un dato. El correo de un tercero que ha leído porque estaba en el hilo. Cada uno de esos textos puede contener instrucciones dirigidas al modelo, y el modelo, por diseño, está entrenado para seguir instrucciones.

Esto tiene nombre en la literatura de seguridad desde los años ochenta: el confused deputy problem. Un componente con más privilegios que quien le solicita una acción acaba usándolos indebidamente porque alguien lo confundió. El ejemplo canónico era un compilador con permiso de escritura sobre un fichero protegido, engañado mediante un nombre de fichero malicioso. Cuarenta años después, el deputy es un LLM, y la manipulación ya viaja escondida en cualquier párrafo de lenguaje natural que el agente procese durante su jornada. El problema es venerable. La superficie de ataque es nueva, y es enorme.

Hagamos la cuenta del daño

En seguridad manejamos el término blast radius para hablar de cuánto daño puede causar una identidad comprometida. Merece la pena hacer la cuenta despacio para el despliegue típico de agentes que estoy viendo entrar en producción este año.

Punto de partida: agente con el contexto de sesión completo de un usuario, más una API key de larga duración para los sistemas que no soportan otra cosa. Llega el incidente, en forma de inyección de prompt escondida en un PDF que el agente procesa un martes cualquiera. ¿Qué tiene el atacante a partir de ese momento?

Tiene todos los permisos de esa persona, ejercidos con la diligencia infatigable de una máquina. Tiene credenciales que seguirán siendo válidas semanas o meses después del incidente, porque nadie las rota, y que probablemente se hayan copiado ya a algún sitio desde el que reutilizarlas con calma. Y tiene algo que como responsable de respuesta a incidentes me quita el sueño: unos logs que dicen que todo lo hizo el usuario legítimo. Porque el agente actuaba con su sesión, y en ningún registro de ningún sistema queda constancia de que hubiera un intermediario. El forense va a señalar a una persona inocente, y la organización va a tardar días en entender siquiera qué ha pasado.

Contrastémoslo con el escenario que defiendo en el resto del artículo. El mismo PDF malicioso, el mismo martes. Pero el agente opera con un token emitido para esa tarea concreta, con un alcance de solo lectura sobre un único sistema, con una audiencia que hace el token inservible contra cualquier otro destino, y con una vida de cinco minutos. El token, además, registra dos identidades: la del usuario en cuyo nombre se actúa y la del agente que materialmente ejecuta. El atacante consigue, en el peor de los casos, unos minutos de lectura sobre un sistema acotado, con toda la cadena de delegación escrita en cada registro. El incidente se investiga en una mañana y el informe forense cuenta la verdad.

La diferencia entre ambos escenarios no la marca la suerte ni la pericia del atacante. La marca la arquitectura que había debajo.

Cinco capas, porque cada una cubre lo que las otras estructuralmente ignoran

Cuando cuento esto, la reacción habitual es preguntarme qué producto lo arregla. Entiendo la pregunta, el mercado está lleno de vendedores encantados de responderla, y algunas de esas herramientas son buenas. Pero después de haber pasado años a ambos lados de esa conversación comercial, mi respuesta honesta es que aquí hay un modelo arquitectónico por construir, y las herramientas llegan después, cuando ya sabes qué capa cubre cada una. Voy con las cinco capas, de dentro hacia fuera, deteniéndome en cada una lo suficiente para que se entienda qué amenaza concreta ataja.

Capa 1 — El sandbox de ejecución. Cuando un agente necesita ejecutar código, esa ejecución ocurre en un contenedor efímero que se crea para esa tarea y se destruye al terminarla. Dentro del contenedor: salida de red cerrada salvo hacia destinos explícitamente permitidos, sistema de ficheros de solo lectura salvo un directorio temporal de trabajo, límites de CPU, memoria y tiempo, y ninguna credencial de larga duración horneada en la imagen. Ese último punto merece subrayarse, porque es el error que más veo: contenedores impecablemente aislados con una API key eterna dentro de una variable de entorno. Si el aislamiento cae, el atacante se lleva un secreto que sigue funcionando fuera. Tecnologías candidatas para esta capa: gVisor, Firecracker, las políticas nativas de Kubernetes. Lo que esta capa contiene es el radio de acción local, lo que el agente puede tocar en su propia máquina cuando algo se tuerce.

Capa 2 — Identidad y delegación. El corazón del modelo, y el terreno donde los que venimos de IAM tenemos más que aportar. La construyo sobre tres decisiones de diseño.

La primera decisión: el agente jamás guarda un secreto propio para autenticarse. Usa la identidad que su plataforma de ejecución ya le proporciona y atestigua — un service account de Kubernetes, una workload identity de nube — y la intercambia ante el proveedor de identidad por un token de corta duración. Suena a detalle menor y cambia todo el juego, porque elimina el problema de distribuir el primer secreto. Si no hay secreto de arranque, no hay secreto de arranque que filtrar en un repositorio, en un log o en una imagen.

La segunda decisión: el token que recibe el agente no es la sesión del usuario, es un derivado empequeñecido de ella. Alcance limitado a los permisos que la tarea concreta necesita, ni uno más. Audiencia restringida a un único sistema destino, de manera que ese token, interceptado, resulta inservible contra cualquier otro servicio de la casa. Vida de minutos, calibrada con la duración esperada de la tarea. El mecanismo formal para producir ese derivado existe y está estandarizado desde hace años, el intercambio de tokens del RFC 8693, y me sigue sorprendiendo lo poco que se implementa.

La tercera decisión, la que separa a quien ha pensado en el día después del incidente de quien no: el token transporta dos identidades simultáneamente. El campo de sujeto dice en nombre de quién se actúa, y el actor claim dice quién está actuando materialmente. Con eso, cada sistema downstream que reciba una llamada del agente sabe, y registra, que fue el agente X operando por delegación del usuario Y. Sin eso, volvemos al forense señalando a inocentes.

Queda el mundo real, donde media empresa corre sobre sistemas que no hablan protocolos modernos de identidad. Una base de datos quiere un usuario y una contraseña, no un token con claims. Para ese mundo, un gestor de secretos dinámicos actúa de traductor: el agente le presenta su token, y el gestor fabrica al vuelo una credencial temporal — un usuario de base de datos que nace para esa tarea y muere con ella — cuya vida hereda la brevedad del token que la originó. Tecnologías candidatas para toda esta capa: Keycloak, Okta o Entra ID en el plano de identidad; Vault o Conjur en el de secretos dinámicos.

Capa 3 — Acceso estandarizado a herramientas. Imaginemos que cada equipo de la organización conecta sus agentes a las herramientas internas como buenamente puede: uno con llamadas REST directas, otro con un SDK casero, un tercero con algo que encontró en GitHub. El resultado son quince posturas de seguridad distintas, cada una con su manera de autenticar, de limitar y de registrar, o de olvidarse de las tres cosas. La alternativa pasa por un protocolo único de acceso a herramientas, y ahí MCP se está consolidando como el estándar de facto de la industria, con un ecosistema creciente de gateways comerciales y open source que le añaden lo que el protocolo, deliberadamente, deja fuera: la autenticación de cada llamada, la verificación de alcances por herramienta, el registro de auditoría. Con esa capa en su sitio, el modelo de seguridad se aplica una vez, en la interfaz, y da igual qué framework de orquestación haya elegido cada equipo para construir su agente. Esa separación tiene además una virtud organizativa que valoro mucho: permite estandarizar el acceso a herramientas sin meterse a legislar qué tecnología de agentes usa cada cual, que es una batalla que ningún equipo de plataforma debería querer dar.

Capa 4 — Guardarraíles de intención. Llego a la lección que más me costó digerir viniendo del mundo de la identidad, y la ilustro con el escenario que uso siempre. Un agente lleva un token técnicamente perfecto: alcance mínimo, audiencia única, cinco minutos de vida, actor claim en su sitio. Un atacante le cuela una inyección de prompt, y el agente llama a un endpoint al que está legítimamente autorizado, con parámetros maliciosos que el atacante le dictó. ¿Falló el token? Ninguno de sus controles falló. El token responde a la pregunta de si esa llamada está autorizada, y lo estaba. La pregunta que nadie estaba haciendo era si esa llamada concreta, con esos parámetros concretos, tenía sentido.

Validar sentido, validar intención, es una función distinta de validar permisos, y requiere una capa propia entre la decisión del agente y la ejecución de la acción. En la práctica combina tres mecanismos: validación del contenido de la llamada contra reglas explícitas, políticas expresadas en lenguaje natural que otro modelo evalúa antes de dejar pasar la acción, y aprobación humana obligatoria para todo lo que supere cierto umbral de riesgo o de irreversibilidad. Llamo blanda a esta capa con toda la intención, porque un modelo evaluando a otro modelo puede equivocarse, y conviene diseñar sabiéndolo. Pero cubre un hueco que ninguna cantidad de ingeniería de permisos va a cerrar jamás, porque los permisos hablan de lo que se puede hacer y esta capa habla de lo que conviene hacer.

Capa 5 — Telemetría y retroalimentación de riesgo. Cada emisión de token, cada credencial dinámica generada, cada llamada a herramienta, cada decisión de guardarraíl, registrada en un punto central con campos de correlación comunes. Insisto en los campos de correlación porque son los que convierten un montón de logs en una investigación posible: un identificador único de token que permita unir el evento de emisión en el proveedor de identidad con la llamada correspondiente en el sistema destino, los claims de sujeto y actor para saber quién actuó y en nombre de quién, y una referencia a la tarea que originó todo. Con eso reconstruyes lo ocurrido seis meses después, sin depender de la memoria de nadie.

Sobre esa telemetría se levanta la parte que me parece más elegante del modelo completo. Se construye una línea base de comportamiento por agente, qué llama, con qué frecuencia, en qué horarios, con qué alcances, y las desviaciones se vuelven señal de riesgo. Y esa señal viaja de vuelta hacia la capa de identidad: el agente que se aparta de su patrón recibe su siguiente credencial con menos vida, con menos alcance, o directamente con un humano delante aprobando. La detección deja de ser un informe que alguien lee el lunes y pasa a ser una entrada del propio sistema de emisión de credenciales. Tecnologías candidatas: cualquier SIEM serio, Splunk, Sentinel o QRadar, con instrumentación tipo OpenTelemetry alimentándolo.

La asunción de diseño que ordena todo lo demás

Todo el modelo anterior se deriva de una única asunción de partida, y prefiero hacerla explícita: el agente será engañado, tarde o temprano, y la arquitectura decide cuánto cuesta cada vez que ocurra.

Hace años que la seguridad perimetral pasó por su propio duelo con el “assume breach”. Costó aceptarlo, hubo resistencia, y hoy nadie serio diseña una red asumiendo que el perímetro aguantará indefinidamente. A los sistemas agénticos les toca el mismo duelo, y cuanto antes lo pasemos, mejor. La inyección de prompt lleva años resistiéndose a una solución definitiva, y todo apunta a que seguirá así, porque pedirle a un modelo de lenguaje que siga instrucciones y a la vez que ignore las instrucciones maliciosas es pedirle que distinga algo que muchas veces ni un humano distingue a la primera. Diseñar asumiendo que el engaño ocurrirá desplaza el esfuerzo hacia donde sí tenemos control: que un agente engañado durante los cinco minutos de vida de su credencial, confinado a un sistema, con lo irreversible detrás de una aprobación humana, sea un incidente menor que se investiga en una mañana con logs completos. Ese resultado sí es alcanzable con la ingeniería que ya sabemos hacer.

El directorio de hace veinte años

Antes de hablar de por dónde empezar, quiero desactivar la objeción que escucho siempre en organizaciones grandes, porque es legítima y tiene solución. La objeción dice: todo esto suena muy bien, pero nuestro Active Directory tiene veinte años de historia, grupos anidados dentro de grupos anidados, listas de distribución de correo haciendo de grupos de permisos porque en 2011 a alguien le pareció práctico, y cuentas de servicio que nadie se atreve a tocar porque se ignora qué dejarían de funcionar. Limpiar eso llevaría años.

Llevaría años, sí. Y la buena noticia es que la limpieza previa resulta innecesaria. El directorio legado se federa como fuente de autenticación: la gente sigue entrando con su cuenta de siempre, con su MFA corporativo de siempre, y nadie migra usuarios a ningún sitio. El modelo de autorización nuevo, el de los agentes y sus tokens acotados, se construye limpio en una capa aparte, donde la pertenencia a grupos del directorio funciona como una señal más entre varias a la hora de evaluar una política, en lugar de como la fuente de verdad absoluta. Una política puede decir que se concede tal permiso si el usuario pertenece a tal grupo del directorio, y además es horario laboral, y además la petición viene acotada a su departamento. El grupo aporta información; la decisión vive en la política nueva, que sí está documentada, versionada y auditada. La limpieza del directorio se convierte así en una tarea de fondo que avanza a su ritmo, mientras todo lo nuevo nace ya con el modelo correcto desde el primer día.

Por dónde empezaría yo mañana

El error que he visto matar más iniciativas de este tipo, y hablo con conocimiento de causa porque he estado sentado en las dos sillas: arrancar con un assessment exhaustivo de seis meses sobre todo el parque de agentes, todos los sistemas, todo el legado. Ese proyecto acumula alcance hasta morir de él, produce un documento estupendo que envejece en una carpeta compartida, y mientras tanto los equipos siguen desplegando agentes sin gobierno, porque el negocio aprieta y nadie va a esperar a que seguridad termine su estudio.

Mi alternativa cabe en una frase de vocabulario militar: una cabeza de playa. Un único caso de uso, deliberadamente pequeño, deliberadamente aburrido. Un agente de solo lectura. Un usuario interno que delega. Un sistema de reporting no crítico como destino. Aprobación humana obligatoria en la primera versión, aunque estorbe, precisamente para aprender cuándo estorba. Y el modelo de cinco capas completo aplicado de principio a fin a ese caso minúsculo: su sandbox, su token con actor claim, su credencial dinámica si toca sistema legado, su guardarraíl, su telemetría correlacionada.

Cuando esa cabeza de playa funciona, y funcionará porque es pequeña, se empaqueta. Idealmente como un módulo de infraestructura como código que cualquier equipo pueda consumir en autoservicio: pides una identidad de agente rellenando cuatro parámetros, el módulo te fabrica el cliente en el proveedor de identidad, los alcances mínimos, la política de intercambio de tokens y el registro en la telemetría, y las barreras de seguridad viven dentro del propio módulo, que sencillamente carece de un parámetro para pedir una vida de token mayor que el máximo o un alcance de escritura universal. A partir de ahí, la adopción se gana por comodidad. Si integrar por el camino correcto cuesta diez minutos con todo bien hecho, y hacerlo por libre cuesta dos semanas y tres tickets, la batalla cultural termina antes de empezar, y el mandato corporativo queda como último recurso para los casos que la comodidad sola no arrastre. He dedicado buena parte de mi carrera a la adopción de servicios de seguridad en organizaciones grandes, y si algo he aprendido es que los estándares que sobreviven son los que ganan por mejores, y los que se imponen por circular acaban rodeados de excepciones.

El siguiente capítulo de una historia que ya conocemos

Circula el relato de que la seguridad de agentes es una disciplina nueva que obliga a olvidar lo anterior y contratar perfiles que no existen. Mi lectura, después de dos décadas en identidad, va en dirección contraria. Mínimo privilegio, acceso just-in-time, gobierno del ciclo de vida de las identidades, atribución de acciones: todo el instrumental conceptual lleva años inventado, y buena parte del instrumental técnico también, empezando por estándares que dormían semiolvidados esperando su caso de uso. Lo que ha aparecido es una población nueva de identidades que se crean y destruyen en segundos, ejercen sus permisos sin descanso y pueden ser manipuladas con un párrafo de texto bien escondido. Una población para la que el instrumental clásico, aplicado sin adaptación, se queda corto, y aplicada con cabeza, encaja.

Los agentes ya están dentro de las organizaciones, con gobierno o sin él. Prefiero dedicar estos años a asegurarme de que entran por la puerta, con su contrato y sus permisos justos, y a que el primer incidente serio nos pille con la arquitectura hecha y los logs completos, en lugar de convirtiendo en urgente lo que hoy todavía puede ser simplemente importante.

---

Si este problema ya está encima de tu mesa, o sospechas que está a punto de estarlo aunque nadie lo haya puesto por escrito todavía, me interesa la conversación.

Francisco Oteiza Lacalle