Una experiencia publicada en The New Stack revela que conceder a un agente de inteligencia artificial permisos más amplios de los que necesita puede convertir un simple error lógico en una operación financiera repetida que el propio modelo no detiene. En una prueba con facturas de clientes, un agente de soporte confirmó que el pago había fallado y que no se habían retirado fondos del cliente, pero ejecutó un reembolso aunque los datos no lo respaldaban, y repitió el error cinco veces.
Claude Sonnet 5 logró detectar los seis casos diseñados para probar este fallo, mientras que Claude Haiku 4.5 falló en todos ellos. Asimismo, una sola línea en las instrucciones del sistema que pedía verificar el estado de la transacción antes de ejecutar una acción financiera bastó para resolver el problema. Sin embargo, el autor considera frágiles ambas soluciones: la organización podría sustituir el modelo por una versión más barata o modificar las instrucciones durante un experimento, haciendo desaparecer la protección sin una advertencia clara.
El permiso denegado como barrera de seguridad
La protección que resistió estos cambios consistió en impedir que el agente tuviera desde el principio el permiso billing:refund. En ese caso, la ejecución falló en la capa de permisos, independientemente del modelo o de la redacción de las instrucciones. Esta es la conclusión del principio de mínimo privilegio en la arquitectura de los agentes de inteligencia artificial: el objetivo no es solo impedir al atacante el acceso o proteger los tokens secretos, sino también impedir que un agente bien intencionado ejecute instrucciones erróneas con rapidez automática y sin supervisión humana.
La naturaleza del agente difiere de la de una cuenta de servicio tradicional que desempeña una función fija. Un agente de soporte puede leer un ticket a las 09:00, ejecutar un reembolso a las 09:04 y modificar el número de asientos a las 09:11. Por ello, el conjunto de permisos necesario para todas sus posibles tareas durante una semana no refleja necesariamente lo que necesita para una sola tarea.
¿Qué midió el experimento?
El autor construyó un entorno de prueba con 30 permisos distribuidos en nueve ámbitos dentro de una interfaz de programación de aplicaciones empresarial ficticia, que incluía tickets, usuarios, facturación, suscripciones, archivos, mensajes, auditoría, administración y búsqueda. Trece permisos podían modificar o extraer el estado. El experimento incluyó 20 tareas, cada una con un resultado que podía verificarse automáticamente, como cerrar un ticket o reembolsar el importe de una factura.
Se compararon cuatro modelos de permisos en los dos niveles de Claude Haiku 4.5 y Claude Sonnet 5, con un total de 160 ejecuciones:
- Permiso amplio: una concesión a largo plazo que incluía los 30 permisos.
- Rol fijo: un rol de soporte que incluía 17 permisos derivados de una descripción de puesto típica.
- Restricción según la tarea: conceder los permisos necesarios para cada ejecución y retirarlos al finalizar.
- Activación inmediata: comenzar sin permisos y solicitar cada permiso cuando fuera necesario, indicando su justificación.
La restricción según la tarea reduce el alcance del daño
El modelo de restricción según la tarea logró completar todas las tareas utilizando aproximadamente uno de cada quince permisos en comparación con la concesión amplia. Los rechazos ocasionales y los reintentos no provocaron un aumento significativo del número de llamadas a la interfaz.
El modelo de rol fijo fue el más débil en ambos ejes. Concedió 17 permisos, cuatro de los cuales no fueron utilizados por ninguna tarea, mientras que carecía de nueve permisos esenciales. Ampliar el rol hasta que todas las tareas tuvieran éxito habría requerido 26 permisos, frente a una mediana de solo dos permisos por tarea. Así, el rol fijo resulta demasiado amplio e insuficiente al mismo tiempo, porque basa la decisión en el título del puesto y no en el trabajo real.
El modelo de activación inmediata alcanzó un nivel igualmente bajo de alcance del daño, pero necesitó aproximadamente un 80 % más de llamadas adicionales a la interfaz. Además, el rechazo de permisos en el modelo por tarea correspondió generalmente a rutas exploratorias opcionales, mientras que el rechazo en el modelo de rol fijo fue definitivo porque bloqueó un permiso esencial.
¿Por qué es importante para las organizaciones?
Los resultados muestran que las capacidades del modelo y las instrucciones del sistema son capas defensivas susceptibles de cambiar, mientras que un permiso no concedido sigue siendo eficaz incluso al cambiar el modelo o modificar el prompt. Por ello, los equipos deberían diseñar los permisos del agente en torno a la tarea actual y hacer que los permisos sensibles sean temporales y auditables, en lugar de acumularlos en un rol permanente y amplio.
El experimento sigue limitado por un entorno sintético, 20 tareas y dos modelos de Claude; por tanto, no demuestra que los resultados vayan a coincidir en todas las organizaciones o con todos los modelos. Sin embargo, ofrece un indicador práctico claro: probar el agente no basta si la arquitectura le permite ejecutar acciones que no necesita, porque el cambio de modelo o de instrucciones puede modificar el comportamiento mientras la capacidad de causar daño permanece intacta.