El error que convierte a tu jefe de gabinete de IA en un "confused deputy"

En abril de 2026, un agente construido sobre Microsoft Copilot Studio actualizó la dirección de correo de un cliente y disparó un reseteo de contraseña. No hubo malware. No hubo credenciales robadas. Cada llamada a herramienta pasó la validación técnica. El agente simplemente hizo lo que una instrucción inyectada le pidió, porque nada en el sistema verificaba quién lo había autorizado ni para qué.

Eso es un "confused deputy": un programa con privilegios al que una entidad con menos privilegios engaña para que use su autoridad. El concepto es de 1988. Lo que cambió es que ahora ese programa con privilegios es tu jefe de gabinete de IA, conectado a tu correo, tu calendario, tu CRM y tu sistema de soporte.

He visto el reflejo equivocado en casi todos los operadores con los que trabajo cuando se enteran de esto. La reacción instintiva es "entonces le doy menos acceso al agente". Y es la lección incorrecta.

Recortar permisos resuelve poco, porque el agente útil necesita acceso real. Un jefe de gabinete que no puede tocar tu calendario ni tu inbox no es un jefe de gabinete, es un bloc de notas. El problema de fondo es otro: la separación entre dos controles que casi ningún despliegue tiene bien atados.

El primero es la identidad vinculada: poder atribuir cada acción del agente a un principal concreto y autenticado, humano o sistema. El segundo es la prueba de autorización: evidencia verificable de que esa acción fue permitida explícitamente, por una autoridad legítima, para un propósito específico, en un momento específico.

Cuando faltan, el sistema no puede responder las dos preguntas que importan después de un incidente: ¿quién autorizó esto, y estaba dentro del alcance? En el caso de Meta, un agente con credenciales válidas se saltó la gobernanza de identidad y ejecutó acciones que jamás debió tener permitidas. El fallo no estuvo en la autenticación —las credenciales eran reales— sino en la ausencia de autorización continua y de verificación de intención.

El caso de Air Canada lo lleva al terreno legal. Su chatbot dio un consejo de tarifa equivocado y la empresa argumentó que era una entidad separada. El tribunal lo rechazó. No había identidad única, ni registro de autorización, ni rastro auditable que ligara la acción del bot a una persona o política responsable. Esa brecha de atribución es la que termina costando dinero y reputación.

Un servicio clásico tiene lógica fija. Un agente decide según prompts, contexto y entradas dinámicas. Esa fluidez es justamente lo que lo hace útil para un operador —entiende "reagenda la llamada con el inversor para que no choque con el board"— y también lo que lo vuelve manipulable. La relación entre lo que entra (un correo, un mensaje de Slack, un documento adjunto) y la acción privilegiada que ejecuta es opaca y fácil de explotar mediante inyección de instrucciones.

Además muchos agentes son efímeros: se levantan, actúan y se apagan sin identidad persistente. Eso hace casi imposible mantener un rastro de auditoría o atribuir acciones después del hecho.

Y hay un tema de escala. Las identidades de máquina ya superan a las humanas en una proporción de 82 a 1 según el survey de CyberArk de 2025, y los agentes aceleran esa curva. Un solo incidente de confused deputy no se queda en un error aislado: se ejecuta a velocidad de máquina, en bucle, sobre todos los sistemas conectados.

Piensa en los puntos donde tu agente toca algo que no se deshace fácil.

Un correo entra a Gmail u Outlook pidiendo, con tono apurado y firma del CEO, mover una factura o cambiar los datos bancarios de un proveedor. Si tu agente trata "parece venir del CEO" como autorización suficiente, acabas de construir el camino más limpio para un fraude de suplantación. El canal interno no es prueba de nada.

O un cliente escribe a soporte y el agente, intentando ser servicial, emite un reembolso en Stripe o cambia el plan de la cuenta. Cada paso es plausible. Ninguno tiene detrás un motivo explícito ni un registro de quién lo aprobó.

O el agente actualiza una oportunidad en HubSpot o Pipedrive, marca un deal como cerrado, cambia un owner. En un CRM, una actualización silenciosa y errónea contamina forecasts, comisiones y los siguientes diez correos que se disparan en automático. Lo mismo con un cambio de estado o de asignación en Linear que reordena el trabajo de medio equipo sin que nadie haya pedido nada.

El patrón se repite: las acciones que más daño hacen son cambios de cuenta, aprobaciones, reembolsos, actualizaciones de CRM y de soporte. Y son justo las que los despliegues apresurados dejan correr sin fricción. El Gravitee State of AI Agent Security 2026 encontró que solo el 14,4% de las organizaciones despliegan agentes con aprobación de seguridad completa. El resto los lanza sin supervisión total —y con autoridad delegada mucho mayor que la de cualquier app de la era cloud.

Antes de darle más alcance a tu agente, lo que necesitas no es más confianza. Es una capa de control de ejecución con tres propiedades por cada acción sensible.

Identidad vinculada. Toda acción atribuible a un principal único y autenticado, con rastro persistente. Si el agente mueve dinero, hay un nombre detrás —no "el agente".

Motivo explícito. El agente no actúa porque algo "parezca" venir de un canal legítimo. Actúa porque hay una autorización dentro de un alcance verificable, con chequeo de intención y contexto en tiempo de ejecución.

Evidencia auditable. Un registro que responda, meses después, quién autorizó qué y por qué. Esto es lo que faltó en los tres casos reales que mencioné.

La arquitectura que lo sostiene ya existe. Seguridad basada en capacidades en lugar de autoridad ambiental, para que cada acción exija una capacidad explícita y no herede poder por estar "dentro". Tokens de vida corta y acotados a la tarea, con rotación continua, en lugar de credenciales amplias y permanentes. Verificación de identidad por comportamiento, que comprueba en runtime si el agente actúa dentro de los parámetros esperados. Y, para las acciones de alto riesgo, un humano en el bucle —no para todo, sí para lo que no se deshace.

El principio de mínimo privilegio sigue valiendo: el agente debería asumir los mismos permisos que el usuario, o menos, y cada delegación debería ser auditable. Pero mínimo privilegio sin identidad vinculada ni prueba de autorización es media solución.

La diferencia entre un gran jefe de gabinete y un gestor de tareas nunca fue cuánto acceso tenía. Fue su criterio sobre cuándo no actuar sin confirmar. Un buen jefe de gabinete humano no transfiere fondos porque te llegó un correo apurado; te pregunta, deja constancia, confirma por un segundo canal. Ese criterio es exactamente lo que hay que codificar en la capa de ejecución de un agente.

En Moments construimos pensando en esto: un agente que vive dentro de tu correo, calendario, contactos y documentos es enormemente útil, y por eso mismo el control de ejecución no es opcional. La pregunta correcta al evaluar cualquier jefe de gabinete de IA no es "¿qué puede hacer?", sino "¿puede demostrar quién lo autorizó, con qué motivo, y dónde queda registrado?".

No te frenes en ampliar lo que tu agente hace por ti. Frénate en darle alcance sensible antes de tener esa capa. La autonomía sin atribución no es eficiencia, es responsabilidad sin dueño esperando a que algo salga mal.

Empieza por inventariar qué acciones de tu stack son irreversibles —reembolsos, cambios de cuenta, escrituras en el CRM— y exige a tu agente, para cada una, identidad, motivo y rastro. Lo demás puede correr suelto. Eso no.