SaaS 可以提出允许但它不应该仅凭一次云端判断就让高风险动作直接进入现实。摘要现代企业越来越依赖 SaaS Policy。身份、权限、审批、额度、风控、组织关系、任务编排、AI Agent 治理往往都集中在云端完成。SaaS 的优势非常明显它能够看到更完整的业务上下文可以快速更新策略可以协调多个成员与系统可以统一记录审批与操作日志可以根据实时数据调整风险判断。因此人们很容易进一步推导既然 SaaS 掌握最多信息它就应该拥有最终放行权。但这一步并不成立。信息更完整不等于永远正确判断更智能不等于不可被污染管理更集中也不等于适合承载最终执行权。SaaS 运行在软件域、网络域和账户体系之中。它会受到身份接管、权限误配、策略篡改、供应链风险、内部人员操作、状态延迟和业务数据污染的影响。如果 SaaS Policy 一旦返回ALLOW执行层就无条件服从那么攻击者只需要控制这个云端判断中心就可能把一次错误判断直接变成真实损失。前两篇讲清楚了Policy 是判断而非事实和判断依赖状态与时间。从这一篇开始我们逐个拆解具体的策略来源。第一个就是最强、也最容易被误当成神谕的 SaaS它应该是治理与协同平面可以提出策略、组织审批、计算风险、同步状态、发起执行请求——但它不能单独决定这个高风险动作现在必须发生。一、为什么现代系统喜欢把 Policy 放进 SaaS把 Policy 放进 SaaS是一个非常自然的工程选择。企业的组织关系、成员身份、权限配置、审批流程和业务数据本来就大量存在于云端。如果策略系统也部署在 SaaS 中它可以就近获取用户身份、组织角色、部门关系、审批记录、历史行为、账户状态、风险评分、业务订单、额度使用、设备在线状态、外部情报乃至 AI Agent 的任务上下文。相比一台本地设备SaaS 能够看到更广的世界。它可以知道某个员工是否已经离职某笔付款是否属于真实订单某个账户是否曾经出现异常某项操作是否已经经过完整审批也可以通过云端模型持续分析新的风险信号。因此SaaS Policy 很适合回答这个问题从组织治理和业务上下文来看这个请求是否应该被提出这正是 SaaS 的价值所在本系列并不否认它。问题不在于 SaaS 参与判断而在于系统是否把参与判断悄悄升级成了拥有最终执行权。这一字之差决定了整个系统的失效模式。二、SaaS 看到的是业务世界不是完整执行现实SaaS 擅长理解业务上下文但它并不天然掌握最终执行环境中的全部事实。例如云端审批系统可能知道这是一笔已确认的供应商付款、金额在预算范围内、两位负责人已经审批、收款对象位于组织白名单、风险评分处于正常区间。于是 SaaS Policy 返回ALLOW但真正执行发生前仍然存在另一组它未必看得清的问题最终序列化后的收款地址是什么、最终提交金额是否与审批金额一致、当前使用的是哪一个密钥槽位、本地额度是否已被其他请求消耗、执行设备是否处于正常安全状态、当前策略版本是否已经同步、请求是否在传输或转换过程中发生改变、本地边界是否检测到云端不可见的异常、最终执行对象是否仍然与原意图绑定。这里有一个清晰的分界SaaS 看到的是这笔业务应该做什么执行边界面对的是现在究竟要做什么。两者高度相关却不是同一件事。这其实就是第一篇提到的混淆代理confused deputy在系统层面的展开——一个系统如果只验证业务语义却不验证最终动作就可能出现云端批准的是正确业务下游执行的却是错误参数。所以 SaaS Policy 可以判断业务合理性但它不能仅凭业务合理性就证明最终执行安全。三、SaaS Policy 仍然运行在可被控制的软件域中SaaS 再强大本质上仍然是软件系统。它依赖云服务器、数据库、管理后台、账户权限、API、网络连接、CI/CD、第三方服务、运维人员、供应链组件、软件配置、密钥与令牌。这些系统都可能失效也都可能被控制。常见风险包括管理员账户被盗、高权限令牌泄露、身份提供商被接管、数据库被篡改、Policy 配置被错误修改、部署流程被污染、内部人员滥用权限、API 鉴权出现缺陷、第三方依赖被攻陷、缓存或同步状态过期、业务数据被伪造、风险模型被诱导。如果 SaaS Policy 具有单独放行执行的能力那么这些风险就不再只是云端控制面风险它们会直接获得改变现实的能力。用安全工程的语言说这是一个攻击面attack surface与爆炸半径blast radius的问题。SaaS 的攻击面本来就大——账户、令牌、供应链、内部人员每一项都是入口。当放行权集中在这里时任意一个入口被突破爆炸半径就等于全部真实执行。这意味着一旦 SaaS 被完全控制攻击者也同时获得了最终执行权。从架构角度看这是一种危险的权力集中。四、SaaS 被攻破不应等于执行边界同时失守成熟系统必须考虑最坏情况。不是只问SaaS 平时是否可靠而是问如果 SaaS 已经被彻底攻破系统还剩下什么如果答案是攻击者可以修改 Policy、可以伪造审批、可以创建高权限成员、可以发出执行请求而执行层会无条件服从那么所谓的执行控制实际上并不存在。系统只是在 SaaS 前面增加了很多验证步骤而一旦这些步骤的控制中心被拿下所有防线会同时失效——这正是纵深防御defense in depth的假象看起来层层设防实则所有层共享同一个信任根一破皆破。真正独立的执行边界应该做到一件事即使 SaaS 已经返回允许本地仍然可以拒绝。这不是不信任 SaaS 的价值而是不允许 SaaS 的一次失陷自动演变成整个系统的灾难。换句话说SaaS 可以被攻破但攻击者不应该因此天然获得最终执行能力。这才是独立执行控制存在的意义。五、云端审批也可能只是云端状态的一部分很多 SaaS 平台会强调请求已经经过多人审批因此可以放心执行。多人审批当然比单人操作更强。但如果审批、身份、Policy 和执行发起全部集中在同一个 SaaS 域中那么这些机制可能并没有真正独立。例如攻击者控制高权限云端账户后可能同时做到创建新的审批成员、修改审批规则、调整额度、改变角色权限、伪造业务背景、将请求标记为已批准、立即发起执行。表面上看系统仍然经过了 Policy 判断、身份验证、多人审批、权限校验、日志记录。但这些环节都处于同一个控制域中它们并没有形成真正的相互约束。这说明一个容易被忽视的事实流程很多不代表权力真的分散。真正的职责分离separation of duties*要求发起与批准位于不同的信任边界一方的失陷不能同时污染另一方。如果所有判断都由同一个 SaaS 状态决定那么 SaaS 仍然是唯一*信任根root of trust。而单一信任根一旦失效整条执行链就会同时失去意义——再多的审批环节也只是同一个根上长出的枝叶。六、SaaS Policy 可能基于被污染的业务上下文SaaS 的优势是拥有丰富的业务数据但丰富的数据也意味着更大的污染面。策略系统可能依赖 CRM 数据、ERP 订单、工单系统、财务记录、身份目录、风险模型、用户输入、AI 生成内容、外部 API、文档与邮件、自动化工作流。攻击者不一定需要直接攻击 Policy 引擎他们也可以污染 Policy 依赖的信息创建一个看似真实的供应商订单、修改客户退款状态、伪造紧急运维工单、提交恶意文档诱导 AI Agent、更改白名单对象的显示名称、制造虚假的风险低分、利用同步延迟维持旧权限、将恶意请求包装成正常业务流程。此时SaaS Policy 可能完全按照规则正确运行。它看到的每一项条件都满足最终返回的ALLOW也符合预期。但整个判断建立在被污染的上下文之上。这就是经典的垃圾进垃圾出garbage in, garbage out只不过在安全语境下进来的不是无意的垃圾而是精心构造的污染Policy 引擎没有被攻破不代表 Policy 判断没有被操纵。SaaS 越依赖复杂上下文它越需要承认自己看到的世界可能是被别人包装过的。七、AI Agent 会进一步放大 SaaS Policy 的权力风险在 AI Agent 场景中SaaS Policy 往往不仅判断用户权限还参与工具调用治理。例如云端系统可能判断该 Agent 可以调用退款工具或该 Agent 可以管理云资源。这样的 Policy 很容易被设计成高层权限判断一旦通过Agent 就可以持续生成具体动作。但 Agent 的任务过程是动态的——它会理解用户指令、读取外部资料、生成执行计划、选择工具、构造参数、根据返回结果继续行动。如果 SaaS Policy 只在高层判断这个 Agent 有权执行此类任务然后允许 Agent 后续自由调用真实工具那么一次宽泛授权就可能覆盖大量不可预见的动作。允许处理退款可能逐渐演变成选择错误客户、使用错误账户、多次重复退款、超过单次额度、在风险状态变化后继续执行、被恶意内容诱导修改目标。这正是第二篇提到的任务级授权 vs 参数级动作错配在 SaaS 侧的体现。因此AI Agent 时代的 SaaS Policy 不能只给任务发一张长期通行证。每个关键动作仍然需要被具体约束对谁执行、执行什么、数量是多少、权限范围多大、有效时间多久、是否需要新的确认、本地边界是否允许。AI 可以提出动作SaaS 可以判断业务条件但最终动作不应仅凭云端策略直接发生。八、SaaS 的高可用目标与执行安全目标并不总是一致SaaS 系统通常追求服务持续在线、请求不中断、工作流快速完成、用户体验顺畅、自动化成功率高、尽量减少人工介入。这些目标在普通业务中非常合理但对高风险执行来说它们可能与安全目标发生冲突。当本地状态无法同步时SaaS 可能倾向于使用最近一次已知状态继续执行当风控服务暂时不可用时业务系统可能倾向于先放行之后再补充检查当策略冲突阻碍交付时管理员可能倾向于临时放宽规则避免业务中断。这是一种典型的可用性优先fail-open思维。而执行边界的目标不同它需要问在关键状态不可验证时是否仍然能够证明执行安全如果不能就应该缩小额度、限制目标、要求本地确认、延迟高风险动作、暂停执行或进入 Safe Mode。这是安全优先fail-secure / fail-closed的思维。两种思维没有绝对对错但用错了地方就是灾难。因此不能让以业务连续性为主要目标的 SaaS单独决定高风险执行是否继续。它可以表达业务紧迫性但安全边界不能因此放弃自己的约束。九、SaaS Policy 更新得越快越需要独立限制快速更新是 SaaS Policy 的优势。组织可以随时修改角色、增加白名单、调整限额、改变审批规则、添加新的 Agent 权限、临时开放紧急操作、更新风险模型。但快速变化也意味着云端可以迅速扩大某个账户或请求的能力。如果策略修改后能够立即推动真实执行那么一次错误配置就可能直接产生不可逆后果。例如管理员误把单笔额度从 10 万改为 1000 万、将普通成员错误提升为组织所有者、将高风险工具加入自动执行白名单、临时关闭本地确认要求、把审批人数改为零、将新目标加入可信名单。在传统软件里错误配置可以通过回滚修复。但真实执行一旦发生往往无法撤销——资金已经转出数据已经导出权限已经授予设备已经启动证书已经替换。回滚只能撤销状态撤不回后果。所以SaaS Policy 的快速更新能力必须受到另一层独立边界约束。云端可以修改治理意图但涉及扩大执行能力的变化不应仅凭云端自己立即生效——尤其是那些跨过阈值、放宽约束的变更本身就应该被当作一次需要额外确认的高风险动作。十、SaaS 日志不能代替执行证明SaaS 通常拥有完善的审计日志可以记录谁发起了请求、谁修改了策略、谁批准了操作、Policy 返回了什么结果、工作流何时完成、API 是否调用成功。这些记录非常重要但它们描述的主要是SaaS 认为发生了什么。这与真正的执行事实并不完全相同。例如 SaaS 可以记录转账请求已批准并成功提交但它未必能够独立证明最终签名对象是什么、最终参数是否与审批一致、使用了哪一个设备状态、本地执行边界是否真正接受、最终结果是否由可信设备确认、请求是否在中间环节被改变。关键的风险在于如果执行事实完全由 SaaS 自己报告那么当 SaaS 被攻破时攻击者既可以控制执行请求也可以控制事后记录——既作案又改证词。一个不能防止记录者即作案者的审计体系在最需要它的时刻恰好失效。真正可靠的证据应该来自执行边界本身真实意图摘要、最终参数摘要、Policy Hash、本地状态、计数器、前后证据链、设备签名、实际执行结果。这类由执行侧生成、可独立验证的证据才是防篡改tamper-evident的。SaaS 可以归档、展示和协同这些证据但它不能成为执行事实的唯一来源。十一、SaaS Policy 应该拥有否决能力但不应拥有单独放行能力一个很重要的设计原则是某一层可以独立收缩权力但不应独自扩大权力。当 SaaS Policy 发现成员已离职、风险评分异常、审批被撤销、订单状态失效、组织进入紧急状态时它应该能够阻止请求继续。也就是说SaaS 可以独立说DENY因为拒绝不会扩大执行风险——最坏结果是某个操作没做成这在安全上永远是可接受的。但当 SaaS 返回ALLOW它表达的应该是从云端治理和业务上下文来看目前没有发现拒绝理由而不是所有其他边界必须立即执行。这就形成了一种刻意的不对称DENY可以是终止信号ALLOW只应该是继续验证的资格。这种不对称非常重要它是整个多源收敛机制的地基。因为安全系统不应把一个来源没有发现问题等同于所有来源已经证明安全。前者是一次局部沉默后者才是全局证明。十二、SaaS、Hub 与本地边界应该如何分工在一个更合理的执行控制体系里不同层应该承担不同职责并被放在不同的信任边界中。SaaS治理与协同。负责组织身份、角色与成员关系、策略管理、审批协调、风险分析、任务编排、状态展示、证据归档、跨节点协同。它回答的是从组织与业务治理角度这个请求是否具备继续向下的条件Hub本地治理状态与策略收敛。负责维护本地可验证状态、接收并验证 SaaS 更新、管理本地额度和频次、比较多个策略来源、绑定真实执行意图、检查状态版本、处理策略冲突、在异常时进入收缩模式。它回答的是云端判断与本地治理状态是否能够收敛本地执行边界最终许可与拒绝。负责验证最终执行参数、验证意图绑定、检查不可突破的本地约束、验证密钥与执行槽位、检查计数器和执行状态、拒绝过期或冲突或不可验证的请求、生成执行证明。它回答的是这个具体动作现在是否真的可以发生这种分工不是重复建设而是把不同类型的权力放在不同的信任边界中——让任何单一边界的失陷都不足以独自跨越所有边界。十三、SaaS 与执行边界之间不应该是命令关系很多系统将 SaaS 与设备的关系设计成SaaS 下发命令 设备执行命令这种结构简单高效但它也把 SaaS 变成了事实上的远程控制中心——设备沦为一个只会服从的执行器。更安全的关系应该是SaaS 提出治理意图 Hub 验证并收敛状态 执行边界独立决定是否许可SaaS 发出的不应该是立即执行这笔操作而应该是根据当前云端治理状态这项执行请求已经满足云端条件请其他边界继续判断。这看起来只是表达方式的变化实际上它改变了系统中的权力关系命令意味着下游必须服从请求意味着下游保留拒绝权。真正独立的执行控制必须建立在后者之上。一个只会服从命令的执行器无论前面加多少验证本质上都只是把决定权原样交给了发令方。十四、网络断开时最能看出 SaaS 是否拥有过大权力判断 SaaS 是否被赋予过大权力可以问一个简单问题当 SaaS 无法连接时本地系统会发生什么如果系统完全停止所有能力说明 SaaS 可能已经成为唯一信任中心如果系统忽略状态缺失、继续执行所有请求说明本地又缺少必要约束。两个极端都不对。更合理的方式是分级降级低风险、已预授权、范围有限的操作可以依据本地状态继续新增目标、提高额度、扩大权限等动作应当被禁止高风险执行需要最新的多源状态无法验证云端状态时系统进入收缩模式本地绝不能因为 SaaS 离线而自动放宽限制。这实际上是分布式系统里脑裂split-brain*问题的安全版处理当节点间失联、无法确认全局状态时正确的做法不是各自为政地继续放行而是收缩到一个可以在本地独立证明安全的最小能力集。这样SaaS 既不是唯一允许系统运行的根也不是离线时可以被完全忽略的附加项。它与本地边界之间应该形成*受控依赖而不是绝对控制。十五、真正的问题不是 SaaS 是否可信而是它是否权力过大讨论 SaaS Policy 的局限并不是说 SaaS 不可信。现实中优秀的 SaaS 平台可以拥有完善的安全团队、强身份体系、多因素认证、严格审计、风险监控、高可用架构、成熟的权限模型和快速响应能力。但安全架构不能只建立在我们相信这个平台足够安全之上。更重要的问题是即使它有一天不再安全它最多能造成什么这就是假设失陷assume breach的思维方式。如果 SaaS 失陷后仍然无法直接突破本地额度、无法替换最终参数、无法跳过物理边界、无法伪造设备证据、无法单独触发灾难性执行那么系统仍然具有韧性。反之如果 SaaS 失陷后可以直接控制全部执行那么再完善的云端安全也只是在保护一个过于强大的单点权力。所以问题从来不是简单的信任或不信任 SaaS而是是否把不应该集中在 SaaS 的最终执行权也交给了 SaaS。信任是一个程度问题权力边界却是一个结构问题——后者才是架构真正要解决的。十六、结语SaaS 可以治理执行但不能成为执行本身SaaS 是现代执行系统不可缺少的一部分。它擅长理解组织、业务、身份、审批和风险可以让复杂治理更高效让分布式成员更容易协作让策略能够持续更新。但 SaaS 的这些优势并不能自动赋予它最终执行权。因为它仍然是一个软件域它看到的是业务状态而不是完整执行现实它可能被接管、被误配、被诱导也可能基于被污染的上下文作出完全符合规则的错误判断。因此SaaS Policy 最合理的位置是治理请求而不是统治执行。它可以说组织允许继续、审批已经完成、当前风险可接受、请求符合云端规则。但它不能单独说所有边界都必须服从这个动作现在立即发生。真正安全的系统会保留一条独立于 SaaS 的最终拒绝路径。这条路径不是为了否定云端而是为了保证即使云端已经失守、判断已经错误、上下文已经被污染错误仍然不能轻易跨越最后的执行边界。Policy 不是神谕。SaaS 可以提出允许但真实执行必须经过独立边界的再次裁决。下一篇预告《Policy 不是神谕四》将转向另一端——本地 Policy。它更难被远程绕过、更贴近执行看起来像是理想的最终裁判。但本地 Policy 的信息更有限、规则更静态同样有它无法独自承担最终决定权的原因。本文是「Policy 不是神谕」系列第三篇。它拆解了三类策略来源中看得最全的 SaaS接下来的第四、五篇将分别拆解本地 Policy 与审批 Policy共同得出一个结论云端、本地和人都不能单独成为最终裁判。