La identidad de los agentes no es un problema de seguridad

En la mayoría de las empresas que ya tienen un agente en producción, ese agente se autentica con una cuenta de servicio compartida y una clave de API que no caduca. La misma cuenta que usan otros tres procesos, creada hace años por alguien que ya no está en la compañía, sin propietario formal.

Nadie hizo mal su trabajo. El piloto necesitaba leer el CRM, pedir una identidad nueva eran tres semanas de tickets, y había una credencial ahí mismo que ya funcionaba.

Y funcionó, que es lo peor que podía pasar.

Por qué esto deja de ser anecdótico

Gartner proyecta que el 40% de las aplicaciones empresariales llevarán agentes embebidos a final de este año, frente a menos del 5% el año pasado. IBM encontró que los incidentes de seguridad que involucran IA en la sombra se han más que duplicado en un año, hasta el 43%, y que dos tercios de las organizaciones no tienen ningún proceso capaz de detectarla.

Una credencial prestada en un piloto es un atajo que cualquiera entiende. El problema llega cuando ese atajo pasa a ser la forma habitual de conectar cuatro de cada diez aplicaciones, sin que nadie lo haya decidido.

Hasta dónde llega el proveedor de identidad

Un proveedor de identidad hace bien dos cosas: comprobar quién es quien llama y comprobar si tiene permiso para llamar a un sitio concreto.

Cuando quien llama es un agente, la pregunta que necesitas contestar es otra. Esta acción concreta, ahora, en este caso, ¿es una de las que el negocio le ha delegado?

Eso no lo sabe el proveedor de identidad, y no lo va a saber por mucho que madure el producto, porque la respuesta depende de reglas de negocio que viven en otro sitio.

Los dos modelos mentales que arrastramos

Cuando repartimos permisos, un agente no encaja en ninguno de los dos.

A una persona le damos acceso amplio porque tiene criterio y porque, si hace una barbaridad, responde. Una aplicación va por el camino contrario: guion fijo, siempre lo mismo en el mismo orden, y puedes leer su código y saber qué va a pedir.

Un agente decide en tiempo de ejecución qué secuencia de llamadas hace, y la secuencia es distinta cada vez. Por eso los permisos modelados sobre qué puede llamar no acotan qué puede hacer.

Un agente con permiso de lectura sobre clientes y permiso de escritura sobre facturas. Por separado las dos cosas son razonables, y por separado se aprobaron. Combinadas permiten emitir una factura a un cliente al que nadie quería facturar.

Nadie autorizó eso. Tampoco nadie lo prohibió, porque el permiso se concedió por endpoint y el riesgo aparece en la combinación.

Qué tiene que nombrar un permiso

“Puede leer clientes” describe una superficie. “Puede comprobar si una factura está conciliada” describe una acción de negocio completa, con principio y con final.

Parece una diferencia de redacción y es una diferencia de arquitectura, porque cambia dónde vive el control. Un alcance por endpoint se define en el proveedor de identidad. Una capacidad se define en la capa de integración, que es la única que sabe que comprobar una conciliación son cuatro consultas a tres sistemas y una regla que nadie escribió nunca.

Ese es el único punto donde se puede poner el freno de verdad.

Es la misma idea que sostiene que un agente necesita capacidades con nombre de negocio en lugar de operaciones técnicas. Yo llegué a ella por el lado de la usabilidad del agente, que elige mucho peor cuando le das treinta operaciones con nombre de tabla. Resulta que aquella decisión era en realidad la decisión de gobierno.

La traza tiene que responder tres preguntas

Registrar que un token llamó a un endpoint no sirve de nada en una auditoría. Es exactamente lo que ya registras hoy, y no te ha ayudado nunca.

Mira lo que pasa de verdad cuando alguien pide algo:

   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 llama al ERP es el agente de facturas. Quien quería algo es Marta, dos saltos más arriba. Si solo guardas la llamada, has perdido el tramo que explica por qué esa llamada estaba permitida.

Qué agente, y no qué cuenta de servicio. Con identidad propia, distinguible de los otros dos que hoy comparten la misma credencial.

En nombre de quién. Esta es la que casi nadie registra y la que te van a preguntar. Un agente casi nunca actúa por sí mismo: actúa porque alguien se lo pidió, o porque otro agente le delegó la tarea.

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

La diferencia en el registro es esta. Lo que guarda hoy un sistema normal:

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

Y lo que hace falta para contestar en una auditoría:

11:04:19
  actor         agente-facturas-03
  en nombre de  agente-asistente-01 → [email protected]
  capacidad     comprobar_conciliacion
  parámetros    proveedor=X, periodo=2026-08
  regla         cuentas-a-pagar/lectura-conciliacion

Las tres tienen que quedar en un registro que el agente no pueda modificar, porque un sistema que escribe donde quiere y luego se audita a sí mismo con ese mismo registro no está auditando nada.

Por qué esto te toca si haces integración

El proveedor de identidad emite el token. La capa de integración decide hasta dónde llega ese token.

Todo control que de verdad acota a un agente vive donde se define la capacidad: qué operaciones existen, qué parámetros aceptan, qué queda registrado y qué exige que lo confirme una persona. Y no es un problema nuevo: es gobierno de APIs, que llevamos quince años haciendo. Lo que ha cambiado es que el consumidor ya no se comporta como esperábamos.

Lo digo con la duda razonable de quien lo mira desde un solo lado, pero tengo la sensación de que el tema está cayendo entero en seguridad y de que ahí se va a quedar a medias. Seguridad puede darte identidades propias y tokens de vida corta. Nada de eso contesta qué puede hacer el agente.

El agente que no necesita nada de esto

Si solo lee, y lee datos públicos o que no comprometen a nadie, móntalo y sigue: el coste de gobernarlo supera al riesgo. Y si estás explorando si un caso de uso tiene sentido, hazlo con datos falsos: la identidad se diseña cuando ya sabes que vas a producción.

Lo que no funciona es lo de siempre, el piloto que toca sistemas reales con credenciales prestadas y la promesa de ordenarlo más adelante.

Por dónde empezar

Dale al agente una identidad propia, ni compartida ni heredada. Solo con esto ya puedes responder qué hizo cada uno, que hoy no puedes.

Haz que el permiso caduque, con vida corta y alcance por tarea. Un token eterno con permisos amplios tiene el mismo valor de control que una contraseña apuntada en un pósit.

Registra la delegación, no solo la llamada. Quién pidió qué a quién.

Y convierte la capacidad en la unidad. Si no puedes enumerar en una lista lo que tu agente puede hacer, es que todavía no lo habéis decidido.

Dentro de unos meses alguien de cumplimiento va a preguntar 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 de cómo se exponen esas capacidades, y cómo un sistema las va destilando a medida que aprende, está en MCP-Led: integración semántica para sistemas empresariales.