La agencia excesiva es un problema de permisos disfrazado de IA

La agencia excesiva (Excessive Agency) ocupa el puesto LLM03 en el OWASP Top 10 for LLM Applications 2026 [1]. Es la entrada que más le importa a cualquiera que opere infraestructura porque, a diferencia de la mayor parte de la lista, tiene que ver sobre todo con aquello a lo que conectaste el modelo y muy poco con el modelo en sí.

Eso importa porque determina quién debe solucionarlo. Una alucinación es un problema del modelo. Una alucinación que elimina una tabla de base de datos es un problema de permisos.

El problema

A un asistente de operaciones se le pide liberar espacio en disco en un nodo de staging. Dispone de una herramienta de shell, porque era la forma más rápida de hacerlo útil. Las credenciales con las que se ejecuta son las que el equipo de plataforma ya tenía a mano, porque aprovisionar una nueva identidad suponía abrir un ticket. Funciona sin supervisión, porque tener a una persona aprobando cada paso anulaba el objetivo.

Interpreta "liberar espacio" de forma demasiado generosa y elimina un directorio que el entorno de staging compartía con otro servicio. El modelo no falló en nada. Hizo exactamente lo que permite una herramienta de shell con credenciales amplias y sin ningún paso de confirmación.

Cada elemento de ese resultado quedó decidido antes de que el modelo se ejecutara: qué herramientas existen, a qué pueden llegar esas herramientas y si algo se detiene antes de la ejecución.

Por qué con la IA es diferente

El software tradicional falla de maneras que se pueden enumerar. Un script que contiene rm -rf ejecutará rm -rf cuando se cumplan sus condiciones, y tú puedes leer esas condiciones. Un modelo elige en tiempo de ejecución entre cualquier cosa que le hayas expuesto, y esa elección depende de texto que puede haber llegado desde fuera de tu sistema.

OWASP divide esa combinación en tres causas raíz, y cada una tiene una solución distinta.

La primera es el exceso de funcionalidad, donde el modelo puede invocar herramientas que la tarea no necesita: un asistente de resúmenes con una herramienta de shell, o un bot de soporte con un endpoint de eliminación porque el cliente de la API lo incluía por casualidad. A menudo nadie eligió esto de forma consciente; la lista de herramientas creció simplemente a partir de lo que resultaba cómodo de conectar.

La segunda es el exceso de permisos. Las herramientas existen por buenos motivos, pero se ejecutan con más privilegios de los necesarios, y aquí es donde los equipos de infraestructura encuentran sus propias huellas. El agente hereda una cuenta de servicio pensada para un operador humano, o se ejecuta en un nodo cuyo rol de instancia tiene acceso a toda la cuenta. El modelo pide una tabla y la credencial le abre la base de datos entera.

La tercera es el exceso de autonomía, donde la acción se ejecuta sin nadie en el bucle de control. A veces eso es lo adecuado. Otras veces significa que ocurre una operación irreversible porque un sistema probabilístico llegó a una conclusión aparentemente plausible.

La edición de 2026 también vincula esto con riesgos específicos de agentes, donde el mismo fallo aparece categorizado como uso indebido de herramientas (Tool Misuse) y abuso de identidad y privilegios (Identity and Privilege Abuse) en el OWASP Top 10 for Agentic Applications [2]. El enfoque varía, pero la pregunta de fondo es idéntica: ¿a qué puede acceder este componente y con los privilegios de quién?

Lo que de verdad funciona

Aborda las soluciones por orden de lo deterministas que resultan, porque ese es también el orden de cuánto puedes confiar en ellas.

Otorga al agente su propia identidad. Eso implica un principal dedicado en lugar de la cuenta del equipo de plataforma o el rol ambiental del nodo, de modo que lo que hizo sea atribuible y lo que pueda hacer esté acotado de manera independiente a cualquier persona. En Kubernetes, esto se traduce en una ServiceAccount dedicada con su propio RoleBinding en lugar del valor por defecto del espacio de nombres. En una cuenta en la nube, es un rol asumido de forma explícita y no un perfil de instancia que hereda todo lo que corre en esa máquina.

En concreto, en Kubernetes el pod del agente no debe ejecutarse bajo la ServiceAccount default del espacio de nombres, que suele ser el camino de menor resistencia y la causa por la que tantas cargas de trabajo acaban con más privilegios de los previstos. Debe recibir su propia ServiceAccount, vinculada a un Role que declare expresamente los verbos y recursos que necesita, en el espacio de nombres donde los necesita. Si el agente interactúa con un proveedor de nube, debe asumir un rol de forma explícita en lugar de heredar el perfil de instancia del nodo, ya que ese perfil se comparte con cualquier otro pod alojado en ese mismo nodo.

La prueba es simple: si no puedes responder "¿qué credencial usó el agente y qué permite exactamente esa credencial?" en menos de un minuto, la identidad está mal configurada, sin importar cómo se hayan configurado las herramientas.

Aplica solo lectura por defecto y haz de la escritura una excepción con nombre propio. La mayoría de las tareas de un agente son de consulta. Cuando la escritura sea verdaderamente necesaria, limítala al recurso específico y no al servicio completo: este prefijo de bucket, esta tabla o este espacio de nombres.

Restringe el tráfico de salida (egress). Un agente con capacidad para alcanzar hosts arbitrarios puede exfiltrar cualquier dato que pueda leer, y la inyección de prompts convierte esa amenaza en una vía realista y no puramente teórica. Una política de red (NetworkPolicy) con una lista de permitidos es determinista y se aplica de forma estricta al margen de lo que decida el modelo.

Exige confirmación para lo irreversible: borrados, pagos, rotación de credenciales o cualquier acción que cruce tu perímetro. Aplica este control en la capa de la herramienta y no en el prompt del sistema. Una instrucción en el prompt es una sugerencia, y el mismo canal de texto que la transporta puede transportar otra instrucción para ignorarla.

Proporciónale un mecanismo de parada, es decir, algo que suspenda la carga de trabajo y revoque las credenciales sin requerir un nuevo despliegue. Escalar un despliegue a cero detiene el trabajo nuevo, pero no invalida un token que ya esté en tránsito; por eso, la detención debe incluir revocación para ser efectiva. Pruébalo antes de necesitarlo y documenta quién está autorizado a activarlo, porque un botón de parada de emergencia que exige encontrar a la única persona que sabe cómo funciona no está realmente disponible a las 3am.

Las cuatro primeras medidas corresponden a configuración de infraestructura. Ninguna exige la colaboración del modelo, motivo por el cual conviene aplicarlas en primer lugar.

Lo que no funciona

Pedirle al modelo que tenga cuidado no se sostiene. "No borres nada sin preguntar" es una indicación que compite con todas las demás instrucciones en la ventana de contexto, incluidas aquellas que puedan provenir de un documento que se le pidió leer. En el mejor de los casos es una preferencia, y nada garantiza su cumplimiento.

Usar una única cuenta de servicio para toda la flota de agentes otorga a cada agente tantos privilegios como requiera la tarea más crítica de cualquiera de ellos, además de arruinar la trazabilidad cuando algo sale mal.

Los flujos de aprobación que nadie lee son otro punto débil. Un paso de confirmación que salta cuarenta veces al día acostumbra a la gente a aprobar de forma automática. El control funciona cuando es puntual; si se activa continuamente, el alcance de las funciones está mal planteado.

Asumir que el acceso de solo lectura es inocuo también es un error. El acceso de lectura sobre un almacén que contiene credenciales, datos personales o registros de clientes constituye una vía directa de exfiltración. El principio de mínimo privilegio se aplica también a las lecturas.

Considerar fija la lista de herramientas permite que se descontrole con el tiempo. Los frameworks de agentes hacen que añadir una herramienta sea trivial, lo que provoca que la superficie de ataque crezca sin que nadie registre la decisión en ningún sitio. Cualquier proceso de revisión que apliques a nuevos endpoints de API debería aplicarse también aquí.

Por último, no confundas el aislamiento en un entorno de pruebas (sandboxing) con la delimitación de permisos. Un contenedor limita lo que el proceso puede tocar en el host. No hace absolutamente nada frente a una credencial dentro de ese contenedor que sea válida contra tu base de datos de producción. Conviene disponer de ambos controles y ninguno sustituye al otro.

Por dónde empezar

• Documenta cada herramienta que tus agentes pueden invocar y quién autorizó cada una. La lista suele ser más larga de lo que se espera y la segunda columna a menudo queda en blanco.
• Comprueba bajo qué identidad se ejecutan. Si está compartida con un humano o heredada de un nodo, corregirlo es la tarea de mayor valor para este trimestre.
• Identifica las acciones irreversibles en esa lista de herramientas y añade una confirmación previa en la capa de la herramienta.
• Configura una lista de permitidos para el tráfico de salida en cualquier entorno que ejecute inferencia o cargas de trabajo de agentes.
• Ensaya el mecanismo de parada. Suspende un agente, revoca su credencial y confirma que ha dejado de funcionar. Lleva diez minutos y convierte una suposición en un hecho verificado.

La agencia excesiva ocupa esa posición porque los agentes han llegado a producción. Los equipos de infraestructura llevan años aplicando estos mismos controles. La novedad reside en que el elemento regulado toma decisiones en tiempo de ejecución, y por esa misma razón las restricciones deben residir fuera de él.

Fuentes

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, publicado el 3 de agosto de 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, publicado el 9 de diciembre de 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/