Explorar notas
Permisos de agentes
El modelo puede decidir que necesita leer un fichero, enviar un email o ejecutar un comando. Convertir esa decisión en un efecto real depende de controles externos al modelo: qué tools están disponibles, qué política permite utilizarlas y con qué identidad se ejecuta la operación.
Los permisos del agente son esa frontera entre una acción solicitada y una acción autorizada.
Capacidad y autoridad
Una tool amplía las operaciones que el modelo puede solicitar. El harness de agente recibe la tool call y puede permitirla, pedir aprobación o rechazarla antes de que llegue al runtime o al servicio externo.
Supongamos que existe una tool send_email. Una call válida todavía puede encontrar varios controles:
- La tool está permitida para esa tarea.
- La operación necesita aprobación del usuario.
- Una regla limita destinatarios o tipos de mensaje.
- La credencial utilizada solo permite lectura y el servicio rechaza el envío.
La lista de tools describe capacidades expuestas al modelo; la autoridad real aparece al combinar esas capacidades con políticas e identidad.
Aprobación
La aprobación humana es útil cuando la intención depende del contexto. Un agente puede preparar un mensaje y detenerse antes de enviarlo para que una persona revise destinatario y contenido.
Ese control no reduce los permisos de la credencial que existe detrás. Si la cuenta puede borrar un repositorio completo, aprobar una operación concreta no transforma esa cuenta en una identidad de menor privilegio. Por eso aprobación y least privilege resuelven problemas distintos.
Capacidad efectiva
Durante una auditoría interesa el efecto alcanzable, no solo el nombre de cada tool.
Si un agente tiene delete_file y también bash, bloquear la primera ruta no impide necesariamente borrar un fichero: la shell puede ejecutar rm. Lo mismo ocurre con una tool web si Bash conserva curl, o con una operación Git específica si están disponibles el binario git y las credenciales necesarias.
tool denegada ≠ capacidad denegada
Las interfaces genéricas merecen especial atención. Una shell, un navegador autenticado o un cliente HTTP pueden representar muchas operaciones detrás de una única capacidad. En pentesting conviene inventariar los efectos que pueden alcanzarse por cualquiera de esas rutas y después comprobar dónde se aplica realmente la política.
Identidad delegada
Muchas acciones se ejecutan con una credencial asociada a un usuario, una cuenta de servicio o una aplicación. Esa identidad añade otra frontera independiente de la decisión del modelo.
Por ejemplo, una tool send_email puede estar habilitada y pasar el control del harness, pero un token OAuth de solo lectura debería hacer que el servicio rechace el envío. Con otra credencial que incluya permisos de escritura, la misma tool call puede producir el efecto.
Los scopes expresan parte de esta autoridad en muchos sistemas OAuth, incluido MCP sobre HTTP. Para evaluar una operación hay que comprobar qué credencial se presenta y qué permisos tiene sobre el recurso concreto, no asumir autoridad a partir de que la tool exista.
Una credencial demasiado amplia aumenta el blast radius de cualquier decisión equivocada. Un token limitado a un repositorio o a lectura de correo expone una superficie muy distinta de una sesión completa del usuario.
Ejemplo: agente de email
Un agente recibe esta tarea:
Resume los emails pendientes que requieren mi atención.
Para completarla necesita leer mensajes. Supongamos que además dispone de capacidad para enviarlos y uno de los emails recuperados contiene una prompt injection que intenta convencerlo de reenviar información a una dirección controlada por el atacante.
A partir de la decisión manipulada pueden aparecer varios frenos:
send_emailestá deshabilitada para esa tarea.- El envío requiere aprobación y el usuario lo rechaza.
- La credencial es de solo lectura y el servicio deniega la operación.
- Otra política impide enviar a ese destinatario.
Si la tool está permitida automáticamente y la identidad tiene autoridad para enviar, la decisión dispone de una ruta hasta el efecto externo.
Bloquear únicamente send_email tampoco basta si el mismo agente conserva otra ruta equivalente, por ejemplo un navegador autenticado o una shell con acceso a la API de correo. El inventario de permisos tiene que cubrir las capacidades efectivas, no solo la interfaz más obvia.
Least privilege y frontera de ejecución
La autoridad debería partir de lo que necesita la tarea. Un agente que solo resume emails necesita lectura; envío, borrado o modificación de reglas del buzón amplían el impacto posible sin ayudar a completar ese trabajo.
Para revisar el blast radius resulta útil comparar:
- Qué efectos exige la tarea.
- Qué acciones puede solicitar el agente.
- Qué rutas alternativas producen esos mismos efectos.
- Qué permisos tienen las identidades que ejecutan las operaciones.
Los permisos responden a si una acción puede empezar y bajo qué autoridad. Una vez arrancado un proceso, todavía queda otra pregunta: qué recursos puede alcanzar ese código dentro de su entorno. Sandboxing y egress cubre esa frontera de ejecución.
Un harness puede autorizar bash para lanzar npm test; el sandbox determina después qué ficheros, credenciales, procesos y conexiones puede utilizar ese comando y cualquiera de sus subprocesos.