Si le das a un agente de IA su propio token de admin a otro sistema, creaste un "confused deputy": puede hacer cualquier cosa, atribuida a nadie. Nos topamos con esto conectando el agente de CRM de TITO a nuestro CRM vía MCP, y la solución es un patrón que vale la pena copiar — identidad delegada en un subsistema de confianza.
Dos capas de permisos
Primero, la plataforma gatea quién puede usar el agente (grants de acceso). Segundo — y esto es la clave — el agente no lleva las credenciales del usuario. El bearer token autentica a la plataforma como cliente confiable; cada llamada a una tool lleva además un header X-Acting-User con la identidad de la persona. El sistema destino matchea ese email a su propio usuario y aplica los permisos de esa persona, auditando bajo ella.
La frontera es el contrato
Esto solo funciona si el destino confía en X-Acting-User exclusivamente desde un token válido y una IP allowlisteada. Ese par es la frontera de seguridad: afuera, el header no significa nada. Adentro, el agente puede actuar como Ana con los derechos exactos de Ana — y nunca como más que Ana.
¿Por qué no simplemente impersonar?
Porque impersonar copia un secreto; delegar pasa una afirmación a través de una frontera que controlás. Revocás el token de la plataforma y todos los agentes pierden acceso de una. Mirás el log de auditoría y cada escritura queda atribuida al humano real que la disparó, no a una cuenta de servicio sin cara.
Los agentes van a actuar cada vez más en nuestro nombre. La identidad es la parte que no te podés permitir resolver a mano alzada.