权限模型
授权一个 AI，应该像授权一名新员工一样清楚：它能进哪些房间、查哪些台账、按哪些按钮，全部有据可查。AIDC 不把权限当作部署后补的管控，而是架构本身的一部分：权限分为 Infrastructure、Data、Tool 三层，再用五条关键规则约束 Agent 的读写边界，让“授权一个 Agent”成为一件可定义、可执行、可审计的管理动作。
给 AI 的不是一把“万能钥匙”，而是一张写清楚楼层与房间的门禁卡：它在哪栋楼办公（Infrastructure，基础设施隔离）、能查阅哪些台账（Data，数据权限）、能操作哪些设备（Tool，工具边界）。三道门各自把关，任何一道失守，仍有下一道兜底。
三层权限模型
“Agent 能做什么”这个问题，在 AIDC 平台上被拆成三个独立回答的问题：它的运行环境能触达什么（Infrastructure——相当于“在哪栋楼办公”）、它能看到和修改哪些业务对象（Data——能查阅哪些台账）、它能调用哪些工具（Tool——能操作哪些设备）。三层各有明确的执行点与 AWS 对应物：
| 层级 | 控制内容 | 主要执行点 |
|---|---|---|
| Infrastructure | AWS account / VPC / subnet / IAM role / KMS key 隔离 | 云基础设施本身 |
| Data | Ontology 的 object、property、link、action 与文件权限 | Policy & Identity Plane + Context Gateway |
| Tool | Agent 可以调用哪些 API、脚本、模型、部署动作 | Cell 内的 Permission Adapter |
Infrastructure基础设施层物理边界。每个部门 Agent Cell 运行在隔离的 AWS 环境中，部门之间在网络与身份层面互不可达。AWS 对应物：独立 account 或 VPC、subnet、security group、private endpoint 做网络隔离；IAM Identity Center、IAM roles 与 session policies 做身份与会话边界；KMS 与 Secrets Manager 做密钥和机密隔离。这一层的意义在于：即使应用层逻辑出错，部门 Cell 也无法在基础设施层面触达对方的存储与运行时——相当于两个部门本来就在不同的办公楼里。
Data数据层语义边界。控制谁能看到哪个 Object 的哪些 property、哪条 Link、哪些文件、哪些 Action。执行点在 Policy & Identity Plane：Context Gateway——按身份与权限分发资料的中枢——在生成上下文包时逐项过滤不可访问的对象、字段、文件和工具。AWS 对应物：每部门独立 EFS 或独立 S3 prefix 承载文件级权限；对象、字段、关系级的细粒度权限在 Ontology 与策略平面执行——细粒度语义权限不依赖底层存储的粗粒度 ACL，但以它为兜底。
Tool工具层行为边界。控制 Agent 可以调用哪些 API、脚本、模型和部署动作。执行点在 Cell 内部：Permission Adapter——把总部策略翻译成本地工具清单的“驻场管理员”——把中央策略转换成本地的工具清单、API 权限与策略快照（如 permissions/policy.cache.json）。AWS 对应物：runtime 所挂的 IAM role 限定它可调用的 AWS API 范围；工具注册清单与策略快照约束脚本与部署动作。策略更新时由 Adapter 同步，而不是修改 Cell 的代码。
实施顺序上，权限过细会导致系统不可用——这是已识别的关键风险。推荐路径是先按部门和对象级权限落地，逐步扩展到字段级权限，而不是一开始就追求最细粒度；具体节奏见下文“分阶段落地与上线检查清单”。
五条关键规则
三层结构回答“权限在哪里执行”，五条规则回答“权限如何被使用”。它们共同构成平台的授权契约——相当于公司制度里“谁可以审批什么”的总则：
默认隔离Isolation by Default部门文件系统默认隔离。平台上不存在“全公司共享盘”：任何可见性都是显式授予的结果，而不是默认状态。一个新部署的 Cell 在被授权之前，只能看到自己的目录——就像新员工入职当天只拿到自己工位的钥匙。
跨部门必须走 linkCross-Department via Link跨部门读取必须通过 Ontology link 或显式共享对象（如 ShareContext 动作）。不存在“直接读对方目录”这条路径——跨部门可见的永远是按关系路径组装、按策略裁剪的受控视图，而不是原始文件。
写状态必须走 Action TypeWrite via Action TypeAgent 写入企业关键状态必须通过受控 Action Type 提交，不允许绕过审计直接改底层表。读权限决定 Agent 能看到什么，写权限被进一步收窄为“能提交哪些动作”——写入即提交，提交即留痕，像一套不可绕行的审批流。
全量 Action LogFull Audit所有 Action 提交都写入 Action Log，并绑定发起者、Agent 版本、上下文包版本和工具调用摘要。审计因此能回答完整的责任链：哪个部门的哪个 Agent，基于哪个版本的上下文，用了哪些工具，改了什么。
中央只定义边界Central Defines Boundaries Only中央策略只定义能力边界，不直接操控每个部门的所有执行细节。部门 Cell 在边界内自治：自己的文件结构、任务执行、工具集成和局部优化由部门负责。中央不需要理解每个部门的全部细节，只需要定义可执行的语义接口、权限边界和审计协议——像集团总部定章程，分公司管经营。
五条规则不可单独豁免。例如“为了效率”允许某个 Agent 直接写底层表，会同时击穿规则三与规则四——状态变化失去审计绑定，后续所有复盘都建立在不完整的事实之上。
一次权限决策：Marketing Agent 想读 Sales 客户数据
示例场景：Marketing Cell 的 Agent 在准备一份 campaign 简报，需要了解某个客户的背景。客户（Customer）对象归 Sales 所有，存放在 Sales 的部门文件系统中。以下是这次请求在平台中的完整路径：
-
请求发起
Marketing Agent 向 Context Gateway 提交上下文请求：任务意图（撰写 campaign 简报）、身份（Marketing Cell 的 Agent）、目标对象（该 Customer 对象）、预期 Action Type（如
CreateWorkItem）。它没有也无法直接检索 Sales 的文件——Infrastructure 层的隔离让那条路径在网络层面就不存在。 -
Ontology 查询
Gateway 在 Ontology 中定位该 Customer 对象，发现存在关系路径：Marketing 的 Campaign 对象通过 link 指向该 Customer（如“Campaign—投放给—Customer”）。存在合法的关系路径，是跨部门读取被继续处理的前提。
-
策略过滤
Policy & Identity Plane 检查 Marketing Agent 对该对象的 Data 层权限：允许读取与 campaign 相关的摘要字段（如行业、阶段、规模区间），但联系人明细、合同金额、报价历史等字段被裁剪；Sales 目录中的原始文件不会进入上下文包。
-
结果 A：存在 link 且策略允许
裁剪后的受控摘要进入 context package，Marketing Agent 据此完成简报。包的版本号精确记录了它看到的内容范围——既不是全部客户数据，也不是一无所有。
-
结果 B：无 link 或策略不允许
请求被拒绝。Agent 的出路不是绕过，而是发起受控动作：请 Sales 通过
ShareContext显式共享指定视图，或提交RequestApproval走人工审批。共享行为本身也是 Action，同样写入 Action Log。 -
审计闭环
无论结果 A 还是 B，这次访问决策都有记录；Marketing Agent 后续提交的简报相关 Action 绑定上下文包版本。如果客户日后质询“Marketing 看过我们的什么数据”，Action Log 可以给出精确答案——而 Marketing Agent 自始至终没有读过 Sales 的文件系统。
与 C-suite 文件系统的对应关系
三层权限不是平台凭空发明的，它是 Company Harness“目录即权限边界”原则的工程化。AIDC 自己的 C-suite 文件系统——十个根目录对应十个 C-suite Agent——就是这套模型在单组织内的最小实现：
| 平台权限概念 | C-suite 文件系统对应物 |
|---|---|
| 部门 Cell 默认隔离 | 一个根目录对应一个 C-suite Agent，一个 Agent 只拥有一个根目录（如 09_marketing/ 归 CMO Agent，10_sales/ 归 CSO Agent） |
| Data 层的对象与文件权限 | 目录即权限边界，每个目录的 AGENT.md 声明唯一所有者、职责范围与可读写边界 |
| 跨部门必须走 link | 跨职能协作通过引用、请求和决策记录完成，而不是共享所有权或直接写对方目录 |
| 写状态必须走 Action Type | 重要变更以决策记录和提交进入文件系统，留下可追溯的变更历史 |
| 全量 Action Log | 文件系统的版本历史与决策记录构成可复盘的审计链 |
| 中央只定义边界 | 治理规则只约束根目录的增长方式与协作方式，不规定每个目录内部如何工作 |
这个对应关系也是 AIDC 部署路径的依据：客户先用 Harness 的目录权限建立组织边界，再随规模演进到平台的三层权限——概念不变，执行点从“目录约定”升级为“基础设施 + 策略平面 + 权限适配器”。
权限的演化边界
平台支持受治理的自演化：Agent prompt、检索规则、文件结构、SOP 都可以经演化闭环持续改进。但有四类权限对象被明确排除在自动演化之外：
- 高权限 IAM 策略 — Infrastructure 层的身份边界，变更影响整个隔离模型；
- KMS 和 secrets 管理 — 密钥与机密是所有层的信任根；
- 跨部门敏感数据共享规则 — Data 层最敏感的部分，错误的放宽不可逆地暴露数据；
- 生产环境破坏性动作 — Tool 层的高危动作，如删除资源、变更生产配置。
这四类对象的任何变更必须保留人工批准或强策略审批，并且必须有 proposal、approval、rollback 的完整流程。允许 Agent 自动放宽自己的权限边界，等于取消权限模型本身。
分阶段落地与上线检查清单
权限模型的落地目标不是“一步到位的最细粒度”，而是“每个阶段都可用、可审计”。一开始就追求字段级权限，往往让系统不可用、让业务部门绕开制度——这正是权限模型要避免的局面。推荐按三个阶段推进：
-
阶段一：部门级隔离
用目录与
AGENT.md确立“一个目录一个所有者”，建立默认隔离。这一阶段在 Harness 上即可完成，不依赖任何平台组件，就能终结“所有人看到所有内容”的状态。 -
阶段二：对象级权限
Ontology 上线后，把读权限收敛到 object 与 link，把写权限收敛到 Action Type；跨部门访问全部改走关系路径。绝大多数业务场景到这一层已经够用。
-
阶段三：字段级裁剪
只对高敏对象（客户合同、报价、薪酬等）开启 property 级裁剪，由 Context Gateway 在生成上下文包时执行。范围越收敛，规则越可维护。
每个阶段上线前，用下面的清单做一次自查：
- 每个部门 Cell 是否只对应一个所有者目录，
AGENT.md是否声明了可读写边界； - 跨部门读取是否全部走 link 或
ShareContext，有没有“直接读对方目录”的暗道； - 是否存在绕过 Action Type 直写底层表的路径（包括运维脚本与临时工具）；
- Action Log 是否完整绑定发起者、Agent 版本、上下文包版本与工具调用摘要；
- 四类排除对象（高权限 IAM、KMS 与 secrets、跨部门敏感共享规则、生产破坏性动作）的变更是否保留 proposal、approval、rollback 的完整流程。
相关阅读
- Agent Cell — Permission Adapter 如何把策略落到 Cell 内部
- Context Gateway — Data 层权限的主要执行点
- AWS 部署映射 — Infrastructure 层的账号、网络与身份落地
- Action Log — 五条规则共同指向的审计链
- C-suite 文件系统 — 目录权限的组织级实现