Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Permisos de agentes
Un agente puede decidir que necesita leer un fichero, enviar un email o ejecutar un comando. Esa decisión no debería otorgarle por sí sola autoridad para hacerlo.
Los permisos son los controles que determinan qué acciones pueden pasar de una decisión del modelo a una operación real. Pueden actuar sobre una tool concreta, requerir aprobación, limitar qué identidad o credencial se utiliza o hacer que el sistema rechace una operación aunque el modelo la solicite correctamente.
Esto introduce una separación importante: capacidad y autoridad no son lo mismo. Que el modelo pueda expresar una acción no significa que esté autorizado para producir su efecto.
Capacidad y autoridad
Una tool amplía las acciones que el modelo puede solicitar. El harness de agente expone esa capacidad al modelo y convierte una tool call aceptada en una operación real.
Entre ambos pasos puede existir una frontera de permisos.
Por ejemplo, un agente puede conocer una tool send_email. El modelo puede generar una llamada válida con destinatario, asunto y contenido, pero el harness todavía puede:
- Permitirla directamente.
- Pedir aprobación.
- Rechazarla.
- Ejecutarla con una identidad que no tenga permiso para enviar.
- Aplicar una política adicional sobre el destinatario o la operación.
Por eso inspeccionar únicamente las tools disponibles no describe la autoridad real del agente.
Desde seguridad interesa la combinación completa:
acción solicitada → control de permisos → identidad utilizada → recurso alcanzable → efecto
Una prompt injection puede alterar la decisión del modelo. Los permisos determinan qué puede conseguir esa decisión después.
Controles de permisos
Los sistemas agentivos pueden colocar controles antes de ejecutar determinadas acciones.
Una configuración puede permitir operaciones de bajo impacto automáticamente y detener otras para aprobación. También puede deshabilitar una tool por completo o aplicar reglas sobre usos concretos.
La nomenclatura depende del harness. Algunos productos utilizan políticas equivalentes a allow, ask y deny; otros combinan modos de ejecución, configuración administrativa y aprobaciones puntuales. El principio es el mismo: el modelo solicita la acción y un componente externo decide si puede ejecutarse.
Este control es determinista respecto a la regla aplicada. Una instrucción dentro del prompt puede convencer al modelo de que solicite una operación diferente, pero no cambia por sí sola una regla deny aplicada por el harness.
Aprobación
Una aprobación humana añade otra decisión antes del efecto.
Si una acción requiere confirmación, el agente puede explicar que necesita enviar un mensaje o modificar un recurso y esperar a que una persona lo permita. Esto resulta útil cuando la intención no puede decidirse únicamente con una política estática.
Pero la aprobación no equivale a least privilege.
Aprobar una operación una vez no reduce necesariamente la autoridad de la credencial que existe detrás, y una interfaz que solicita confirmaciones continuamente puede acabar convirtiéndolas en una acción rutinaria. La aprobación funciona mejor como control para decisiones donde el contexto humano importa que como única frontera frente a una capacidad excesivamente potente.
Capacidad efectiva
Los permisos deben analizarse según el efecto que el agente puede producir, no únicamente según el nombre de cada tool.
Supongamos que un agente dispone de:
delete_file.bash.
La política bloquea delete_file.
Eso impide que el agente utilice ese camino concreto. No impide necesariamente borrar el fichero: bash puede ejecutar rm.
La misma situación aparece con otras capacidades. Bloquear una tool especializada de acceso web no elimina el acceso web si una shell puede ejecutar curl o wget y el runtime conserva conectividad. Restringir una operación Git específica tampoco evita necesariamente el mismo efecto si Bash, el binario git y las credenciales necesarias siguen disponibles.
Por tanto:
tool denegada ≠ capacidad denegada
Una frontera de permisos es efectiva cuando cubre todas las rutas relevantes hacia el efecto que intenta controlar.
Esto hace especialmente importantes las tools genéricas. Una tool muy específica suele tener un conjunto limitado de efectos. Una shell, un navegador con sesión autenticada o un cliente HTTP genérico pueden representar muchas capacidades distintas detrás de una única interfaz.
Desde una perspectiva de pentesting, el inventario útil es el de efectos alcanzables por cualquier camino disponible. La lista de tools permitidas es sólo una parte.
Identidad delegada
Muchas acciones de un agente se ejecutan en nombre de otra identidad.
Un agente que trabaja con GitHub, Gmail, Slack o un servidor MCP puede utilizar una credencial asociada a un usuario, una cuenta de servicio o una aplicación. Esa identidad tiene permisos propios sobre el sistema de destino.
El modelo no obtiene automáticamente toda la autoridad del servicio. Obtiene la que pueda ejercer a través de las credenciales y operaciones que el sistema le haya delegado.
Por ejemplo, un token que sólo permite leer emails puede hacer que una llamada a send_email falle aunque la tool exista y el control de permisos permita utilizarla. Con una credencial que también permita enviar, la misma decisión puede producir un efecto externo.
Los scopes son una forma habitual de expresar parte de esa autoridad. En sistemas basados en OAuth, incluido MCP sobre HTTP, el servidor puede validar qué identidad presenta el token y qué scopes contiene antes de permitir una operación.
La autoridad efectiva puede verse así:
tool disponible → ejecución autorizada → credencial presentada → permisos sobre el recurso
Si cualquiera de esas capas rechaza la operación, ese camino no alcanza el efecto.
También puede ocurrir lo contrario: una credencial excesivamente potente puede ampliar mucho el impacto de una decisión equivocada aunque la tarea original sólo necesitase una fracción de sus permisos.
Ejemplo: agente de email
Supongamos que un agente recibe esta tarea:
Resume los emails pendientes que requieren mi atención.
Para hacerla dispone de dos capacidades:
- Leer emails.
- Enviar emails.
Uno de los mensajes recuperados contiene una prompt injection indirecta que intenta convencer al agente de que reenvíe información de otros correos a una dirección controlada por el atacante.
La prompt injection ocurre cuando ese contenido no confiable consigue que el modelo solicite una acción fuera de la intención del usuario. A partir de ahí, los permisos deciden si esa solicitud puede ejecutarse.
Si send_email está deshabilitada, la decisión manipulada no puede utilizar esa tool. Si requiere aprobación, la operación se detiene antes de ejecutarse y el usuario puede rechazarla. Si la credencial utilizada sólo permite lectura, el servicio de email tampoco debería aceptar el envío.
En cambio, si el agente tiene autorización automática para enviar mensajes y opera con una identidad capaz de hacerlo, la misma decisión manipulada tiene un camino hasta un efecto externo.
La cadena completa sería:
email controlado → decisión manipulada → solicitud de envío → control de permisos → identidad delegada → email externo
El ataque no cambia porque el modelo utilice una tool específica o una API distinta. Lo importante es si existe una ruta autorizada desde la decisión hasta el efecto.
Este escenario muestra también por qué bloquear únicamente send_email puede no ser suficiente en una arquitectura más amplia. Si el agente conserva un navegador autenticado, una shell con acceso a una API de correo o cualquier otra capacidad equivalente, hay que analizar si esas rutas permiten conseguir el mismo resultado.
Least privilege y blast radius
La autoridad necesaria debería partir de la tarea.
Si un agente sólo tiene que resumir emails, necesita poder leerlos. Poder enviarlos, borrarlos o modificar reglas del buzón amplía su autoridad sin ser necesario para esa tarea.
La diferencia puede expresarse de forma simple:
autoridad necesaria < autoridad concedida → blast radius innecesario
Esto importa incluso cuando el modelo funciona correctamente la mayor parte del tiempo. Una prompt injection, un error de razonamiento o una instrucción ambigua sólo puede producir efectos dentro de las capacidades que el sistema pone a su alcance.
El principio de least privilege no elimina esos fallos. Reduce lo que pueden conseguir.
La misma idea se aplica a la granularidad de la identidad. Una credencial limitada a un repositorio ofrece una superficie distinta de otra con escritura sobre toda una organización. Un token de email de sólo lectura tiene un blast radius diferente de una sesión completa del usuario.
Para evaluar un agente resulta útil comparar:
- Qué necesita hacer para completar la tarea.
- Qué acciones puede solicitar.
- Qué caminos alternativos ofrecen el mismo efecto.
- Qué autoridad tienen las identidades utilizadas detrás de esos caminos.
La diferencia entre los puntos 1 y 4 describe buena parte del blast radius innecesario.
Frontera de permisos y frontera de ejecución
Los permisos no describen por sí solos todo lo que puede ocurrir después de ejecutar una acción.
Un harness puede autorizar bash para lanzar npm test. Esa decisión responde a si el comando puede ejecutarse.
Una vez iniciado, el proceso puede tener acceso a otros ficheros, variables de entorno, procesos o conexiones de red según el entorno donde se ejecute. Esas capacidades dependen de otra frontera.
La aprobación y el sandboxing suelen aparecer juntos en sistemas reales, pero resuelven preguntas diferentes:
Frontera de permisos: ¿se permite iniciar esta acción?
Frontera de ejecución: una vez iniciada, ¿qué puede alcanzar realmente su ejecución?
El sandboxing y egress tratan esa segunda frontera: qué puede alcanzar la ejecución y por dónde puede comunicarse fuera del entorno.