Un asistente LLM puede eliminar registros y enviar correos de forma autónoma. ¿Cómo reduces el riesgo?
Respuesta breve
La autonomía sin límites más el acceso a herramientas es la «agencia excesiva» de OWASP LLM: un modelo manipulado o equivocado puede tomar acciones destructivas. Acótalo con herramientas de mínimo privilegio, exige confirmación humana para operaciones irreversibles, y mantén los permisos estrechos y auditados. Confiar en él o darle admin amplía el radio de impacto, y ocultar un botón en la interfaz no hace nada respecto a la capacidad subyacente del modelo de invocar la acción.
El asistente es genuinamente útil: puede resolver tickets eliminando registros obsoletos y enviando correos a los clientes, todo por su cuenta. El problema es que «por su cuenta» más «destructivo» más «un modelo que puede ser manipulado» es la receta para un error rápido y automatizado.
El riesgo: agencia excesiva
OWASP lo llama agencia excesiva — conceder a un LLM demasiada funcionalidad, autonomía o permiso en relación con cuán fiables son sus decisiones. Un modelo puede equivocarse, o puede ser dirigido por una inyección de prompt oculta en un ticket, un correo o un documento recuperado. Cuando esa mala decisión está conectada a herramientas reales (eliminar, enviar, pagar, aprovisionar), el modelo se convierte en un actor automatizado que ejecuta la mala intención del atacante o la suya propia a velocidad de máquina. El radio de impacto es todo lo que las herramientas puedan tocar.
Cómo reducirlo
- Herramientas con mínimo privilegio. Da al agente el conjunto más pequeño de herramientas estrechamente acotadas que necesita — lectura donde la lectura baste, sin eliminación general, sin token de admin amplio.
- Humano en el bucle para acciones irreversibles. Las operaciones destructivas o difíciles de deshacer (eliminación masiva, envío de correos externos, pagos) deben exigir confirmación humana explícita, no autoejecución silenciosa.
- Permisos acotados y auditables. Limita cada herramienta por alcance, tasa y destino; registra cada invocación con sus entradas e identidad, para que las acciones sean revisables y reversibles.
- Fallo seguro. Prefiere borrado lógico/colas y operaciones reversibles, para que un error pueda revertirse.
Por qué los distractores son peligrosos
- «Confía en él»: la intención no es un control. Un diseño útil sin barreras es exactamente lo que se explota.
- «Dale admin»: maximizar el privilegio maximiza el radio de impacto — lo opuesto a lo que quieres para un actor no determinista y manipulable.
- «Oculta el botón de eliminar»: el peligro es la capacidad del modelo de invocar la acción, no un elemento de interfaz. Ocultar el botón deja la herramienta subyacente plenamente invocable.
Qué quieren oír los entrevistadores
Que nombras la agencia excesiva, la conectas con la inyección de prompts, y acotas al agente con herramientas de mínimo privilegio, confirmación humana para acciones irreversibles, y permisos auditados y reversibles — en vez de confiar en buenas intenciones u ocultar la interfaz.
Posibles preguntas de seguimiento
- ¿Qué acciones concretas pondrías tras una confirmación humana, y por qué esas?
- ¿Cómo se combina la agencia excesiva con la inyección de prompts para causar daño real?
- ¿Qué registrarías para que una mala acción autónoma sea reconstruible después?