Imagina que tu empresa pone un asistente de IA a leer la bandeja de entrada de administración. Le encargas que resuma los correos y prepare respuestas. Para que funcione, quien lo configura le da acceso al correo con el permiso de siempre, el que sirve para todo: leer, enviar y borrar. Nadie lo discute porque es lo más rápido. El problema aparece el día que el asistente hace algo que nadie le pidió, y lo hace con todos los permisos que le diste.

◢¿Qué es la agencia excesiva de un agente de IA?

Un agente de IA es un asistente que no solo contesta, también hace cosas: lee archivos, consulta una base de datos, envía correos, crea tareas. Esas capacidades se le dan mediante herramientas o extensiones.

Según OWASP, la agencia excesiva es la vulnerabilidad que permite que se ejecuten acciones dañinas como respuesta a una salida inesperada, ambigua o manipulada del modelo. Lo importante es que da igual por qué falla el modelo. Puede ser una alucinación, un modelo que rinde mal o un ataque de prompt injection. Si el agente tiene poder para hacer daño, lo hará con la misma facilidad con la que hace su trabajo.

◢Las tres causas: demasiadas funciones, demasiados permisos, demasiada autonomía

OWASP señala que la raíz suele ser una de estas tres, o varias a la vez.

Demasiadas funciones. La herramienta que le das al agente puede hacer más de lo que necesita. Un ejemplo de OWASP: una extensión para leer documentos que además permite modificarlos y borrarlos. Otro: una herramienta de pruebas que se dejó instalada cuando ya no se usaba y sigue disponible para el agente.

Demasiados permisos. La herramienta tiene más acceso del necesario a los sistemas de detrás. OWASP lo ilustra con una extensión que solo debería leer datos pero se conecta a la base de datos con una identidad que también puede escribir y borrar. O con una que trabaja para un usuario concreto pero entra con una cuenta privilegiada que ve los archivos de todos.

Demasiada autonomía. El agente ejecuta acciones de alto impacto sin que nadie las confirme. El ejemplo de OWASP es una herramienta que borra documentos de usuarios sin pedir confirmación.

◢¿Cómo se ve en una empresa normal?

Piensa en tres escenarios, planteados como hipótesis, no como casos reales.

En administración, un asistente que lee facturas y las clasifica. Si además puede mover o eliminar archivos en la carpeta compartida, un error de clasificación deja de ser un fallo de texto y se convierte en documentos que desaparecen.

En atención al cliente, un chatbot que consulta el estado de un pedido. Si para hacerlo entra en el CRM con una cuenta de administrador, cualquier cliente que logre manipularlo puede acabar viendo datos de otros.

En recursos humanos, un asistente que filtra currículums. Un currículum puede contener texto escondido pensado para el modelo, y si el asistente tiene acceso a más información de la que necesita, esa puerta queda abierta.

El ejemplo que propone el propio OWASP es el más claro: una aplicación de asistente personal lee el correo con una extensión que también puede enviar. Un atacante manda un correo con instrucciones escondidas, el agente las sigue, busca información sensible en la bandeja y la reenvía a otra dirección.

◢¿Es lo mismo que la prompt injection?

No. La prompt injection es una forma de engañar al modelo. La agencia excesiva es lo que determina cuánto daño puede hacer ese engaño, o un simple error. Una prompt injection contra un asistente que solo puede leer produce, como mucho, un resumen raro. Contra uno que puede enviar, borrar y pagar, produce un incidente.

Por eso, aunque nadie garantiza que un modelo no vaya a ser engañado, sí puedes decidir qué puede hacer cuando lo engañen. Es la parte del problema que depende de ti.

◢Qué hacer antes de conectar un agente a tus sistemas

OWASP propone varias medidas. Estas son las que mejor se traducen a una pyme:

• ▹Ofrece solo las herramientas imprescindibles. Si el agente puede trabajar sin una función, no se la des.
• ▹Recorta cada herramienta a lo necesario. Para resumir correos basta un acceso de solo lectura al correo.
• ▹Evita las herramientas abiertas. Una que ejecuta cualquier comando o abre cualquier URL es mucho más arriesgada que una que solo guarda un archivo en una carpeta concreta.
• ▹Da los mínimos permisos en los sistemas de detrás, y que se apliquen allí, en la base de datos o en el servicio, no en una instrucción al modelo.
• ▹Haz que el agente actúe con la identidad del usuario que lo usa, con permisos mínimos, y no con una cuenta de servicio que lo puede todo.
• ▹Exige aprobación humana en lo que tenga consecuencias: enviar, borrar, pagar, cambiar permisos.
• ▹Registra lo que hace y limita la frecuencia de sus acciones. OWASP lo recoge como medidas que no evitan el problema pero reducen el daño.

Hay una idea de fondo que OWASP resume bien: la autorización se implementa en los sistemas de detrás, no confiando en que el modelo decida si una acción está permitida. Pedirle al asistente por favor que no borre nada no es un control de seguridad.

◢¿Y si ya tenemos agentes funcionando?

Haz un inventario sencillo. Para cada asistente, apunta tres cosas: qué herramientas tiene, con qué cuenta entra en cada sistema y qué acciones ejecuta sin que nadie las apruebe. Casi siempre aparece algo que sobra, como una cuenta con más acceso del necesario o un permiso de escritura que nadie usa.

Después, quita. Empieza por los permisos de escritura y borrado, y por cualquier cuenta de administrador. Si el agente deja de funcionar sin ellos, vuelve a darle solo lo que le falte.

Si además el equipo usa herramientas de IA por su cuenta sin que TI lo sepa, el inventario debería incluirlas. No puedes recortar permisos de un agente que no sabes que existe.

◢Una pregunta para cada nuevo asistente

Cuando construyo un asistente para una empresa, la pregunta que me hago es qué haría de más si se equivocara o lo engañaran. Si la respuesta incomoda, el diseño todavía no está terminado. Y es mucho más fácil ajustar los permisos antes de ponerlo en marcha que después de un susto.

Si quieres que tu plantilla entienda estos riesgos sin tecnicismos y sepa qué pedir antes de dar acceso a una IA, es uno de los temas que trabajo en mis formaciones de ciberseguridad e IA para empresas.