权限模型

在实践中

权限模型与一条权限之间的区别，就像国际象棋的规则与一步棋之间的区别。决定一套模型能否扛过安全审查的，是模型本身的三个性质，而不是任何一条规则。容器是什么——角色、用户组、Profile、权限集——其中是否有不止一种在干同一件事？一个人同时持有多份授权时，它们如何叠加：只做加法、任一份命中即放行，还是存在会压过其它规则的拒绝项，于是求值顺序和优先级决定结果？以及什么都不匹配时的默认值是拒绝还是放行？产品会在多年里累积出彼此重叠的容器，结果「这个人为什么能看到这条记录」这个问题，不模拟一遍引擎就答不出来——而这恰恰是审计员开口问的第一个问题。

ObjectStack 刻意把这个面收窄。能力容器只有一种——权限集——它按并集合并，且纯粹是加法：里面没有任何一位是拒绝。岗位是一个扁平的分发组，负责把权限集绑到人身上；业务单元是可见性层级；完全不存在 Profile 这个概念。默认拒绝在字面意义上成立：每一个 allow 位默认为 false，所以在某条定义开口之前，一个对象是读不到的。在这一套模型之上叠着四层强制：对象级 CRUD、字段级读与写、行级谓词（见「行级安全」），以及针对协作例外的按记录共享——否则这类例外只能靠放宽整个角色来解决。导出是一条独立的轴，而不是「读」的顺带结果，因为「在屏幕上看一条记录」和「把整张表拉成 CSV 拖走」是两种不同的特权——Salesforce、Dynamics、NetSuite 和 SAP 都做了这个切分，而粗粒度的模型会悄悄把它丢掉。

「只做加法、没有拒绝」是一条实打实的约束，选它是为了可审阅性，不是为了表达力。因为授权只会做加法，「这个人为什么能看到这个」的答案就是列出授予它的那几个权限集——一份有限、可读的清单；而在一个允许拒绝的模型里，同一个问题需要在可能相隔数年、由不同人写下的规则之间推理优先级。同一个性质也让 AI Agent 无需为它另发明一套东西就能被治理：Agent 以登录用户的身份行动，按那个用户的权限集解析，于是不存在一个需要单独推理其权限的特权服务身份——审阅「Agent 能做什么」与审阅「这个人能做什么」，是同一件事。