Un agente no distingue borrar una base de datos de descargar un informe
Para un modelo que opera una interfaz, ambas acciones son el mismo rectángulo. El argumento a favor de permisos estructurales, y lo que le falta para ser algo más que una tesis.
Cualquier agente que opere una interfaz ve lo mismo en todas partes: rectángulos. El mismo cursor, el mismo clic, el mismo peso. Nada en la pantalla le indica que un botón se lleva por delante la base de datos de producción y que el de al lado solo descarga un informe. Para el modelo, ambos son la misma acción hasta que una de las dos ya se ha ejecutado.
De ahí sale el argumento: el problema de dar a un agente acceso directo a herramientas y paneles no es que sea temerario, es que cada acción le pesa lo mismo. Un humano duda antes de pulsar el botón rojo, repasa dos veces antes de borrar algo. El agente no tiene ese reflejo: actúa sobre patrones, no sobre consecuencias. Un clic equivocado a las tres de la mañana sin nadie mirando es, en el registro, una tarea completada más.
Permisos como estructura, no como teatro
La conclusión que se defiende es que los permisos y las aprobaciones no pueden ser un adorno. Tienen que formar parte de la arquitectura: qué acciones puede ejecutar el agente por su cuenta, cuáles exigen que firme un humano y a cuáles no debería poder llegar nunca. No hace falta que el agente juzgue mejor; hace falta que el sistema que lo rodea ponga mejores límites.
Suena razonable, y es casi un lugar común en cualquier equipo que haya metido un agente en un flujo con acceso a infraestructura real. El detalle es que el texto se queda ahí. No hay un incidente concreto, ni cifras, ni caso de estudio, ni una herramienta que resuelva el reparto de permisos. Es una tesis, no un informe, y llega sin nada que un administrador de sistemas pueda llevarse a su despliegue esta semana.
Tampoco hay respuesta a la parte difícil: cómo se clasifica una acción. Que borrar una tabla sea crítico lo ve cualquiera; el problema son las intermedias, las que parecen inocuas y encadenadas acaban tocando producción. Un agente que solo ve funciones expuestas como herramientas no tiene forma de saber que el tercer paso de su plan era irreversible.
Para quien despliega agentes con acceso a paneles internos, la decisión de arquitectura no es qué modelo usar, sino dónde se corta el acceso y quién aprueba qué. Y eso hoy se resuelve a mano, framework a framework, sin un estándar que ordene las acciones por riesgo. Queda por ver si aparece uno o si seguimos confiando en que el botón rojo no esté al alcance.
