Roles, permisos y derechos de uso no son lo mismo
Un rol describe responsabilidad organizativa; un permiso autoriza una acción sobre un recurso; un derecho de uso habilita una capacidad bajo una política comercial. Son ejes distintos.
El vocabulario debe existir antes que los atributos
Un proveedor de identidad puede transportar roles y atributos, pero no debería inventar su significado. Primero se define el vocabulario de la plataforma; después se decide cómo representarlo en tokens, directorios y servicios.
En ALLAN se distinguen al menos cinco ejes:
- Rol de plataforma. Responsabilidad administrativa transversal.
- Rol de organización. Autoridad dentro de un tenant.
- Permiso sobre un recurso. Acciones concretas sobre un agente, versión o conector.
- Derecho de uso. Capacidad habilitada por plan, contrato o límite.
- Policy de ejecución. Decisión sobre una herramienta o acción durante un run.
Combinar esos ejes en un claim admin=true hace imposible explicar por qué una
acción fue autorizada.
Roles
El control de acceso basado en roles asocia permisos a funciones relativamente estables de una organización. Un usuario activa uno o varios roles y hereda las acciones correspondientes.
Los roles son adecuados para expresar responsabilidades como administrar una organización o gobernar la plataforma. No capturan por sí solos todos los matices de un entorno multi-tenant: recurso, propietario, clasificación, plan o riesgo de la acción pueden requerir atributos adicionales.
Una jerarquía explícita evita inferencias informales. Un administrador de plataforma puede recibir capacidades para gobernar la configuración de un tenant, pero ese rol no le concede por sí solo acceso a cada agente o recurso del tenant. La jerarquía administrativa y los grants sobre recursos deben resolverse y probarse por separado, no inferirse en cada interfaz.
Permisos y grants sobre agentes
Un grant responde a «¿qué puede hacer esta identidad sobre este agente?». Puede distinguir lectura, edición, uso, publicación o administración.
Dos personas con el mismo rol organizativo pueden tener permisos distintos sobre un agente concreto. De igual forma, un agente compartido con un equipo no debe hacerse visible a todo el tenant por el mero hecho de existir.
Los grants también permiten separar propiedad y consumo. Quien puede invocar una versión no tiene necesariamente permiso para modificarla o promoverla.
Derechos de uso
Un derecho de uso —entitlement— responde a una pregunta comercial u operativa: «¿incluye este plan la capacidad?» o «¿queda cuota disponible?».
Ejemplos:
- acceso a una categoría de modelo;
- número de sesiones de creación;
- capacidad mensual;
- función avanzada habilitada para un tenant;
- límite ampliado concedido por contrato.
Extracto. La autorización y el derecho de uso pueden negar la misma petición por razones diferentes. Conservar esa diferencia mejora la explicación, la auditoría y la experiencia de usuario.
Un administrador puede tener autoridad para configurar una capacidad que su organización no ha contratado. Un usuario puede tener permiso sobre un agente pero haber agotado su cuota. Ninguno de esos casos debería representarse como «forbidden» sin más contexto.
El runtime no administra la autoridad humana
El motor necesita una identidad verificada para aislar tenant, usuario y estado. También debe aplicar políticas sobre herramientas y aprobaciones.
No le corresponde decidir qué persona es administradora de la plataforma ni gestionar la jerarquía humana. Esa responsabilidad pertenece a la capa de autorización que conoce roles, grants y entitlements.
Esta frontera reduce el acoplamiento: el runtime ejecuta agentes; la plataforma decide quién puede configurarlos o gobernarlos. El motor consume una decisión o un contexto de autoridad, pero no se convierte en directorio corporativo.
Identidades humanas e identidades de servicio
Una llamada entre servicios no debe simular a una persona ni heredar sus roles administrativos. Las identidades de workload necesitan:
- autenticación propia;
- audiencia y propósito limitados;
- scopes mínimos;
- rotación y revocación;
- trazabilidad hasta la petición humana o tarea raíz cuando exista;
- una política expresa para operaciones sin usuario presente.
NIST sitúa la identidad y la autorización por recurso en el centro de una arquitectura zero trust: la ubicación de red no sustituye la decisión. En una plataforma agéntica, que una llamada proceda de un servicio interno tampoco debe conceder autoridad ilimitada.
Policy de herramientas
El manifiesto de un agente declara qué herramientas necesita, pero esa declaración solo puede estrechar la capacidad disponible. La organización, el usuario, el conector y el riesgo de la acción pueden imponer límites adicionales.
El runtime aplica una decisión antes de ejecutar:
allow: la acción puede continuar;requires_approval: necesita una autoridad humana;deny: no está permitida.
La policy no debe depender únicamente de cómo el modelo describa su intención. Nombre de la herramienta, parámetros, identidad, recurso y contexto de la tarea son datos del punto de aplicación.
Autonomía y autorización
La autonomía describe cuánto puede decidir un agente dentro de un marco; no amplía ese marco. Un agente autónomo no puede atravesar un permiso denegado ni convertir una herramienta no autorizada en disponible.
Este límite es esencial frente a la «agencia excesiva» descrita por OWASP: el riesgo crece cuando un sistema recibe más funciones, permisos o autonomía de los necesarios y puede ejecutar acciones de impacto sin supervisión adecuada.
Estado y límites
La separación básica entre RBAC humano y runtime está presente en ALLAN. El modelo público no reproduce la configuración concreta del proveedor de identidad, los atributos de transición ni los contratos internos entre servicios.
El vocabulario actual es deliberadamente pequeño. Una plataforma madura puede necesitar roles de auditoría, seguridad, soporte o facturación, matrices de acción por recurso y una política específica para workloads. Este ensayo establece la separación conceptual; no presenta una matriz completa de autorización.
Referencias
Fuente editorial de ALLAN
docs/authz.md, editado para retirar atributos, rutas y detalles del proveedor de identidad.- Documentos de comunicación y metering, utilizados para distinguir policy de ejecución y derechos de uso.
Fuentes externas
- NIST, Role Based Access Control, recursos y modelo unificado de RBAC.
- NIST, Guide to Attribute Based Access Control, SP 800-162, actualización de 2019.
- NIST, Zero Trust Architecture, SP 800-207, 2020.
- OWASP, LLM06:2025 Excessive Agency, guía de seguridad, 2025.
- NIST, Artificial Intelligence Risk Management Framework 1.0, 2023.