权限模型

SkillFlaw 的权限体系由租户、业务域、资源范围、可见性与动作边界共同构成。 权威语义以平台统一权限规则与授权执行逻辑为准。

安全架构

SkillFlaw 的安全架构围绕“先认证、再鉴权、后访问资源或执行隔离能力”的控制闭环组织。 浏览器、前端、Webhook、系统集成和 MCP Client 统一通过 API 网关进入平台，认证服务负责密码校验、令牌签发、刷新与会话校验，授权服务再基于租户角色、业务域角色、资源归属、可见性与操作类型做资源级判定。

安全架构可以从以下几个层面理解：

• 入口与接入边界：终端用户、浏览器前端、Webhook 和 MCP Client 只能通过受控接口访问平台，避免外部调用方直接接触内部资源与执行环境。
• 认证与密钥控制：登录、刷新令牌、会话检查与退出登录等接口统一进入认证服务，密码校验、密钥/密钥文件、JWT 签名与 Fernet 对称加密在这里集中处理。
• 授权与资源判定：授权服务并不只看页面上下文，而是按模块、操作、租户 ID、业务域 ID、资源范围与所有者等维度进行资源级判权；规则核心是先定位资源，再按资源自身归属做鉴权。
• 数据与敏感配置保护：PostgreSQL 中的系统配置、凭据配置、业务资源以及管理控制平面的敏感字段统一纳入受控访问范围，仅在满足规则的路径上做读取、脱敏或定向解密。
• 高风险执行隔离：技能沙箱服务与沙箱管理器位于独立隔离层，执行时对 CPU、内存、进程 ID、超时时间、文件系统和网络能力设置边界，避免高风险代码在主应用进程中裸跑。

这套安全架构决定了权限模型不能只依赖页面级上下文。 用户必须先通过认证建立身份，再由授权服务结合资源自身归属与范围做判定，最后才能读取资源、访问敏感配置或进入隔离执行环境。

多租户模型

平台首先按租户隔离数据与权限。租户是一级管理边界。 租户用户与角色可以通过以下方式形成授权：

• 用户直接授权
• 用户组授权
• 组织授权

租户角色决定用户在租户层可以看到什么、管理什么。

系统租户

系统租户是特殊租户，具备：

• is_sys = true
• tenant_id = 00000000-0000-0000-0000-000000000000

系统级资源通过“属于系统租户的资源”来表达，而不是依赖独立业务 scope。 系统租户的写操作仍必须按系统租户自身做权限判断。

业务域与个人

SkillFlaw 明确区分业务域数据与个人数据。

业务域

业务域支持层级结构。 项目与工作流必须创建在业务域下，业务域授权会向下影响其所属业务对象。

个人业务域

个人业务域是特殊语义，通常表现为：

• business_id = 0
• 所有者通过 c_uid 标识

这样可以把个人对象与共享业务域对象明确区分开。

角色模型

权限模型主要包含两类角色。

租户角色

租户角色包括：

• TENANT_ADMIN
• TENANT_READONLY
• TENANT_EMPLOYEE
• TENANT_ORG
• TENANT_BIZ
• TENANT_DEV
• TENANT_OPS
• TENANT_QA

这些角色控制租户层的查看、治理和部分个人资源操作能力。

• 租户管理员（TENANT_ADMIN）：租户范围内的最高管理角色。拥有租户治理的完整权限上限；在系统租户上下文内，还承担新租户创建、修改与删除治理能力。
• 租户只读用户（TENANT_READONLY）：租户侧最基础的读权限角色。可查看租户内除用户治理外的各类信息，但不具备创建、修改、删除资源或授权配置的能力。
• 租户员工（TENANT_EMPLOYEE）：在 TENANT_READONLY 基础上增加个人业务域资源写权限。可创建、修改、删除个人范围内由自己拥有的资源，但不自动获得组织治理、一级业务域创建或高阶授权治理能力。
• 租户组织管理员（TENANT_ORG）：继承 TENANT_EMPLOYEE 能力，并额外负责租户组织治理。可维护租户内用户、用户组、组织角色授权关系；租户级用户 / 用户组 / 组织角色授权与删除属于该角色与 TENANT_ADMIN 的治理范围。
• 租户业务域管理员（TENANT_BIZ）：继承 TENANT_EMPLOYEE 能力，并负责一级业务域治理。可创建一级业务域、维护一级业务域及其业务管理员授权；一级业务域的新增、修改、删除由该角色与 TENANT_ADMIN 共同承担治理职责。
• 租户开发者（TENANT_DEV）：岗位型角色，权限与 TENANT_OPS、TENANT_QA 一致。拥有除组织维护与一级业务域创建外的大部分租户权限，适用于组件、流程、技能等研发协作场景。
• 租户运维（TENANT_OPS）：岗位型角色，权限与 TENANT_DEV、TENANT_QA 一致。适用于运行保障、配置维护与状态检查场景，但仍遵守统一资源归属、scope 与 PRIVATE 规则。
• 租户测试（TENANT_QA）：岗位型角色，权限与 TENANT_DEV、TENANT_OPS 一致。适用于测试、验证、连通性检查与结果确认场景；测试、校验、连通性检查类接口统一按 READ 口径执行。

业务域角色

业务域角色包括：

• BUSINESS_ADMIN
• BUSINESS_READONLY
• BUSINESS_EMPLOYEE
• BUSINESS_DEV
• BUSINESS_QA
• BUSINESS_OPS

这些角色控制用户在业务域及其子业务域中的查看和操作能力。

• 业务管理员（BUSINESS_ADMIN）：业务域范围内的最高管理角色。对当前业务域及全部子业务域的资源拥有创建、修改、删除、查看权限，是业务侧治理上限角色。
• 业务只读用户（BUSINESS_READONLY）：业务侧基础可见角色。仅可查看当前业务域及全部子业务域中的资源，不能在该业务域创建资源，也不能修改或删除该业务域的人员资源。
• 业务员工（BUSINESS_EMPLOYEE）：标准业务协作角色，但权限口径与 BUSINESS_READONLY 一致。角色名称用于区分业务身份，不额外放宽业务域写权限。
• 业务开发者（BUSINESS_DEV）：岗位型角色，权限与 BUSINESS_QA、BUSINESS_OPS 一致。拥有除业务域用户授权外的大部分业务域权限，适用于研发、联调与能力建设场景。
• 业务测试（BUSINESS_QA）：岗位型角色，权限与 BUSINESS_DEV、BUSINESS_OPS 一致。适用于测试、验证、检查与结果确认场景；测试、校验、连通性检查类接口统一按 READ 口径执行。
• 业务运维（BUSINESS_OPS）：岗位型角色，权限与 BUSINESS_DEV、BUSINESS_QA 一致。适用于运行保障与配置维护场景，实际写边界仍由资源归属、scope 与 PRIVATE 语义共同约束。

资源范围

对于组件、模型、MCP、OpenAPI 插件、知识库、变量、技能等资源类对象，正式 visible_scope 为：

• 租户：1
• 业务域：2
• 个人：3

对于工作流、项目等部分业务对象，实际 scope 仍主要表现为业务域或个人。

访问类型

access_type 决定谁可以看到对象，但不会自动放宽写权限。 正式口径为：

• PUBLIC：跨租户可见
• PROTECTED：租户内可见
• PRIVATE：可见性受 scope 与授权限制，写权限仍最严格，仅创建者可修改

这意味着“可见”不等于“可改”。

项目 audience 模型

项目（project）并不以 access_type 作为主访问边界，而使用 audience_type，包括：

• ALL
• USER
• TENANT
• BUSINESS
• PROJECT

因此项目的访问控制比通用资源可见性更偏向“受众模型”。

五种 audience_type 的正式访问口径如下：

• ALL：对所有访问者开放，包括匿名用户。适用于无需登录即可查看或调用的公开项目入口。
• USER：仅已登录且在平台内存在账号的系统用户可访问。该类型要求访问者先具备系统用户身份。
• TENANT：仅当前项目所属租户内的授权用户可访问。授权可以来自租户对用户、用户组或组织的角色授予。
• BUSINESS：仅命中目标一级业务域授权范围的用户可访问。授权可来自业务域对用户、用户组或组织的显式授予，并向该业务域子树内业务对象生效。
• PROJECT：仅被该项目显式授权的用户、用户组或组织成员可访问。它是五种类型里边界最精确的项目级受众控制方式。

按资源 ID 打开的只读接口

对资源详情页和按资源 ID 打开的只读子接口，平台规则要求：

1. 先按资源 ID 定位真实资源
2. 再按该资源自己的租户、业务域、scope、access_type 和授权范围判断是否可读
3. 一旦资源可读，则 versions、messages、transactions、access logs、validation、test 等只读接口必须复用相同读取语义

这样可以避免资源已经可见后，又被页面级 scope 二次拦成 403 或 404。

关键设计原则

权限模型遵循以下原则：

• 页面全局上下文不等于资源归属
• 跨租户可见不等于跨租户可写
• 业务域私有资源不是默认“租户内全部可见”
• 必须先算权限，再查数据
• 授权语义应尽量复用共享快照与统一判定，而不是各模块本地推导

相关页面

• 产品架构
• 关于 SkillFlaw
• 产品路线图