更接近执行不代表看见全部事实更难被远程控制也不代表永远不会判断错误。摘要当人们意识到 SaaS Policy 不能单独放行执行后很容易走向另一个极端既然云端不够可信那就把最终决定全部交给本地。这种判断听起来很合理。本地 Policy 更接近真实执行环境它可以掌握设备状态、本地额度、密钥槽位、计数器、连接状态和物理边界。它不必完全依赖云端也更难被一次远程账户接管直接绕过。因此本地 Policy 确实应该拥有比普通业务系统更强的拒绝能力。但这并不意味着本地 Policy 应该成为唯一裁判。本地系统同样有自己的局限。它可能不知道一名成员刚刚离职不知道某项审批已经被撤销不知道业务订单已经失效不知道一个收款目标刚刚被组织列入风险名单也不知道自己收到的执行请求是否来自被污染的上游上下文。它离执行更近却离完整业务事实更远。如果系统把最终权力从 SaaS 完整地转移给本地 Policy只是把一个单点权力换成了另一个单点权力。上一篇拆解了 SaaS这一篇拆解本地——两篇合起来指向同一个结论真正安全的结构不是寻找一个绝对正确的裁判而是让本地 Policy、云端治理、人的授权和独立执行约束互相限制并在高风险动作发生前向更严格的结果收敛。一、为什么本地 Policy 容易被认为更可信与 SaaS 相比本地 Policy 有几个非常明显的优势。它更接近真实执行可以直接观察当前设备是否正常、执行模块是否在线、当前使用的密钥槽位、本地额度是否已经消耗、请求是否重复、计数器是否连续、策略版本是否完成同步、是否存在本地异常、当前是否进入 Safe Mode、最终参数是否符合设备约束。这些信息往往是云端无法完全掌握的。SaaS 可能知道组织希望做什么本地 Policy 更有机会知道最终究竟要执行什么。同时本地系统不必完全暴露在公网和云端账户体系中。一个 SaaS 管理员账户被盗并不必然意味着攻击者能够直接修改本地限制一次云端数据库污染也不必然能够绕过设备内部的固定额度、目标限制或执行规则。这正是本地 Policy 的价值——它提供了一条不完全依赖云端判断的安全边界。但价值越大越容易被赋予过多权力。系统很容易从本地必须有独立判断能力滑向本地判断就是最终真理。而这两者并不相同。这篇要论证的恰恰是这一步滑动的危险。二、本地看到的是执行状态不是完整业务状态本地 Policy 最擅长判断的是与执行直接相关的条件金额是否超过本地上限、目标是否位于本地允许列表、请求是否在有效期内、当前设备是否处于正常状态、是否满足频率限制、参数摘要是否一致、本地计数器是否允许继续。但一个动作是否应该执行往往还依赖本地看不到的业务事实。例如一笔付款在本地可能完全符合规则金额低于上限、收款地址在白名单中、签名请求格式正确、审批签名数量满足要求、设备状态正常。但云端可能已经知道供应商合同刚刚被终止、付款订单已经撤销、审批人账户出现异常、收款方正在接受内部调查、该业务请求已经被标记为重复、组织进入紧急冻结状态。如果本地 Policy 只看自己掌握的状态它可能仍然判断ALLOW从本地规则角度这个结论没有错误。但从完整业务状态看这个动作已经不应该发生。这说明本地 Policy 可以证明动作满足本地约束却不能单独证明动作仍然符合完整治理意图。本地离执行更近但更近不代表更完整。这与第三篇里 SaaS 的处境恰好互补——SaaS 看得全却离执行远本地离执行近却看得窄两者的信息盲区正好错开。三、离执行最近也可能离意图最远在复杂系统里真正的执行参数经过多层转换后才到达本地边界。用户最初表达的可能是向供应商甲支付本月服务费用。经过业务系统之后它变成订单编号、币种、金额、收款账户、付款备注、执行时间。再经过自动化系统或 AI Agent它可能被进一步转换成 API 调用、交易结构、权限操作、脚本参数、设备指令、签名 Payload。本地 Policy 最终看到的可能只是一个结构化动作目标Account X 金额98,000 操作Transfer它可以验证这个动作是否符合本地限制但它未必知道 Account X 是否真的属于供应商甲、这笔金额是否对应本月服务费用、订单是否真实存在、用户是否理解最终执行内容、中间系统是否错误地转换了原始意图、AI Agent 是否被恶意内容诱导改变了目标。因此本地 Policy 可能非常准确地验证了一个错误动作。它可以确认这个 Payload 没有违反本地规则却无法确认这个 Payload 就是用户真正想要发生的事情。这正是第一篇提到的执行缝隙在本地侧的落点执行安全不能只验证动作是否合法还必须验证动作是否仍然绑定原始意图intent binding。一个没有意图绑定的本地边界越精确越可能高效地放行一个被篡改过的动作。四、本地 Policy 也依赖输入而输入可能已经被污染本地并不是一个脱离上游独立存在的世界。它仍然需要接收执行请求、身份证明、审批结果、策略更新、白名单、额度配置、目标信息、风险状态、时间信息、组织治理状态。这些输入可能来自 SaaS、Hub、业务系统、移动端、管理员或其他服务。因此本地 Policy 是否正确依然取决于输入是否真实、完整、新鲜、绑定当前意图、来自可信来源、未在传输中被替换、彼此之间相互一致。例如本地收到一份看似有效的审批证明。它可能成功验证签名也可能确认审批数量满足要求。但如果审批人当时看到的内容与本地最终收到的参数不同那么这份审批证明依旧不能代表真实授权——签名是真的签名覆盖的对象却不是执行的对象。在这种情况下本地没有被攻破本地 Policy 也没有计算错误错误发生在输入进入本地之前。这提醒我们一个容易被忽略的事实把 Policy 放到本地只能缩小攻击面不能自动消除输入污染。物理隔离能挡住远程篡改却挡不住一份被污染的数据合法地走进来。五、本地状态也会过期人们经常把本地状态理解成真实状态但本地状态也可能只是最近一次同步的结果。成员权限来自上一次云端同步、白名单来自昨天的配置、风险状态来自十分钟前的缓存、审批撤销尚未送达、新策略还没有完成下发、设备时钟出现偏差、组织冻结状态还未更新、本地数据库仍保存旧的治理 Epoch。这时本地 Policy 的判断可能完全符合自己看到的状态但它看到的是旧世界。设想某位成员上午 10:00 被移出组织。由于网络异常本地节点直到 10:10 仍未收到更新。10:05这名成员发起一项高风险操作。本地检查发现身份凭证有效、本地成员列表中仍然存在、权限符合要求、请求没有超过额度。于是本地 Policy 放行。它并不是被攻击者绕过它只是依据过期状态做出了过期判断。这正是第二篇讲过的TOCTOU 与状态陈旧只不过这次发生在本地。对高风险执行来说过期状态和错误状态可能具有相同后果。因此本地 Policy 必须知道状态来自什么时候、当前使用的是哪个版本、同步是否完整、是否超过允许的新鲜度、是否存在未解决的状态冲突。如果不能证明本地状态仍然有效就不能仅因为它来自本地而继续信任。本地不是新鲜的同义词。六、本地管理员也可能成为单点权力本地 Policy 经常被认为比 SaaS 更难攻击。但本地系统仍然需要管理——有人需要更新策略、调整额度、增加白名单、更换设备、恢复系统、轮换密钥、处理异常、解除 Safe Mode、修改成员权限、进行维护操作。如果一个本地管理员可以独自完成这些动作那么本地 Policy 仍然可能成为单点权力。一个高权限管理员可能临时提高额度、加入新的目标、关闭某项检查、重置计数器、绕过审批条件、强制退出 Safe Mode、替换本地策略文件、将异常请求标记为可信。这些操作可能完全合法。但合法管理权限不等于正确决策。本地管理员也可能被盗号、被诱导、操作失误、面临业务压力、故意滥用权限或在不了解完整上下文时作出错误判断。如果本地管理员既能修改 Policy又能立即触发执行那么本地系统仍然没有实现权力分离——它只是把第三篇里Owner ≠ God的问题从云端搬到了设备旁边。信任根换了个位置但它仍然是单一信任根。七、本地 Policy 越静态越可能无法理解新风险本地 Policy 通常比 SaaS 更稳定。它不适合频繁变化也不应该依赖大量复杂服务。这种稳定性有利于建立明确边界——但稳定也意味着它往往更加静态。本地规则通常擅长判断固定额度、固定目标、固定时间窗口、固定频率、固定成员集合、固定执行类型、固定设备状态。但新的风险往往并不符合旧模式一个原本可信的目标突然出现异常、多个低金额请求组合成高风险行为、AI Agent 通过正常工具完成异常目标、某个账户没有被盗但操作者被深度诱导、一个新型攻击没有触发已有阈值、多个合法请求形成从未预料的组合。本地 Policy 可能没有足够上下文识别这些变化它会继续按照静态规则工作。这并不是缺陷——本地系统本来就不应该被设计成无所不知。问题在于如果系统假设本地 Policy 可以理解所有风险它就会把本地规则的视野边界误认为安全边界。本地 Policy 应该提供不可突破的底线但它不应该假装自己能够替代完整的业务、风险和治理判断。静态是它的优点也划定了它的能力上限。八、硬件约束也不等于业务判断当本地 Policy 被固化在独立设备、可信执行环境TEE或安全芯片附近时人们更容易赋予它绝对权威因为硬件边界更难被软件修改。设备可以强制限制单笔最高金额、每日执行次数、可用密钥槽位、可执行目标集合、必须具备的签名数量、请求有效时间、计数器连续性、特定执行类型。这些限制非常重要。它们保证即使上游软件已经被攻破攻击者仍然无法无限扩大损失——这是典型的不可篡改约束immutable constraint是最后一道兜底。但硬件能够证明的只是这次执行没有突破固化的本地边界。它不能自动证明业务目的真实、用户没有被误导、审批内容准确、目标仍然可信、订单仍然有效、当前操作符合组织最新决策。换句话说硬件可以非常可靠地执行一条错误的规则也可以非常可靠地限制一个已经失效的目标集合。可靠性保证的是规则被忠实执行而不是规则本身正确。所以硬件约束必须被理解成最后的风险边界而不是对业务世界的最终解释。九、本地 Policy 可以独立拒绝但不应独立扩大权限与 SaaS Policy 类似本地 Policy 的权力也应该具有不对称性。当本地发现设备状态异常、参数不一致、请求过期、额度不足、计数器异常、策略版本冲突、审批绑定失效、无法确认关键状态时它应该能够独立拒绝。本地不需要等待云端批准自己拒绝因为拒绝是在收缩执行能力。但如果本地希望提高额度、增加目标、延长有效期、降低审批要求、解除冻结、扩大权限、跳过某项约束它就不应该仅凭本地单方决定立即生效因为这些动作都在扩大可执行空间。这里的原则和第三篇对 SaaS 的要求完全一致方向相反地落在本地任何单一来源都可以提出更严格限制但扩大高风险执行能力必须经过多源确认。这使本地 Policy 保留强拒绝权却不会演变成新的绝对权力中心。收缩是安全的扩张才需要制衡——这条不对称原则对每一个策略来源都成立。十、本地优先不等于本地唯一强调本地执行边界时经常会出现一个口号本地优先。这个方向本身没有问题。对真实执行来说本地必须拥有最终的物理拒绝能力云端不能绕过本地业务系统不能命令本地无条件执行AI Agent 也不能凭借工具权限直接跨越本地边界。但本地优先应该被理解为本地边界拥有不可被远程取消的约束权而不是本地不需要考虑任何外部治理状态。本地可以拒绝云端已经允许的请求但本地不应该因为自己的规则允许就忽略云端已经撤销的审批、组织已经冻结的成员或业务已经终止的订单。真正合理的关系不是云端说了算也不是本地说了算而是任何一方都不能单独推动高风险执行 任何一方发现关键风险都可以阻止执行。这是一种刻意设计的双向否决结构放行需要合力拒绝只需一方。十一、只相信本地会把治理系统压缩成设备配置组织治理比本地规则复杂得多。一个真实组织需要处理成员加入与退出、角色变化、多人审批、业务关联、风险事件、跨部门授权、临时权限、应急冻结、合规要求、审批撤销、多设备协调、责任追踪。如果所有最终判断都由本地 Policy 独立完成那么这些治理关系最终都必须被压缩成设备能够理解的配置。这会产生两个问题。第一本地规则会变得越来越复杂。设备开始承担本不属于它的组织逻辑、业务逻辑和风险逻辑最终变成一个没人能完整解释的庞然大物——这正是第一篇警告过的复杂度制造安全幻觉。第二本地配置会变成新的治理中心。谁能够更新本地配置谁就拥有事实上的最终权力系统重新回到单点控制。所以本地执行边界应该保持克制。它负责守住关键事实和不可突破的约束而不是试图复制整个 SaaS 治理系统。克制本身就是一种安全属性。十二、本地与云端冲突时不能简单选择一方真实系统中本地 Policy 与 SaaS Policy 一定会发生冲突SaaS 允许但本地拒绝、SaaS 拒绝但本地仍显示允许、云端策略已经更新但本地尚未同步、本地额度充足但云端风险状态异常、云端审批有效但本地设备状态不可验证、本地白名单允许但组织已经撤销该目标。面对冲突系统不能简单规定永远以云端为准也不能规定永远以本地为准。更合理的原则是冲突本身就是不确定性结果应当向更严格的一侧收敛。如果 SaaS 拒绝本地不应继续执行如果本地拒绝SaaS 也不能远程强制放行如果双方状态不一致系统不应该选择对业务最方便的一方而应该缩小额度、限制目标、要求额外确认、等待状态同步、暂停高风险动作或进入 Safe Mode。这里要扭转一个根深蒂固的工程直觉在普通业务系统里冲突是需要被快速消除的障碍但在高风险执行里策略冲突是执行系统必须认真对待的风险信号。冲突意味着至少有一个来源看到了别人没看到的东西——在弄清楚之前收缩永远比放行安全。这一点是后续几篇多源收敛的核心本篇先埋下。十三、本地 Policy 需要证明自己处于什么状态本地 Policy 不能只输出ALLOW它还应该能够说明使用的是哪个策略版本、当前治理 Epoch 是多少、本地状态最后何时更新、当前设备是否健康、当前额度计数是多少、当前模式是正常还是收缩、哪些外部状态已经验证、哪些状态仍然缺失、最终判断绑定了哪个 Intent、判断结果有效到什么时候。这使本地判断不再是一个神秘的黑箱结论而是一份有条件的本地声明在当前设备状态、当前本地策略和当前已验证外部状态下这个具体意图没有突破本地边界。这份声明沿用了第二篇提出的带条件决策凭据思路只是把它落到了本地侧。它很重要——但它仍然只是多源决策的一部分而不是终局。十四、真正独立的本地边界不等于孤立边界独立很容易被误解成孤立。独立的本地边界应该能够不被 SaaS 强制绕过、在网络断开时保持基本约束、独立验证最终执行参数、独立拒绝异常请求、独立生成执行证据、在上游失陷时限制最大损失。但它仍然需要接收和验证组织治理状态、审批事实、身份变更、策略版本、风险冻结、业务意图、外部撤销信号。两者的分界很清晰独立意味着它有自己的判断与拒绝能力孤立则意味着它假设自己不需要其他来源的信息。前者提高韧性后者会制造盲区。一个孤立的本地边界会在网络恢复后依然用着过期的世界观放行请求。所以好的本地执行边界应当既独立又受多源事实约束——独立是为了不被绕过受约束是为了不失明。十五、AI Agent 时代本地 Policy 更不能只判断工具权限在 AI Agent 系统中本地 Policy 很容易被设计成一组工具级限制例如允许 Agent 调用退款接口或允许 Agent 执行服务器重启。这种规则仍然过于宽泛。因为本地 Policy 如果只知道工具允许却不知道具体动作就可能放行错误目标、错误金额、错误时间、错误权限范围、重复调用、被诱导生成的参数、已经失效的业务请求。AI Agent 的风险并不只在于是否拥有工具更在于它如何使用工具。所以本地 Policy 必须面对具体执行意图对哪个对象、使用什么参数、执行多少次、权限持续多久、是否与审批内容一致、是否与当前治理状态一致。即使如此本地仍然无法单独判断完整业务合理性。它只能保证Agent 最终提出的动作没有突破当前可验证边界。这再次说明本地是最后边界而不是唯一裁判。工具级授权和参数级动作之间的鸿沟本地必须去弥合但弥合不等于独断。十六、真正安全的分工云端理解业务本地守住现实一个更合理的执行控制体系不要求任何一层无所不知。它接受每个层都有自己的能力边界。SaaS Policy负责理解组织身份、业务上下文、审批流程、风险状态、动态治理、跨节点协同。它回答从组织和业务角度这个请求是否应该继续Hub 或本地治理层负责验证云端状态、维护本地策略、收敛多源结果、管理额度与频率、绑定真实意图、发现状态冲突。它回答这些不同来源的判断是否能够形成一致、可执行的约束独立执行边界负责验证最终参数、检查不可突破的本地限制、验证意图与审批绑定、拒绝过期和冲突请求、控制真实执行、生成设备级证据。它回答这个具体动作现在是否可以在受控范围内发生任何一层都不完整。但正因为它们不完整才需要彼此限制。完整性不是来自某一层而是来自它们的相互约束。十七、结语本地应该是边界不应该是神谕本地 Policy 很重要。没有本地 PolicySaaS 一旦失陷就可能直接控制真实执行没有本地额度、目标限制、计数器、设备状态和参数验证执行层就只是云端命令的机械延伸。所以本地必须拥有独立拒绝权必须能够在云端判断错误时说不必须能够在网络异常、状态冲突和参数变化时收缩执行能力。但本地 Policy 同样不是绝对真理。它看到的业务世界有限它依赖的输入可能被污染它保存的状态可能过期它的规则可能静态它的管理员也可能犯错或滥用权限。因此真正安全的设计不是把最终权力从 SaaS 转移到本地而是让 SaaS 无法绕过本地让本地也无法忽略其他独立治理事实。本地应该拥有最后的拒绝能力但它不应该仅凭自己的有限视野独自推动高风险动作发生。因为安全不来自换一个更可信的中心它来自一个没有任何单一来源能够独自导致灾难性执行的结构。Policy 不是神谕。本地可以守住最后的边界但它不应该独自解释整个世界。下一篇预告《Policy 不是神谕五》将转向最后一类、也是最容易被高估的策略来源——审批 Policy也就是人。多人审批看似天然可信但人会被误导、会疲劳、会被催促也可能只是在点击一个被重新包装过的意图。我们会拆解为什么有人参与并不等于授权真实。本文是「Policy 不是神谕」系列第四篇。第三篇拆解了 SaaS本篇拆解了本地下一篇拆解审批人。三者合起来将得出系列第二阶段的总结论云端、本地和人都不能单独成为最终裁判。