Hay un patrón de seguridad que la industria describió hace décadas, resolvió en teoría y volvió a introducir sin darse cuenta cada vez que apareció una capa nueva de software. Se llama confused deputy, el diputado confundido, y describe a un componente que tiene más autoridad que quien le pide algo y que, al actuar en su nombre, presta esa autoridad a alguien que no debería tenerla. El nombre lo acuñó Norm Hardy a fines de los años ochenta para explicar por qué los permisos asociados al proceso, y no a la petición, terminan siendo un problema.
Los agentes de IA son el ejemplo más limpio del patrón que hemos visto en años. Un agente tiene, por diseño, más autoridad que la mayoría de quienes interactúan con él; recibe instrucciones en lenguaje natural desde múltiples fuentes; y no distingue quién le está hablando en cada fragmento de texto que procesa. Es la definición del diputado confundido, con la agravante de que aquí la confusión no es un error de programación: es el modo normal de operación.
El patrón, en una frase
El diputado confundido ocurre cuando la autoridad se aplica según quién ejecuta y no según por cuenta de quién se ejecuta. El componente tiene permisos amplios porque los necesita para su función general; alguien con menos permisos le pide una operación puntual; el componente la realiza con su propia autoridad y el sistema de destino no tiene forma de saber que el origen real era otro.
En seguridad clásica esto se llamó autoridad ambiental: permisos que están en el aire del proceso en lugar de viajar con cada solicitud. La respuesta propuesta entonces fue el modelo de capacidades, donde el permiso es un objeto que se pasa junto con la petición y solo habilita lo que esa petición necesita. Una idea vieja que vuelve a ser útil.
Dónde reaparece en agentes
El agente que lee lo que escriben terceros
Un asistente de soporte con acceso al sistema de tickets procesa un caso creado desde el formulario público. En el cuerpo del ticket hay texto redactado para el agente, no para el analista: instrucciones que le piden buscar otros casos, resumirlos y adjuntarlos a la respuesta. El agente puede leer toda la cola; el autor del ticket, nada. El agente presta su autoridad y el registro dirá que la consulta fue legítima.
El agente compartido entre clientes
En una plataforma multiinquilino, un mismo agente atiende a varias organizaciones con una única credencial de servicio hacia la base de datos y filtra por inquilino en la lógica de la aplicación. Cualquier cosa que altere esa lógica —un parámetro mal construido, una herramienta que acepta el identificador desde el texto— convierte al agente en el puente entre inquilinos. La credencial nunca distinguió a quién servía.
El agente que actúa entre sistemas
Un agente de automatización lee correos y crea tareas, o revisa un repositorio y publica comentarios. La entrada viene de un sistema con control de acceso débil y la salida va a uno con control fuerte. El agente atraviesa esa frontera con permisos de escritura y sin verificar que quien originó el contenido tuviera derecho a provocar esa acción. Es la misma cadena que describimos en la anatomía de un ataque a un sistema de IA: entrada no confiable, autoridad prestada, efecto real.
El agente no fue vulnerado. Hizo su trabajo con los permisos que le diste, para alguien que no tenía derecho a pedírselo.
Cómo se corta
Separar la identidad del agente de la de quien le habla
El primer paso es que el agente tenga identidad propia y que cada petición lleve, además, la identidad verificada del solicitante. Sin ese segundo dato no hay forma de aplicar ninguna regla: el sistema de destino solo ve al agente. Esto implica propagar el contexto de autorización por toda la cadena de herramientas, no solo en la primera llamada: trabajo de plomería, y la parte que más se omite.
Evaluar la intersección de permisos
Cada acción debería autorizarse contra dos conjuntos a la vez: lo que el agente puede hacer y lo que el solicitante podría hacer por sí mismo. Cuando el solicitante es anónimo o externo —el autor de un ticket público, el remitente de un correo— ese segundo conjunto es prácticamente vacío, y esa es la respuesta correcta. Lo desarrollamos al hablar del modelo de permisos de agentes.
Verificar el origen de cada instrucción
El contexto del modelo debería llevar marcada la procedencia de cada bloque: qué escribió el usuario autenticado, qué vino de un documento recuperado, qué devolvió una herramienta. No elimina el riesgo por sí solo, porque el modelo puede ignorar la marca, pero permite algo más importante: aplicar política determinista fuera del modelo. Una regla del tipo "ninguna acción de escritura puede originarse en un bloque de procedencia externa" se evalúa en código, no en el prompt, y por eso funciona.
Confirmación humana donde la autoridad se presta
Cuando la cadena cruza una frontera de confianza y termina en algo irreversible —enviar, publicar, pagar, borrar, otorgar acceso—, la aprobación tiene que salir del canal del modelo. No como control principal, sino como el último punto donde alguien con contexto nota que la petición no tiene sentido.
Qué mirar en tu arquitectura esta semana
Toma cada agente en producción y dibuja dos columnas: de dónde llega el texto que procesa, y qué puede hacer con lo que decide. Marca las filas donde una entrada de baja confianza alcanza una acción de alta consecuencia. Ese cruce es tu inventario de diputados confundidos, y suele ser más corto de lo que se teme. Si el ejercicio no se puede hacer porque nadie tiene la lista completa de herramientas por agente, ese es el hallazgo, y viene antes que cualquier control técnico.
La lección del patrón original sigue vigente: no se resuelve haciendo al diputado más listo. Un agente mejor entrenado sigue siendo un agente que actúa por cuenta de otros con permisos que no son de ellos. Se resuelve cambiando dónde vive la autoridad, para que viaje con la petición en lugar de quedarse pegada al proceso.