Havenlon｜Policy 不是神谕（三）：为什么 SaaS Policy 不能单独放行执行

Lovekde_cn1

71人浏览 · 2026-07-12 09:30:00

Lovekde_cn1 · 2026-07-12 09:30:00 发布

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。 信任是一个程度问题，权力边界却是一个结构问题——后者才是架构真正要解决的。