Confused Deputy
Autoridad usada para el solicitante equivocado
Confused Deputy describe el problema en el que un intermediario utiliza su autoridad legítima para realizar una acción a favor de un solicitante que no debería poder provocarla. El intermediario puede autenticarse correctamente ante el destino; el fallo consiste en no relacionar suficientemente esa capacidad con la identidad, el recurso y la finalidad del pedido original.
La explicación de AWS IAM muestra el problema al delegar acceso entre cuentas o servicios. CWE-441 trata intermediación no deseada y pérdida de contexto del origen. Son referencias para entender la relación de autoridad, no una afirmación de que todo fallo de autorización tenga esa clasificación.
Tres responsabilidades
Conviene identificar al solicitante que induce la operación, al intermediario que posee una capacidad y al recurso protegido que recibe el efecto. La pregunta es por qué la petición del primero terminó ejecutándose con la autoridad del segundo.
Autenticar al intermediario no responde si el solicitante tenía derecho a ese pedido. Tampoco basta con comprobar que el identificador del recurso existe. El sistema necesita conservar o reconstruir de forma confiable el vínculo entre principal, tenant, acción y destino.
El deputy no necesita estar comprometido ni escapar de un sandbox. Puede usar una API válida y una credencial que funciona exactamente según su configuración. Por eso el diagnóstico debe examinar la delegación, no buscar obligatoriamente una vulnerabilidad de memoria o una contraseña robada.
Ejemplo: reportes de pedidos
Un servicio de Commerce prepara reportes para comerciantes. Su identidad técnica puede leer varios tenants, pero cada comerciante solo debería recibir sus propios pedidos. Si el servicio acepta un tenant indicado por el caller sin comprobar esa relación, puede consultar correctamente y entregar datos al solicitante equivocado.
La respuesta no consiste en pedir al comerciante que escriba mejor su intención. El servicio debe derivar o verificar el tenant autorizado y limitar la consulta. Conservar un log del pedido ayudará a investigar, pero no sustituye esa decisión antes de revelar los datos.
Una credencial diferente por tenant puede reducir el problema, si el servicio también selecciona correctamente la identidad. Si el caller puede elegir libremente una credencial ajena, cambiar la organización de secretos no resuelve la delegación.
Aplicación a agentes
Un coding agent puede leer una instrucción no autorizada dentro de un repositorio y usar después una herramienta con acceso del usuario. Prompt Injection describe cómo el contenido intenta desviar la decisión. Confused Deputy describe cómo se pone autoridad legítima al servicio de ese pedido.
Son relaciones componibles, no sinónimos. Puede haber una inyección que solo altere texto sin usar autoridad externa. También puede haber un confused deputy en un servicio completamente determinista, sin un modelo ni prompts.
Tool Abuse observa la capacidad utilizada indebidamente. Una fuga mediante una consulta autorizada para otro principal conecta además con Data Leakage. Distinguir los mecanismos permite elegir controles en la frontera correcta.
Controles y límites
Least Privilege reduce la autoridad disponible, pero un permiso pequeño todavía puede aplicarse al tenant equivocado. Trust Boundaries ayuda a identificar dónde se pierde el origen y dónde comprobarlo.
La aprobación de un paso debe referirse a la acción y al destino efectivos. Una descripción genérica como «preparar reporte» no debería autorizar después cualquier exportación. El alcance técnico y el significado del pedido deben seguir vinculados cuando cambia la ejecución.
La comprobación puede contrastar dos callers con derechos diferentes sobre el mismo identificador. El resultado esperado depende del contrato del servicio. Es una forma de evaluar delegación; no una receta universal de IAM ni una garantía de ausencia de todos los fallos de autorización.
Fuentes y alcance
Los ejemplos de Commerce y agentes son síntesis editorial. La clasificación de una vulnerabilidad real exige examinar su causa y una entrada suficientemente específica.