Pérdida de datos por permisos excesivos

Cuando a un agente se le da la cuenta del equipo, o un rol amplio para no tener que pedir permisos uno por uno, recibe todo lo que ese equipo podría hacer alguna vez, incluido lo que el agente no hará nunca en su trabajo normal. La diferencia entre lo concedido y lo usado es el radio de impacto que se le regala a un error del modelo, a una instrucción mal entendida o a un texto inyectado. El Top 10 de OWASP para aplicaciones con LLM, en su edición 2025, lo llama agencia excesiva: funciones, permisos o autonomía de más.

El permiso mínimo se deriva de las tareas que el agente tiene que hacer y se comprueba con datos: qué permisos usó en los últimos meses, cuáles no tocó nunca y cuáles no corresponden a ninguna tarea. Un permiso que ninguna tarea necesita no se deja por si acaso; se retira, y si algún día hace falta, se pide como un cambio.

La tabla de permisos con su uso es la herramienta más simple de una revisión de accesos: cada permiso con la fecha en que se concedió, el cambio que lo aprobó, cuántas veces se usó y qué tarea lo necesita. Los que tienen cero usos son los primeros candidatos a retirar.

Los más interesantes, sin embargo, son los que casi nunca se usan. Un permiso usado una sola vez en noventa días puede ser justo el de la vez que salió mal, y en una revisión periódica pasa desapercibido porque «sí se usa».

El alcance de una pérdida de datos se mide contra la intención del pedido, no contra lo que dijo el agente. La intención estaba escrita en el ticket: una lista de comercios de prueba. Lo que se borró está en el resultado de la herramienta. La diferencia entre las dos listas son los clientes que no tenían por qué perder nada.

Se cuenta por cliente, no por registro: a la gerencia y a los clientes les importa cuántos comercios perdieron datos, y cada uno de ellos es una llamada, una restauración y, quizá, una compensación.

Un respaldo devuelve el estado del momento en que se tomó. Lo que se escribió entre ese momento y el borrado se pierde, aunque la restauración «salga bien». Por eso la bitácora de una restauración se lee con dos preguntas: desde qué instantánea se restauró y qué se creó después de ella.

En los comercios de prueba esa pérdida no importa a nadie. En los clientes reales es la que se cuenta, se explica y se repone a mano cuando se puede.

Hay cuatro formas de achicar el radio de impacto de un agente, y se combinan. Retirar lo que ninguna tarea usa. Separar en otra cuenta, con otra aprobación, lo poco que sí hace falta y es peligroso. Partir lo irreversible en dos pasos, para que el agente haga solo el reversible. Y acotar cada acción a identificadores concretos que vienen del pedido, no a filtros que arma el modelo.

Ni una instrucción en el prompt de sistema ni un registro más detallado recortan un permiso: el primero depende de que el modelo obedezca y el segundo cuenta el daño después.