Problema
Un usuario autoriza a un agente para consultar facturas. El agente delega parte del trabajo a otro agente, que llama a un servidor MCP, que a su vez consulta una API financiera.
La implementación rápida consiste en pasar el mismo token por toda la cadena.
Parece práctico: la persona ya dio permiso y todos los componentes necesitan acceso. Pero el token deja de expresar quién actúa, para qué recurso fue emitido y qué autoridad conserva en cada salto. Si uno de los intermediarios se compromete, puede reutilizar una credencial más amplia de lo necesario.
El sistema mantiene acceso. Pierde identidad, audiencia y trazabilidad.
Tesis
Una cadena agentiva necesita conservar tres sujetos distintos: el usuario que origina, el agente que actúa y el recurso que recibe.
El usuario aporta autoridad delegable. El agente debe tener identidad propia. El recurso debe recibir un token emitido específicamente para su audiencia. Cuando aparece otro salto, la autorización debe volver a evaluarse y reducirse; no viajar intacta como una llave maestra.
La regla operativa es simple: propagar contexto de autoridad no significa propagar la credencial original.
Framework
Modela cada llamada con cuatro elementos:
- Originador: persona o servicio que inició el objetivo.
- Principal actuante: agente concreto que intenta ejecutar la operación.
- Audiencia: servidor o API para el que se emitió el token.
- Delegación: scope, profundidad, propósito y condiciones que sobreviven al siguiente salto.
El log útil no dice sólo “Bertha autorizó”. Debe poder responder: “el agente de conciliación, actuando en nombre de Bertha, pidió lectura de la factura 483 al recurso financiero, mediante una delegación válida para este paso”.
Señal medible: porcentaje de tool calls que registran originador, agente, audiencia, scope y decisión de autorización.
Postura: si dos recursos aceptan el mismo bearer token por comodidad, el perímetro ya está mezclado.
Por que importa ahora
La especificación de autorización de MCP exige que el cliente incluya el parámetro resource y que el servidor valide que el token fue emitido específicamente para él. Su guía de seguridad prohíbe expresamente el token passthrough: un servidor MCP no debe aceptar un token destinado a otro recurso ni reenviarlo sin cambios a una API downstream.
La razón no es ceremonial. Sin audiencia correcta se pueden eludir rate limits, validación y monitorización. Los logs del servidor y de la API pueden atribuir la misma acción a identidades diferentes. Y un token robado puede reutilizarse entre servicios que nunca debieron compartir confianza.
Google Cloud lleva el patrón al runtime: Agent Identity asigna una identidad criptográfica por agente, basada en SPIFFE, y vincula tokens a certificados X.509. En flujos delegados, sus logs pueden mostrar conjuntamente identidad de usuario y de agente. La documentación actual marca como Preview tanto OAuth delegado como el Agent Identity auth manager, por lo que deben evaluarse como capacidades en maduración, no como contrato universal. AWS propone para cadenas multiagente otra pieza complementaria: token exchange on-behalf-of, contextos firmados y políticas independientes por salto, de modo que el agente downstream reciba sólo el scope delegado.
Son implementaciones de proveedor, no un estándar único. La arquitectura común sí es portable: identidad del actor, autoridad de origen y autorización del recurso deben seguir separadas.
Anti-ejemplo
“El orquestador ya validó al usuario; los subagentes pueden usar su token.”
Un subagente especializado en lectura recibe el token completo del usuario, que también permite borrar registros. El siguiente servidor no distingue al subagente del originador. Cuando una instrucción maliciosa fuerza un delete, todos los logs muestran una credencial válida y nadie puede probar qué componente amplió la acción.
Autenticación válida no equivale a autorización correcta en cada salto.
Protocolo (3 pasos)
- Dibuja la cadena real. Usuario, agente, subagente, MCP y API; anota qué token y qué audiencia existen en cada flecha.
- Intercambia, no reenvíes. Emite credenciales cortas y específicas para el recurso y reduce scope, capacidad y profundidad en cada delegación.
- Autoriza y registra por hop. Evalúa agente, herramienta, originador y acción fuera del razonamiento del modelo; conserva la decisión en una traza común.
| Capa | Pregunta | Control mínimo |
|---|---|---|
| usuario | quién originó | identidad y contexto verificable |
| agente | quién actúa ahora | principal propio |
| token | para quién sirve | audiencia y expiración |
| delegación | qué autoridad sobrevive | scope y límite de saltos |
| recurso | se permite esta acción | policy externa y log |
Relacionado
- Agent Identity: el pasaporte operativo que separa agente útil de riesgo invisible
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
- Sandboxed Work: el perímetro de ejecución de los agentes en producción
Fuentes consultadas
- Model Context Protocol: Authorization
- Model Context Protocol: Security Best Practices
- Google Cloud: Agent Identity overview
- AWS: least-privilege authorization in multi-agent AI chains
Proximo paso
Audita una integración agentiva con OAuth. Si encuentras el mismo token entrando en dos recursos distintos, detén el diseño y separa audiencia, principal y delegación antes de ampliar autonomía.