Las plataformas de automatización de IA manejan datos sensibles y workflows críticos. Registros de clientes fluyen a través de los pasos de las recipes. Informes financieros se generan y distribuyen. Comunicaciones internas se redactan y envían. El modelo de control de acceso necesita estar a la altura de lo que está en juego.
“Administrador o Usuario” no es suficiente. Necesita un oficial de cumplimiento que pueda leer registros de auditoría pero no pueda ejecutar nada. Necesita líderes de departamento que administren las automatizaciones de su equipo pero no puedan tocar otros departamentos. Necesita límites claros que se mapeen a su organigrama, no un simple interruptor binario.
Este artículo cubre el sistema RBAC de JieGou: la jerarquía de 6 roles, 26 permisos granulares, sobrescrituras con alcance de departamento y el mecanismo de cumplimiento que se ejecuta en cada llamada a la API.
La jerarquía de 6 roles
Cada usuario en JieGou tiene un rol global — un nivel numérico único que determina sus permisos base en toda la cuenta.
| Rol | Nivel | Propósito |
|---|---|---|
| Owner | 50 | Creador de la cuenta. Acceso completo incluyendo eliminación de cuenta. |
| Admin | 40 | Gestión completa: facturación, usuarios, claves API, analíticas entre departamentos. |
| Dept Lead | 30 | Líder de departamento. Editar/eliminar cualquier contenido en sus departamentos. Instalar packs. Promover workflows. |
| Member | 20 | Usuario estándar. Crear contenido, editar propio, ejecutar recipes/workflows, gestionar programaciones. |
| Auditor | 15 | Acceso de solo lectura a registros de auditoría, analíticas, gobernanza. No puede crear ni ejecutar. |
| Viewer | 10 | Acceso de solo lectura al contenido. No puede ejecutar nada. |
Los niveles numéricos no son arbitrarios. Permiten verificaciones de permisos O(1) — en lugar de iterar a través de listas de roles, el sistema compara dos enteros. Un permiso requiere un nivel mínimo, y el usuario lo cumple o no.
El rol de Auditor
Auditor es la adición más reciente, diseñado específicamente para cumplimiento. Se ubica entre Viewer (10) y Member (20) en el nivel 15.
La diferencia clave con Viewer: los Auditores obtienen el permiso audit:read. Pueden acceder a registros de auditoría, paneles de analíticas e informes de gobernanza. Los Viewers no pueden.
La diferencia clave con Member: los Auditores no pueden crear contenido, ejecutar recipes, ejecutar workflows ni gestionar programaciones. Observan e informan. Nada más.
Esto importa para industrias reguladas. Su oficial de cumplimiento necesita verificar que los workflows siguen las políticas, que el manejo de datos cumple los requisitos y que la actividad de los usuarios se alinea con su marco de gobernanza. No debería necesitar — y no debería tener — la capacidad de modificar o ejecutar nada.
Los Auditores están disponibles en el mapeo de grupo SSO a rol, para que pueda aprovisionar automáticamente oficiales de cumplimiento desde su IdP. Mapee su grupo compliance-team o internal-audit al rol de Auditor, y los nuevos empleados en esos grupos obtienen el acceso correcto en su primer inicio de sesión. Sin asignación manual de roles.
26 permisos en 8 categorías
Los roles son abreviaciones. Los permisos son lo que realmente se verifica. JieGou define 26 permisos granulares organizados en 8 categorías:
Cuenta (4 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
account:delete | Owner | Eliminar toda la cuenta |
account:admin | Admin | Acciones administrativas (configuración SSO, ajustes de cuenta) |
account:settings | Admin | Gestionar ajustes a nivel de cuenta |
account:billing | Admin | Gestionar facturación y suscripción |
Usuarios (2 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
users:manage | Admin | Gestionar todos los usuarios en la cuenta |
users:manage-department | Dept Lead | Gestionar usuarios dentro de su(s) departamento(s) |
Contenido (6 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
content:create | Member | Crear nuevas recipes, workflows, documentos |
content:edit-own | Member | Editar contenido que usted creó |
content:edit | Dept Lead | Editar contenido en su departamento |
content:edit-any | Admin | Editar cualquier contenido en todos los departamentos |
content:delete-any | Admin | Eliminar cualquier contenido en todos los departamentos |
content:read | Viewer | Leer contenido (recipes, workflows, documentos) |
Ejecución (3 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
execution:run | Member | Ejecutar recipes y workflows |
execution:schedules | Member | Crear y gestionar ejecuciones programadas |
execution:triggers | Member | Configurar disparadores basados en eventos |
Analíticas (2 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
analytics:read-department | Auditor | Leer analíticas de su(s) departamento(s) |
analytics:read-all | Admin | Leer analíticas de todos los departamentos |
Funcionalidades (4 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
features:chat | Member | Usar la interfaz de chat con IA |
features:documents | Member | Gestionar documentos de base de conocimiento |
features:packs | Dept Lead | Instalar y gestionar packs de departamento |
features:connectors | Admin | Configurar conectores e integraciones MCP |
Gobernanza (3 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
governance:audit | Auditor | Leer registros de auditoría e informes de gobernanza |
governance:environments | Dept Lead | Gestionar entornos de despliegue |
governance:promote | Dept Lead | Promover workflows entre entornos |
Seguridad (2 permisos)
| Permiso | Rol Mín. | Descripción |
|---|---|---|
security:byok | Admin | Gestionar claves API Bring Your Own Key |
security:embedded-api | Admin | Configurar la API embebida |
El mapeo de rol a permisos es estático. Un Dept Lead (nivel 30) automáticamente tiene cada permiso con un rol mínimo de 30 o inferior. Sin sobrescrituras de permisos por usuario, sin definiciones de roles personalizados. Esto mantiene el modelo auditable — puede ver el rol de un usuario y saber exactamente qué puede y qué no puede hacer.
Sobrescrituras de rol con alcance de departamento
Un rol global aplica en todas partes. Pero las organizaciones no son planas. Un gerente de producto podría necesitar acceso de Member globalmente pero acceso de Dept Lead en el departamento de Producto para gestionar las automatizaciones de su equipo.
Las sobrescrituras con alcance de departamento resuelven esto. Un usuario tiene un rol global, más cero o más sobrescrituras de rol específicas por departamento.
Ejemplo: Sarah es Member globalmente. Tiene una sobrescritura de Dept Lead en el departamento de Ventas. En Ventas, puede editar cualquier contenido, instalar packs y promover workflows. En Ingeniería, es una Member estándar — solo puede editar su propio contenido.
El principio de diseño crítico: las sobrescrituras solo pueden elevar, nunca reducir. Si usted es un Admin global con una sobrescritura de Viewer en Ingeniería, su rol efectivo en Ingeniería sigue siendo Admin. La sobrescritura se ignora porque reduciría el acceso. Esto evita que una sobrescritura mal configurada bloquee accidentalmente a alguien de un departamento al que debería tener acceso.
Resolución de rol efectivo
Cuando el sistema necesita determinar qué puede hacer un usuario en un departamento específico, ejecuta esta resolución:
- Verificar si existe una sobrescritura de departamento para este usuario en este departamento
- Si existe una sobrescritura, devolver el mayor entre el rol global y la sobrescritura
- Si no existe sobrescritura, devolver el rol global
En pseudocódigo:
effectiveRole(user, department):
override = getDepartmentOverride(user, department)
if override exists:
return max(user.globalRole, override.role)
return user.globalRoleLas verificaciones de permisos con alcance de departamento usan este rol efectivo. Cuando Sarah intenta instalar un pack en Ventas, el sistema resuelve su rol efectivo en Ventas (Dept Lead, nivel 30), verifica el nivel mínimo para features:packs (30), y otorga acceso. Cuando intenta lo mismo en Ingeniería, su rol efectivo es Member (20), que está por debajo del nivel requerido.
Reglas anti-escalamiento
Los cambios de rol son la operación más sensible en seguridad del sistema. Cuatro reglas previenen la escalación de privilegios:
-
No puede cambiar su propio rol. Sin auto-promoción. Un administrador que quiera convertirse en owner necesita que otro owner haga el cambio.
-
No puede asignar el rol de Owner. La transferencia de Owner es una operación separada y deliberada con sus propias salvaguardas. No ocurre a través de la API estándar de cambio de rol.
-
No puede asignar un rol mayor o igual al suyo (a menos que sea Owner). Un Admin (40) puede asignar Dept Lead (30), Member (20), Auditor (15) o Viewer (10). No puede asignar Admin (40) ni Owner (50). Solo el Owner puede crear otros Admins.
-
No puede cambiar el rol de alguien con un rol mayor o igual al suyo (a menos que sea Owner). Un Admin no puede modificar el rol de otro Admin. Un Dept Lead no puede modificar el rol de un Admin. La jerarquía se aplica estrictamente hacia arriba.
Estas reglas se componen limpiamente. Combinadas, garantizan que ningún usuario pueda escalar sus propios privilegios o los privilegios de sus pares — solo el Owner está fuera de esta restricción.
Cómo se aplican los permisos
Cada ruta API en JieGou pasa por una protección de autenticación de tres pasos antes de ejecutar cualquier lógica de negocio:
Paso 1: Verificar la cookie de sesión. El token de sesión de la cookie HTTP se valida contra Firebase Auth. El resultado se almacena en caché en Redis con un TTL de 5 minutos, para que las solicitudes repetidas de la misma sesión no consulten Firebase Auth en cada llamada.
Paso 2: Buscar el registro de AccountUser. La membresía de cuenta del usuario — incluyendo su rol global y sobrescrituras de departamento — se obtiene de Firestore. Esto también se almacena en caché en Redis con un TTL de 5 minutos.
Paso 3: Verificar permiso contra la jerarquía de roles. El permiso requerido se mapea a su nivel de rol mínimo. El rol efectivo del usuario (considerando sobrescrituras de departamento si la verificación tiene alcance de departamento) se compara con él. Esto es O(1) — una sola búsqueda de hash para encontrar el nivel mínimo, más una comparación numérica.
Sin consultas a base de datos en el momento de verificación de permisos. Sin iterar a través de listas de permisos. Dos búsquedas en caché y una comparación de enteros.
Verificaciones a nivel de recurso
Más allá de los permisos basados en roles, los recursos individuales (recipes, workflows, documentos) tienen reglas de acceso basadas en propiedad:
- Owner, Admin, Dept Lead — pueden modificar cualquier recurso en su alcance
- Member — puede modificar solo recursos que creó
- Auditor, Viewer — no pueden modificar ningún recurso
Esto se combina con los permisos a nivel de rol. Un Member con content:edit-own solo puede editar recursos donde resource.createdBy === user.id. Un Dept Lead con content:edit puede editar cualquier recurso en su departamento sin importar quién lo creó.
Integración con funcionalidades de la plataforma
RBAC no está aislado — se conecta con cada subsistema principal de la plataforma:
Puertas de aprobación. La elegibilidad de aprobación respeta la jerarquía de roles. Puede configurar un paso de aprobación para requerir un rol mínimo — por ejemplo, solo Dept Lead o superior puede aprobar outputs de workflow antes de que vayan a producción.
Visibilidad de ejecución. Las ejecuciones de workflow tienen 4 alcances de visibilidad: private (solo quien ejecutó), department (cualquiera en el mismo departamento), group (grupos especificados) y account (todos). RBAC determina quién puede ver los resultados de ejecución y quién no.
Promoción de entorno. Diferentes entornos (desarrollo, staging, producción) pueden requerir diferentes roles mínimos. Desarrollo podría permitir promoción a nivel de Member. Producción podría requerir Admin. RBAC controla cada transición.
Informes de gobernanza. El panel de gobernanza muestra la distribución de roles en la cuenta, conteos de recursos accesibles por usuario y utilización de permisos. Los Auditores pueden revisar estos datos para asegurar que los patrones de acceso coincidan con las políticas.
Disponibilidad
RBAC está disponible en todos los planes. Cada cuenta de JieGou obtiene la jerarquía completa de 6 roles y 26 permisos. Las sobrescrituras con alcance de departamento y el rol de Auditor están disponibles en los planes Team y Enterprise. Explore todas las funcionalidades o inicie una prueba gratuita.