Identidad no humana: por qué tus agentes necesitan credenciales propias

Cuando un equipo conecta su primer agente a producción, la identidad casi nunca es la parte interesante. La parte interesante es el razonamiento, las herramientas, la demo. Así que el agente se conecta por la vía rápida: corre bajo el token personal de quien lo hizo, o bajo una cuenta de servicio con acceso amplio y permanente, porque era lo que había a mano y hace que la demo funcione hoy.

Solo que ese atajo es el hallazgo que acaba con el proyecto en el comité de seguridad, y lo acaba por una razón que no tiene nada que ver con lo bueno que sea el agente. Un agente que usa las credenciales de una persona hereda la autoridad de una persona, la ambigüedad de auditoría de una persona y el radio de acción de una persona, siendo al mismo tiempo un sistema probabilístico que lee entradas adversarias todo el día. Has conectado un sistema al que se puede convencer de hacer cosas a una credencial que puede hacer casi cualquier cosa. Ningún proceso de homologación aprueba eso, y hace bien.

El replanteamiento que lo desbloquea es sencillo de decir y estructural de implementar. Un agente no es un usuario, y no debe autenticarse como tal. Es una carga de trabajo, y necesita identidad propia, acotada a lo que hace, que viva y muera en una escala de tiempo que una credencial humana nunca podría tener.

Un token prestado es una llave maestra

Sé concreto sobre por qué el atajo es descalificante, porque "buena práctica" no es un argumento que un comité de riesgos acepte.

El token personal de quien desarrolla está diseñado para una persona: es de larga duración, de alcance amplio y se usa de forma interactiva en muchos sistemas. Son exactamente las propiedades equivocadas para un agente. Cuando el agente actúa bajo ese token, tres cosas se rompen a la vez. El rastro de auditoría ya no puede distinguir a la persona del agente, así que no puedes decir quién, o qué, ejecutó una acción. El alcance es mucho más ancho que la tarea del agente, así que un ataque de diputado confundido tiene una superficie enorme que explotar. Y la credencial es de larga duración, así que, si se filtra, sigue siendo valiosa durante semanas.

Esa última propiedad es la que convierte un error en una brecha. Un token de larga duración robado, con acceso permanente a producción, es una llave maestra. Funciona desde cualquier sitio, durante mucho tiempo, contra muchos sistemas. Todo en la forma habitual de conectar agentes maximiza el valor de esa llave para quien la robe.

El objetivo de la identidad de carga de trabajo es dejar la llave sin valor.

Identidad de carga de trabajo, de corta duración y privilegio mínimo

La postura de producción invierte todas las propiedades del token prestado. Cada agente corre bajo su propia identidad no humana, distinta de cualquier persona, emitida y rotada por la plataforma, acotada exactamente a las acciones que su proceso requiere, y de corta duración por construcción.

Vale la pena nombrar el patrón en el que ha convergido la industria, porque le da a tu equipo de seguridad algo conocido sobre lo que razonar en lugar de algo hecho a medida. SPIFFE, el Secure Production Identity Framework for Everyone, define una identidad estándar para una carga de trabajo, y SPIRE, su runtime, emite a cada carga un documento de identidad verificable criptográficamente, atestiguado en el momento de emisión y que caduca rápido, a menudo en minutos. El agente no guarda un secreto estático que pueda filtrarse. Demuestra continuamente qué es y recibe una credencial nueva y de corta duración, que la plataforma puede dejar de emitir en el instante en que la carga deba dejar de correr.

Superpón privilegio mínimo a eso y la identidad lleva solo las capacidades estrechas que el proceso necesita. No "acceso a la base de datos", sino read_open_invoices. No "enviar correo", sino submit_decision_for_review. La identidad es lo que la credencial autentica, las capacidades son lo que autoriza, y ambas son deliberadamente pequeñas.

Ahora repite el robo. Un atacante que captura una credencial de agente tiene algo que caduca en minutos, funciona solo para un puñado de acciones con nombre y solo desde una carga atestiguada. No hay secreto estático que reutilizar, ni acceso permanente que heredar, ni alcance ancho por el que pivotar. La llave abre casi nada, y durante casi nada de tiempo. Ese es el objetivo de diseño: una credencial de agente robada debería valer casi cero.

La salida de datos es la otra mitad de la frontera de identidad

La identidad controla qué puede hacer un agente. No controla, por sí sola, a dónde puede enviar datos, y para un sistema que lee contenido regulado todo el día, a dónde pueden ir los datos importa tanto como qué acciones pueden dispararse.

Por eso la identidad de carga de trabajo va emparejada con una allow-list de salida explícita. El agente solo puede alcanzar los destinos concretos que su proceso requiere, nombrados de antemano, y cualquier otra vía de salida se deniega por defecto. No "internet, menos una lista de bloqueo". Lo contrario: nada, más una lista corta de endpoints permitidos.

La razón por la que esto importa es la exfiltración, el décimo punto de la lista de riesgos agénticos de OWASP. La mayoría de los controles anteriores intentan impedir que se manipule a un agente. La allow-list de salida asume que uno de ellos acabará fallando y hace otra pregunta: incluso si consiguen dar la vuelta al agente, ¿a dónde puede enviar realmente los datos? Si los únicos destinos permitidos son tus propios sistemas, un agente comprometido no tiene a dónde mandar lo que robó. Privilegio mínimo en las acciones y privilegio mínimo en la salida son dos caras de la misma frontera, y una homologación seria busca las dos.

Esto es lo que de verdad pasa una homologación de seguridad

Da un paso atrás y mira qué está probando de verdad una homologación, la aprobación formal de seguridad que una empresa regulada exige antes de que un sistema entre en producción. No está probando si tu agente es listo. Está probando si un revisor puede razonar sobre qué puede hacer el sistema cuando las cosas van mal.

Un token humano prestado falla esa prueba al primer contacto, porque la respuesta honesta a "¿qué puede hacer esta credencial si se filtra?" es "casi cualquier cosa, durante semanas, desde cualquier sitio". No hay forma de disimularlo. El trabajo del revisor es imaginar la credencial en manos de un atacante, y el cuadro es inaceptable.

La identidad de carga de trabajo pasa porque cambia la respuesta. "¿Qué puede hacer esta credencial si se filtra?" pasa a ser "un puñado de acciones con nombre, durante unos minutos, solo desde una carga atestiguada, y solo puede alcanzar estos tres endpoints internos". Esa es una respuesta acotada, comprobable y defendible, y una respuesta acotada es para lo que sirve una aprobación. El mismo giro hace honesto el rastro de auditoría, porque ahora cada acción se rastrea hasta una identidad de agente concreta y no hasta una cuenta compartida ambigua. Por fin puedes decir qué ejecutó una acción, no solo suponerlo.

Nada de esto es infraestructura exótica por sí misma. Es la diferencia entre un sistema que un comité de seguridad puede aprobar y uno que no, y esa diferencia suele ser la diferencia entre un piloto que sale y uno que muere en revisión.

Así que la pregunta que llevar a tu próximo comité de seguridad no es "¿es nuestro agente lo bastante preciso para confiar en él?". Es si robaran esta noche la credencial de este agente, qué podría hacer exactamente el ladrón con ella, durante cuánto tiempo, y hacia qué destinos. Si la respuesta es algo mayor que una lista corta que caduca en minutos, tu agente se está autenticando como una persona, y ese es el hallazgo que te van a devolver.

Si quieres poner a prueba cómo se autentica uno de tus agentes y cuánto vale su credencial para un atacante, reserva una reunión.