La identidad de los agentes no es un problema de seguridad

En muchas empresas que ya tienen un agente en producción pasa algo bastante sencillo: el agente se autentica con una cuenta de servicio compartida y una clave de API que no caduca.

La misma cuenta que utilizan otros procesos. Una cuenta que se creó hace años, probablemente por alguien que ya ni siquiera trabaja en la empresa, y que nunca tuvo un propietario claro.

Y no, nadie hizo necesariamente nada mal.

Cuando estás haciendo un piloto y necesitas que el agente lea el CRM, pedir una identidad nueva puede convertirse fácilmente en tres semanas de tickets, aprobaciones y reuniones. Si tienes una credencial que ya funciona, la tentación es bastante evidente.

Y funciona.

Ese es precisamente el problema.

Por qué esto deja de ser anecdótico

Gartner proyecta que el 40 % de las aplicaciones empresariales llevarán agentes integrados a finales de este año, frente a menos del 5 % el año pasado. IBM, por su parte, ha encontrado que los incidentes de seguridad relacionados con la IA en la sombra se han más que duplicado en un año, hasta alcanzar el 43 %, mientras que dos tercios de las organizaciones no tienen un proceso para detectarla.

Una credencial prestada para un piloto es un atajo fácil de entender.

El problema aparece cuando ese atajo se convierte en la forma habitual de conectar una parte importante de las aplicaciones de la empresa, sin que nadie haya tomado realmente esa decisión.

Hasta dónde llega el proveedor de identidad

Un proveedor de identidad hace muy bien dos cosas: comprobar quién está haciendo una llamada y comprobar si tiene permiso para acceder a un determinado recurso.

Con un agente, la pregunta importante es ligeramente diferente:

Esta acción concreta, en este momento y en este contexto, ¿es una de las acciones que el negocio ha delegado en este agente?

El proveedor de identidad no puede responder a eso.

Y probablemente tampoco debería hacerlo.

No es una cuestión de que el producto de identidad sea más o menos sofisticado. La respuesta depende de reglas de negocio que viven en otra parte del sistema.

Ahí está la diferencia.

Los dos modelos mentales que arrastramos

Cuando hablamos de permisos solemos pensar en dos modelos.

A una persona le damos un acceso relativamente amplio porque esperamos que tenga criterio para utilizarlo. Y si hace algo absurdo, podemos pedirle explicaciones.

Una aplicación tradicional funciona de otra manera. Tiene un flujo definido, ejecuta unas operaciones concretas y, en general, podemos mirar el código para saber qué va a hacer.

Un agente no encaja demasiado bien en ninguno de los dos modelos.

Decide en tiempo de ejecución qué llamadas necesita hacer y la secuencia puede cambiar de una ejecución a otra.

Por eso, definir sus permisos únicamente en función de los endpoints que puede llamar no limita necesariamente lo que puede llegar a hacer.

Un ejemplo sencillo.

Un agente tiene permiso para leer clientes y permiso para escribir facturas. Por separado, ambas cosas parecen razonables. Incluso es posible que ambas hayan sido aprobadas por separado.

Pero juntas permiten algo que nadie había previsto: emitir una factura a un cliente al que no se pretendía facturar.

Nadie autorizó esa operación concreta.

Pero tampoco nadie la prohibió.

El problema es que el permiso se concedió mirando cada endpoint por separado, mientras que el riesgo aparece cuando combinamos varias capacidades.

Qué debería nombrar realmente un permiso

“Puede leer clientes” describe una superficie técnica.

“Puede comprobar si una factura está conciliada” describe una acción de negocio completa.

Parece una diferencia de redacción, pero en realidad es una diferencia de arquitectura.

En el primer caso, el alcance se define en el proveedor de identidad. En el segundo, la capacidad se define en la capa de integración.

Y esa capa es la que conoce el contexto necesario para hacer la operación.

Sabe, por ejemplo, que comprobar una conciliación implica consultar cuatro cosas distintas en tres sistemas y aplicar después una regla de negocio que quizá ni siquiera esté documentada en ningún sitio.

Ese es el punto donde realmente se puede poner el freno.

Es, en el fondo, la misma idea que hay detrás de utilizar capacidades con nombres de negocio en lugar de exponer directamente operaciones técnicas. Yo llegué a esta conclusión pensando inicialmente en la usabilidad del agente: si le das treinta operaciones con nombres de tablas y endpoints, el agente tiene más opciones, pero no necesariamente más criterio.

Con el tiempo me di cuenta de que aquella decisión de diseño era también una decisión de gobierno.

La traza tiene que responder tres preguntas

Registrar que un token llamó a un endpoint no sirve de mucho cuando llega una auditoría.

Es exactamente lo que ya registramos hoy.

Y, en muchos casos, ese registro no explica absolutamente nada.

Pensemos en un caso realista:

Marta (cuentas a pagar)
        │
        │ pide: "revisa las facturas de este proveedor"
        ▼
Agente asistente
        │
        │ delega: comprobar_conciliacion(proveedor=X)
        ▼
Agente de facturas
        │
        │ invoca la capacidad
        ▼
Capa de integración ──── aquí se decide y se registra
        │
    ┌───┴─────┬─────────────┐
    ▼         ▼             ▼
   ERP      Banco     Contabilidad

Quien termina llamando al ERP es el agente de facturas.

Pero quien inició la petición fue Marta, dos pasos más arriba.

Si solo guardamos la llamada al ERP, hemos perdido precisamente la información que explica por qué esa llamada estaba permitida.

La traza debería permitir contestar, como mínimo, tres preguntas.

Qué agente.

No qué cuenta de servicio.

El agente debería tener una identidad propia y distinguible de otros agentes que hoy pueden estar utilizando la misma credencial.

En nombre de quién.

Esta es probablemente la pregunta que más fácilmente se pierde.

Un agente rara vez actúa completamente por iniciativa propia. Normalmente está ejecutando algo que alguien le pidió, o que otro agente le delegó.

Bajo qué criterio.

Qué capacidad se invocó, con qué parámetros y qué regla permitió hacerlo.

La diferencia entre ambos tipos de registro es bastante grande.

Hoy podríamos tener algo así:

11:04:19  svc_integracion  GET /api/v2/invoices?vendor=X  200

Y para una auditoría necesitaríamos algo más parecido a esto:

11:04:19
actor       agente-facturas-03
en nombre   agente-asistente-01 → marta.ruiz@empresa.com
capacidad   comprobar_conciliacion
parámetros  proveedor=X, periodo=2026-08
regla       cuentas-a-pagar/lectura-conciliacion

Además, esa información debería quedar en un registro que el propio agente no pueda modificar.

Porque si un sistema escribe el registro donde quiere y después utilizamos ese mismo registro para auditarlo, en realidad no estamos auditando demasiado.

Gobierno de APIs con un consumidor nuevo

El proveedor de identidad emite el token.

La capa de integración decide hasta dónde puede llegar.

Los controles que realmente limitan a un agente están donde se define la capacidad: qué operaciones existen, qué parámetros aceptan, qué se registra y qué operaciones necesitan confirmación humana.

Y esto no es algo completamente nuevo. Llevamos muchos años haciendo gobierno de APIs.

Lo que ha cambiado es el consumidor.

Ya no tenemos delante una aplicación que sigue siempre el mismo flujo. Tenemos un sistema que decide qué hacer sobre la marcha.

Lo digo con la cautela de quien está mirando el problema principalmente desde el lado de la integración, pero tengo la sensación de que estamos metiendo todo este asunto dentro del cajón de “seguridad”.

Y ahí se nos puede quedar una parte importante sin resolver.

Seguridad puede darte una identidad propia para cada agente. Puede darte tokens de vida corta, rotación de credenciales y controles de acceso.

Todo eso es necesario.

Pero ninguna de esas cosas responde por sí sola a la pregunta más importante:

¿Qué puede hacer exactamente este agente?

El agente que no necesita nada de esto

También hay que poner un poco de sentido común.

Si tienes un agente que únicamente lee información pública y no puede comprometer datos ni realizar acciones sobre terceros, probablemente no necesitas montar todo este sistema de gobierno desde el primer día.

El coste de hacerlo puede ser mayor que el riesgo.

Y si todavía estás intentando averiguar si un caso de uso tiene sentido, utiliza datos falsos. No necesitas resolver la identidad definitiva de un agente que quizá nunca llegue a producción.

Lo que no funciona es repetir el patrón de siempre: hacer un piloto que toca sistemas reales con credenciales prestadas y dejar la parte de gobierno para “más adelante”.

Porque muchas veces ese “más adelante” acaba convirtiéndose en producción.

Por dónde empezar

Primero, dale al agente una identidad propia.

Ni compartida ni heredada.

Solo esto ya permite saber qué hizo cada agente, algo que con una cuenta de servicio compartida puede ser imposible.

Después, haz que los permisos caduquen. Vida corta y alcance limitado a la tarea siempre que sea posible.

Un token eterno con permisos amplios no ofrece mucho más control que una contraseña escrita en un pósit.

También hay que registrar la delegación.

No solo la llamada.

Quién pidió qué a quién.

Y, sobre todo, empieza a pensar en la capacidad como la unidad de gobierno.

Si no puedes hacer una lista y decir “este agente puede hacer estas diez cosas”, probablemente todavía no habéis decidido realmente qué puede hacer.

Dentro de unos meses alguien de cumplimiento puede preguntar algo muy sencillo:

¿Qué puede hacer exactamente vuestro agente contra los sistemas de la empresa?

La respuesta no puede ser:

“Depende de lo que decida”.

Tiene que ser una lista.

---

El patrón completo para exponer esas capacidades y para que un sistema pueda ir destilándolas a medida que aprende lo explico en MCP-Led: integración semántica para sistemas empresariales.