Least Privilege for Agents
El principio aplicado a una ejecución agente
Esta perspectiva aplica Least Privilege a las herramientas, identidades, recursos y decisiones delegadas a un agente. El principio general conserva su canonical. Aquí la pregunta es qué autoridad efectiva necesita una ejecución para completar un encargo, sin convertir contexto disponible o iniciativa del modelo en permiso adicional.
La guía de seguridad de agentes de OWASP relaciona herramientas y alcance de permisos. El diseño debe comprobar la capacidad real del ejecutor y de los servicios alcanzables; ocultar una opción en el prompt no restringe necesariamente esa autoridad.
Del encargo a capacidades concretas
«Investigar un fallo» puede necesitar buscar símbolos, leer archivos y ejecutar pruebas acotadas. «Publicar la corrección» agrega otras operaciones. Conviene distinguir recursos, acciones, destinos, duración y datos que cada fase necesita, sin interpretar un objetivo amplio como autorización sobre todo el entorno.
Agent Permissions and Approval Boundaries desarrolla la aplicación operativa y las decisiones adicionales antes de efectos protegidos. Tener permiso para usar una herramienta no significa tener permiso para cualquier argumento que esa herramienta acepte.
Una herramienta especializada puede reducir la capacidad expuesta respecto de una shell general. Su backend también debe imponer el alcance. Una función de consulta que internamente usa una credencial administrativa conserva riesgos que su nombre no revela.
Lectura, salida e identidad
Solo lectura no equivale a ausencia de riesgo. Un agente puede leer información sensible y revelarla en otra llamada o respuesta. Data Leakage sigue esos canales; la decisión debe limitar tanto las fuentes necesarias como los consumidores autorizados.
Una herramienta puede autenticar una consulta sin exponer la credencial al modelo ni al código generado. Si la clave se entrega a un proceso, la frontera cambia. Una sesión breve limita duración, pero no vuelve pequeña la autoridad disponible durante ese tiempo.
También debe conservarse para quién se actúa. Un agente que atiende a un usuario no debería heredar acceso indiscriminado a todos los usuarios del servicio. Confused Deputy explica por qué autenticar correctamente al ejecutor no resuelve la autorización del solicitante.
Contexto y restricciones de ejecución
Context Engineering for Software Development selecciona información relevante. Leer menos material innecesario puede reducir exposición y ruido, pero no revoca permisos del proceso. Un contexto aislado puede compartir máquina y credenciales con otras tareas.
Agent Sandboxing limita recursos bajo su cobertura. Una herramienta remota o delegación puede operar en otra frontera. Reducir acceso al filesystem no impide por sí solo una mutación mediante una API autorizada.
Persistent Instructions comunica guía reutilizable. Una frase como «no desplegar» es útil para interpretar el encargo, pero no sustituye controles que retengan las credenciales o rechacen la operación. Prompt Injection puede desviar la decisión; la restricción efectiva debe seguir siendo significativa cuando esa guía falla.
Delegación y ampliación de alcance
Delegar una tarea no debería ampliar silenciosamente la autoridad del destinatario. La revisión necesita saber qué identidad actúa, qué recursos recibe y qué límites sobreviven. Una contribución puede devolver evidencia sin obtener capacidad de publicar el resultado.
Una aprobación puntual tampoco equivale a acceso general para tareas futuras. Si cambian el destino, los argumentos o los efectos, hay que comprobar que la operación siga dentro del alcance autorizado. Reutilizar una decisión solo por compartir una palabra de comando puede ocultar diferencias relevantes.
La respuesta útil ante un bloqueo identifica la operación necesaria y el límite encontrado. No convierte todo error en una solicitud de acceso administrativo ni exige intervención manual para pasos que ya estaban claramente autorizados.
Ejemplo y evidencia
En Commerce, un agente investiga Payments UI con un checkout local y datos sintéticos. Puede proponer una corrección y ejecutar sus pruebas. Una API de reembolsos y credenciales de producción no son necesarias para ese encargo. Si encuentra indicios de un problema remoto, puede devolver una hipótesis y la evidencia requerida para una decisión posterior.
Una comprobación puede observar que la operación local permitida funciona y que un intento sobre recursos fuera del encargo se rechaza antes del efecto. Debe examinar todas las rutas relevantes, no solo la herramienta que el modelo eligió en una demostración.
Más restricciones pueden reducir consecuencias y también impedir trabajo válido. El objetivo es autoridad suficiente, explícita y revisable. La calidad de la salida sigue necesitando Generated Code Verification; permisos acotados no certifican corrección del cambio.
Fuentes y alcance
- Least Privilege, fuente canónica del principio general.
- OWASP: AI Agent Security Cheat Sheet.
Fuente externa consultada el 2026-11-05. La aplicación al encargo de Commerce es síntesis editorial y no prescribe un producto o un esquema universal de aprobaciones.