Estamos desplegando sistemas autónomos que leen archivos, llaman APIs, envían mensajes y ejecutan código, pero todavía cuesta responder una pregunta básica: ¿quién es este agente?

La mayoría de las organizaciones sigue autenticando agentes con cuentas de servicio compartidas, API keys estáticas o credenciales creadas para software determinístico. Ninguno de esos modelos representa bien a una instancia que decide qué herramientas usar a partir de lenguaje natural y contexto cambiante.

¿Por qué no alcanzan las identidades de humanos, servicios o bots?

Los humanos autentican de forma interactiva y pueden aprobar scopes o responder un desafío de MFA. Un agente opera sin una persona presente en cada ejecución.

Los servicios usan credenciales estáticas porque realizan funciones predecibles. Un agente no es determinístico: con la misma herramienta puede tomar decisiones diferentes según el prompt, la conversación, el modelo y el estado del entorno. Un permiso fijo termina siendo demasiado amplio para la mayoría de las tasks o insuficiente para algunas.

Los bots tradicionales ejecutan comportamientos enumerables. En un agente, las acciones emergen de la combinación entre modelo, pedido del usuario, herramientas y contexto. La identidad tiene que representar esa instancia y la autoridad que recibió para una task específica.

¿Dónde aparece el problema de delegación?

Cuando una persona pide “resumí mis últimos correos”, se inicia una cadena. El usuario delega autoridad al agente. El agente llama a un MCP server. El server accede a una API en nombre del usuario. Cada salto toma una decisión de confianza, pero la mayoría de los tokens solo identifica a un operador o una aplicación, no a toda la cadena.

OAuth modela delegación, pero un agente no encaja con facilidad en el concepto de cliente fijo. Decide qué herramientas llamar y con qué parámetros durante la ejecución. Para auditar la acción hace falta vincular al usuario, la instancia del agente, el cliente, la task y la operación autorizada.

¿Qué pasa cuando se combinan varias herramientas?

Un agente puede leer un archivo con un server, extraer una credencial, consultar una base de datos con otro y enviar los resultados mediante un tercero. Cada permiso aislado parece razonable. La composición crea un canal de exfiltración que nadie aprobó.

Ningún server ve la cadena completa. El agente es el único componente con todo el contexto, pero hoy no existe un modelo universal que aplique límites entre herramientas equivalentes a los límites de origen de un navegador.

¿Qué perdemos sin una identidad propia para los agentes?

Se pierde atribución: no se puede demostrar qué instancia hizo una acción por pedido de qué persona. Se pierde detección: una cuenta compartida no permite construir un baseline por agente. Se pierde mínimo privilegio: todos heredan la misma autoridad. También se pierde trazabilidad regulatoria cuando una decisión sensible solo aparece firmada por una credencial genérica.

¿Cómo debería ser un stack completo de identidad agéntica?

Identidad por instancia. Cada proceso recibe una identidad verificable, de vida corta y con rotación automática.

Autorización delegada. Los tokens vinculan explícitamente a la persona, el agente, la aplicación y la task, con autoridad acotada.

Política por herramienta. Cada invocación se evalúa con sus parámetros, no solo por estar conectado al server.

Confianza entre agentes. Los participantes verifican identidad y alcance cuando colaboran mediante A2A u otros protocolos.

Auditoría continua. Cada acción conserva la identidad de la instancia, la delegación, la herramienta, los argumentos y el resultado.

SPIFFE, OAuth, A2A y las propuestas de la IETF aportan piezas. El hueco está en unirlas de forma portable y operable.

¿Qué puede hacer un equipo hoy?

Dejar de compartir credenciales entre agentes. Registrar cada tool call y sus parámetros. Limitar herramientas por agente. Fijar versiones y hashes de servers y skills. Revocar autoridad cuando termina la task. Tratar a los agentes como infraestructura privilegiada, con el mismo rigor que un servicio de producción.

Los estándares están avanzando, pero los agentes ya están ejecutando acciones. El momento de cerrar la brecha de identidad es antes de que una cuenta compartida se convierta en la única explicación disponible después de un incidente.

Referencias

  • Cloud Security Alliance, encuesta sobre identidad de agentes de IA, 2025.
  • Gravitee, State of AI Agent Security 2026.
  • IETF, propuestas de delegación OAuth para agentes.
  • NIST, AI Agent Standards Initiative.
  • SPIFFE y especificación A2A.