真正的分层不是谁服从谁而是谁都不能单独把自己的判断变成真实执行。摘要在一个同时拥有 SaaS、Hub 和本地执行边界的系统里最容易出现的误解是这三层之间究竟谁的权力最大有人认为 SaaS 掌握组织、审批和业务上下文应该由它统一决策有人认为 Hub 更接近执行、又保存本地治理状态应该由它拥有最终裁决权也有人认为只有本地设备真正控制密钥、接口和物理动作本地边界才是最高权威。但寻找最高权威这个思路本身就违背了分层不信任的目的。分层的意义不是选出一个更值得信任的中心而是让任何一层的失陷都不足以独自酿成灾难。SaaS、Hub 和本地边界并不是三个争夺最终解释权的裁判它们分别面对不同的事实SaaS 面对组织、业务与协同状态Hub 面对本地治理状态与多源策略收敛本地执行边界面对最终参数、执行条件与真实动作。任何一层都不完整——SaaS 看得更广却无法单独证明最终参数Hub 更近设备却无法独立理解全部业务本地边界最贴近现实却不能凭有限规则解释整个组织意图。第七、八篇把收敛确立为原则与冲突主轴。这一篇把它落到架构上三层之间不是命令链而是三条彼此不可绕过的边界。核心只有一句话——限制可以向下传递放行必须逐层重新验证任何一层都能收缩执行能力任何一层都不能独自扩张它。一、三层架构最危险的误解是把它理解成命令链在传统系统中云端、网关和设备通常构成一条清晰的控制链云端下发指令 → 网关转发 → 设备执行。这非常适合普通自动化——云端管业务逻辑网关管协议转换与连接设备把指令变成动作。但一旦动作涉及资金转移、权限提升、数据导出、证书轮换、生产变更、AI Agent 调用高风险工具、真实设备控制这条命令链就暴露出致命问题只要云端判断中心被控制下面所有层都会把错误命令继续传递下去。Hub 如果只是转发器、本地设备如果只是执行器那么多层架构并没有形成多层安全——它只是让一条命令经过了更多机器。真正的执行控制要求每一层都不是单纯中继每一层都必须能独立验证自己负责的条件并在必要时拒绝继续。两种结构的差别可以直接画出来命令链危险 边界模型安全 SaaS ──指令──▶ Hub SaaS ──治理条件──▶ Hub Hub ──指令──▶ 本地 Hub ──收敛后的Intent──▶ 本地 本地 机械执行 本地 独立验证并保留拒绝权 ​ 上游失陷 全链失陷 每层独立验证限制↓可传递放行需逐层重验左边任意上游被攻破错误一路直达现实右边每一层都是一道要重新过的闸且这些闸只会让范围更小、不会更大。二、三层各自的职责治理、收敛、执行SaaS 的职责是治理与协同不是远程统治执行。它最擅长掌握组织和业务世界成员身份与角色、业务申请、审批完成与撤销、组织是否冻结、风险信号、Policy 发布、Agent 任务权限。没有 SaaS复杂组织无法完成跨成员、跨设备、跨地区的持续治理。所以 SaaS 应能发起治理意图、发布组织级 Policy、组织审批、撤销权限、冻结高风险动作、下发风险收缩信号、协调多个 Hub、归档证据。但它不应单独提高本地硬额度、强制本地忽略设备异常、绕过 Hub 收敛、直接指定密钥、在参数变化后复用旧审批、伪造设备执行、远程取消不可突破的本地限制。SaaS 可以说从组织和业务角度这个请求具备继续条件但不能宣布所有本地边界必须立即服从。Hub 的职责是保存本地治理状态并完成策略收敛不是当通信网关。如果 Hub 只接收云端请求再转发给执行模块它就无法形成独立边界。它真正该承担的是本地治理角色验证 SaaS 消息来源、维护本地可验证治理状态、保存组织/成员/Policy 版本、管理本地额度频次与目标集合、检查状态新鲜度、绑定 Execution Intent、比较多源约束、发现冲突、计算最终可执行范围、在状态缺失时进入收缩模式、把最终请求提交给独立执行边界。Hub 的核心作用不是决定一切而是防止不同来源的判断未经收敛就直接抵达执行层。本地执行边界的职责是控制真实动作而不是重建完整业务世界。它可能控制密钥、签名、设备接口、Executor、物理输出、不可逆动作因而必须拥有最终拒绝权需要验证最终 Payload、Intent Hash、目标、金额、权限范围、执行槽位、有效期、计数器、执行次数、设备是否处于 Safe Mode。但它不应试图复制 CRM、ERP、组织架构、审批平台、风险模型、Agent 的全部上下文——承担全部业务判断会让它变得过于复杂而复杂度越高越难审计、验证和隔离。本地边界回答的是最终动作是否与收敛后的 Intent 一致、有没有突破硬约束不是这笔业务在整个组织中是否全部合理。三、SaaS 与 Hub可以收紧不能扩张可以否决不能伪造SaaS 与 Hub 之间的边界是双向的。SaaS 可以向 Hub 通知收缩型治理某成员已撤销、某审批已失效、某组织已冻结、某目标已移出允许范围、某 Policy 已收紧、某风险事件要求暂停。这些信号经验证后应尽快应用。但 SaaS不应单方面要求 Hub 提高额度、新增高风险目标、降低审批要求、延长有效期、跳过本地确认、强制退出 Safe Mode、忽略计数器、覆盖尚未验证的本地状态。SaaS 可以快速收紧本地能力但扩大本地执行能力必须经过额外验证与收敛——收缩可传播扩权要收敛。反过来Hub 也不能成为 SaaS 的机械延伸。即使 SaaS 返回ALLOWHub 仍要检查本地 Policy 是否允许、状态是否够新鲜、审批是否绑定当前 Intent、金额是否超本地上限、目标是否已被本地接受、执行次数是否可用、设备是否正常、是否存在版本冲突。SaaS 的ALLOW只是 Hub 开始收敛的输入不是 Hub 必须服从的命令。但 Hub 的独立不等于它可以编造上游事实。它不能因为本地还存着旧状态就声称成员仍有效、审批仍存在、组织没冻结、云端风险可以忽略、旧 Policy 可以永久使用。Hub 可以在离线时使用明确预授权的有限能力却不能把暂时拿不到新状态解释成所有旧状态继续有效。独立意味着可以拒绝上游不意味着可以替上游编造事实。四、Hub 与本地提交意图而不是下达命令Hub 完成收敛后提交给本地边界的不应是请执行操作 X而应更接近这是一个已完成多源收敛的执行意图请独立验证最终参数与本地约束并决定是否许可。Hub 可以交付 Intent Hash、最终参数、Policy Hash、审批证明、治理状态版本、金额与目标限制、有效期、执行次数、需要使用的执行槽位。但本地边界仍必须自己检查请求是否完整、签名是否有效、Intent 是否一致、设备状态是否正常、计数器是否连续、额度是否仍在、请求是否重复、最终参数是否突破硬限制。Hub 不能因为自己收敛完成就取消本地边界的独立拒绝权。而本地边界这一侧同样有约束它是最后的拒绝者——发现参数变化、请求过期、摘要不一致、槽位错误、计数器异常、设备异常、请求重复、硬限制被突破时即使 Hub、SaaS 和审批人全部允许也必须拒绝。但它也不能因为技术上能执行就脱离治理任意执行仅凭本地密钥存在、金额低于硬上限、目标曾在白名单、格式合法并不等于执行合理它仍需验证当前 Intent、必要治理证明、审批绑定、策略版本、权限状态、有效期。本地边界拥有的是最终拒绝权不是凭有限状态独自创造执行授权的权力。五、核心原则限制可传递放行不可传递这是整个结构最重要的一条。SaaS 返回ALLOW不能直接传递成Hub 必须允许更不能传递成本地必须执行——每一层都要重新验证自己负责的条件。但 SaaS 返回DENY或成员已撤销、组织已冻结、目标已禁用经真实性验证后这种限制应当向下传递。同样Hub 的本地额度限制应传递到执行边界本地边界的 Safe Mode 不应被上游覆盖审批对目标和金额的限制不应被下游放宽。允许只提供继续验证的资格限制才具备持续收缩范围的效力。这就是限制可传递、放行不可传递。它的直接推论是拒绝权与放行权的分离SaaS 可以说不组织冻结、审批撤销、成员失效、业务异常Hub 可以说不状态无法收敛、额度不足、版本冲突、Intent 绑定失败、状态过期本地边界可以说不参数不一致、硬限制触发、设备异常、请求重复、计数器错误、槽位不匹配。但没有任何一层可以单独说其他边界必须忽略自己的判断立即执行。拒绝权分散放行权收敛——三层都能踩刹车没有一层能单独踩油门。六、两种收缩机制必须互相独立SaaS 和本地边界都需要能独立收缩系统能力。SaaS 可以进入组织冻结发现账户被接管、组织遭遇重大风险、审批系统异常、SaaS 数据完整性受疑要求相关 Hub 停止高风险执行。本地可以进入Safe Mode状态同步异常、计数器断裂、设备完整性异常、Policy 版本冲突、证据链异常。关键在于本地 Safe Mode 不应依赖 SaaS 批准SaaS 冻结也不应被本地旧缓存忽略。两种刹车必须各自独立——任何一方拉下有效刹车高风险执行都应停止或收缩。如果本地 Safe Mode 需要云端点头才生效那么攻击者只要切断或接管云端就能让刹车失灵。独立才是刹车之所以是刹车的前提。七、故障不能成为绕过架构的理由三层的故障处理最容易在保可用的名义下打开后门。要害是同一句话任何一层失效执行权都不能因此回流到更容易被控制的层。SaaS 离线时Hub 有限自治但不能变成无限自治。可以继续的应是已预授权、低风险、目标固定、额度有限、时间有限、次数有限、本地可验证、不涉及扩权的动作不应继续的是新增成员/目标、提高额度、降低审批、开放新工具、解除冻结、使用无法确认的新审批、高风险不可逆动作。离线自治不是 Hub 暂时升格为最高权威而是用之前已收敛好的有限权力继续运行。Hub 异常时SaaS 不能直接跨过它控制本地执行。一旦 SaaS 能绕过 Hub本地治理状态就失去意义、收敛被跳过、额度无法正确计算、意图绑定链中断、云端重新获得直接执行权。更合理的结果是保留最小能力、暂停新高风险请求、等待 Hub 恢复、进入受限本地模式、走明确的物理恢复流程。本地执行边界异常时Hub 不能用软件替代它的决定。直接用软件密钥、调用备用接口、切云端签名、跑应急脚本、绕过硬件确认都等于取消了不可绕过边界——而一旦允许这种回退攻击者就会主动让本地边界看起来不可用去触发更宽松的软件路径。边界失效时绝不能让不存在边界成为新的运行模式否则制造故障就会变成攻击者最省力的攻击手法。八、三层必须围绕同一个 Intent 工作如果三层处理的不是同一个执行意图再多限制也无法真正收敛。SaaS 看到向供应商 A 支付 30,000Hub 收到向目标账户 X 付款本地边界最终面对对 Payload H 用密钥槽位 3 签名——这三种表达必须被明确绑定供应商 A 对应账户 X金额仍是 30,000Payload H 装的就是 X 和 30,000审批人批的也是同一组关键参数Policy 约束没有在转换中丢失。没有 Intent 绑定三层只是在各自验证不同的对象即使全部通过也证明不了真实执行与原始治理意图一致。为此可以进一步区分两类意图。Governance Intent由 SaaS 与人的治理过程产生表达为什么执行、谁提出、谁批准、业务对象、允许的金额与范围、适用 Policy、有效期。Execution Intent由 Hub 在验证收敛后形成表达最终动作类型、最终目标、最终金额、最终参数、执行次数、有效时间、执行槽位、本地限制、必要证明。Hub 的关键作用是把 Governance Intent 正确地收敛成一个具体、有限的 Execution Intent本地边界只接受与 Execution Intent 严格一致的最终动作。这样SaaS 不直接控制底层执行本地边界也不必理解全部业务世界。九、Policy 更新与执行证据也必须三层分权不仅执行请求需要三层互限Policy 更新本身也需要。当 SaaS 想提高本地额度、新增目标、增加 Agent 权限、延长有效期、降低审批要求时Hub 不能收到就无条件采用而要验证来源、版本、是否属于扩权、是否需要额外治理确认、是否与本地硬边界冲突、当前设备是否支持。同样本地管理员改本地 Policy 也不能自动改变组织状态——本地增加一个目标不代表组织已批准该目标。原则仍是那条收紧可较快传播扩权必须完成多源收敛本地硬限制不能被远程取消本地修改不能伪造组织授权。执行证据同样不能被任何一层独占。如果 SaaS 既发起请求、又判断允许、又记录审批、还声称执行成功那么它同时控制了意图、判断、命令和结果叙事——一旦被接管攻击者既能推动动作也能修改事后记录。可靠的证据关系应该是三层分记SaaS 记录治理事实谁发起、谁审批、哪个 Policy 生效、组织状态Hub 记录收敛事实收到哪些来源、用了哪些版本、如何形成 Execution Intent、为何拒绝或继续本地边界记录执行事实最终参数、是否执行、用哪个槽位、计数器变化、结果、设备签名。三层各为自己的事实负责任何一层都不能替另一层伪造证据——记录者不能同时是唯一的作案者。十、Hub 不应变成新的超级裁判由于 Hub 连接各方它极易积累过多权力。如果 Hub 同时能修改本地 Policy、伪造审批状态、选择最终参数、控制执行密钥、生成执行证明、忽略 SaaS 冻结那么它就成了一个新的超级裁判——这恰恰违背分层不信任。Hub 应该拥有策略收敛能力但不应独占组织事实、人的审批事实、最终密钥、物理执行权、执行证明。Hub 可以决定当前信息是否足以形成执行请求但不能独自让现实发生也不能独自证明现实已经发生。十一、相互限制不是相互否定三层互限常让人担心效率下降如果每层都能拒绝流程会不会频繁停摆关键在于——限制不是让三层彼此对抗而是让每一层只对自己真正掌握的事实负责。SaaS 不必重复判断本地计数器本地边界不必重新分析完整订单Hub 也不必取代人工审批。职责越清晰系统越稳定真正制造复杂度的从来不是多层限制而是边界模糊后每一层都想去解释和覆盖别人的结果。这样设计的最终结果是没有任何单点能够独自扩权。SaaS 被接管攻击者仍不能突破本地额度、替换最终参数、绕过 Safe Mode、直接调用密钥、伪造设备证明Hub 被接管仍不能伪造有效审批、绕过硬限制、使用任意槽位、制造可信设备证据、取消有效云端冻结本地模块出问题系统仍不能自动回退软件执行、忽略组织撤销、使用过期 Intent、把技术可执行解释成治理允许。分层不信任的实际意义不是假设每一层都安全而是假设任何一层都可能失效并确保它失效后仍无法独自扩大执行能力。于是三层各自拥有局部权威、却没有谁拥有全局神谕SaaS 的成员撤销不能被 Hub 随意否定Hub 的本地额度不能被 SaaS 直接提高本地设备异常不能被上游投票覆盖审批绑定的目标不能被执行层重新解释——但没有谁能凭一个ALLOW覆盖全部其他边界。这是一种比最高权威更稳定的权力结构。十二、一个具体推演SaaS 被完全接管之后把上面的原则放进最坏场景。假设攻击者完全接管了 SaaS——拿到管理员账户、能改 Policy、能伪造审批、能创建高权限成员、能发起执行请求。在命令链结构里这等于游戏结束错误命令会一路传到设备执行。但在边界模型里攻击者会依次撞上三堵墙。他想把某笔付款额度从 5 万提到 100 万——这是扩权型更新Hub 不会无条件采用要求多源收敛撞墙一次。他绕过收敛、伪造一个已审批状态直接下发——Hub 检查审批是否绑定当前 Intent、状态是否新鲜发现绑定对不上撞墙两次。他退而求其次让请求金额压在旧额度内、复用一份真实旧审批——本地边界比对最终 Payload 与 Intent Hash发现目标或参数已变且计数器/有效期不符撞墙三次。他试图让 Hub看起来不可用、逼系统走云端直连的软件回退——但架构规定故障不回流软件层系统进入受限模式而不是打开后门撞墙四次。SaaS 被完全接管在命令链里是终局在边界模型里只是第一堵墙。攻击者拿到的不是执行权而是一张还要过三关的入场券。这不保证系统永不出错但它把云端失陷从全盘失控降级成了能力受限的局部失陷——这正是分层不信任要买的东西。十三、结语三层不是上下级而是彼此不可绕过的边界SaaS 不是远程总控Hub 不是被动网关本地设备也不是脱离治理的孤立裁判。它们分别承担组织治理、本地收敛、最终执行而三者之间最重要的关系不是服从而是限制。SaaS 可以提出治理条件但不能强制本地执行Hub 可以收敛多源 Policy但不能取代人的授权也不能控制最终密钥本地边界可以拒绝最终动作但不能凭有限状态独自创造组织授权。限制向下传递允许逐层重验任何一层都能收缩执行任何一层都不能独自扩张执行。这才是 SaaS、Hub 和本地边界应有的关系不是谁拥有最终答案而是谁都不能单独让错误越过最后边界。Policy 不是神谕。三层的价值不在于选出一个最高裁判而在于让任何单一层都无法独自决定真实执行。下一篇预告《Policy 不是神谕十》将回到最核心的那条工程原则把前几篇的机制收束成一句可执行的规则——为什么高风险执行必须取更严格者以及它为什么不是保守而是对不可逆后果唯一诚实的态度。本文是「Policy 不是神谕」系列第九篇。第七篇给出收敛总则、第八篇处理冲突本篇把收敛落到 SaaS/Hub/本地的架构分层与相互肘制上第十篇将完成取更严格者这一中轴论证。