Havenlon 设计哲学（四）：可信，不等于不需要约束

在安全系统里可信几乎总是一个褒义词。可信管理员、可信设备、可信执行环境、可信服务、可信模型、可信根——一个组件越可信人们就越愿意把更多权限交给它权限越多它承担的职责也越多。沿着这条路走下去系统最终往往会得出一个看似顺理成章的结论既然它足够可信就没有必要再限制它。而这恰恰可能是整个系统最危险的时刻。因为可信描述的是我们对一个组件的判断约束决定的是这个组件一旦出错能造成多大的后果。这是两个完全不同的问题。一个组件可以非常可信却依然可能因为漏洞、误配置、状态异常、供应链污染或上游输入被篡改而做出错误行为。可信度再高也只是把这件事发生的概率压低从来没有把它压到零。因此Havenlon 的第二条设计原则是可信不等于不需要约束。越重要、越可信的组件越需要明确的能力边界。一、可信是一种判断不是一种自然属性人们很容易把可信理解成组件自身固有的属性。仿佛一台设备一旦通过安全认证它就会永久安全一个管理员通过了严格背调他就会永远可靠一个 AI 模型在大量测试集上表现良好它就不会在真实环境中偏离预期。但工程世界里的可信从来不是一种绝对状态。它通常只意味着一件事在特定时间、特定环境、特定输入和特定假设下我们认为这个组件出问题的概率比较低。这些前提条件一旦变化原有的判断就可能整体失效。一个长期可靠的管理员可能在账号被盗之后失去可信性一台通过认证的硬件可能在一次固件更新后引入新的攻击面一套稳定运行多年的 SaaS可能因为一次配置变更而悄悄扩大了权限范围一个表现优秀的 AI Agent可能在遇到新上下文、异常工具返回或恶意注入时做出完全错误的判断。可信不是一张永久有效的通行证它更像一个需要持续重估的工程判断。如果系统把我们目前相信它直接翻译成它可以不受限制地行动那么系统实际上是在做一笔很糟糕的交易用一个随时可能过期的临时判断兑换一份永不回收的永久权力。二、越重要的组件错误半径越大普通组件出错通常只影响一个局部功能。关键组件出错却可能直接改变整个系统的行为。这正是重要组件不能因为更可信就获得更宽松约束的原因。恰恰相反它越重要越应该被限制错误的传播范围。一个普通业务账号被盗攻击者可能只能读取部分数据一个超级管理员账号被盗攻击者却可以修改角色、关闭审计、重置密钥并删除证据一台普通终端故障影响的是单个用户一台根密钥设备出问题动摇的是整个信任体系一个普通 AI 助手理解偏差最多生成一段不准确的文字一个持有生产权限的 AI Agent 判断错误却可能直接改写线上配置、转移资金、停掉关键服务。组件越重要错误半径通常越大。如果系统没有为它划出清晰的能力边界那么所谓的关键组件很容易在无声无息中演化成关键单点。真正成熟的设计不会只追问它可靠吗而是同时回答另一个更难的问题当它失效时损失最多可以扩散到哪里三、能力边界不是不信任而是工程责任对可信组件设置约束经常被误解成一种态度问题——你不相信我。管理员会问既然我是负责人为什么还要限制我的操作 安全设备会被追问既然它已经通过认证为什么不让它直接处理一切 AI 系统同样会被要求放开全量工具权限既然模型能力足够强为什么还要一步步审批但能力边界从来不是情绪判断。它不是在说某个组件不值得相信而是在明确地回答这个组件应该对什么负责以及不应该对什么负责。一个好的边界至少要回答三个问题这个组件可以做什么这个组件不能做什么当它出现异常时系统如何阻止异常继续传播落到具体设计上它长这样管理员可以配置组织策略但不能单方面删除全部历史证据SaaS 可以组织和编排审批流程但不能替换掉最终的执行对象AI 可以生成执行建议但不能自己证明自己的建议已获授权硬件可以验证执行边界但不能凭空创造业务意图执行器可以完成外部动作但不能在缺少有效裁决的情况下自行执行。边界不是削弱一个组件的价值而是保护它不被迫承担超出其能力范围的责任。一个只负责密码学运算的硬件本就不该被要求理解商业意图一个只负责生成方案的模型本就不该被要求承担资金安全的最终责任。让组件承担它无法判断的事本身就是设计缺陷。四、最可信的组件往往最容易获得过多权限系统中的权力很少是一次性集中起来的。它更常见的形成方式是在一次次为了方便的决定中一点一点累积出来的。管理员的权限是这样长出来的最开始他只负责账号管理后来为了处理异常增加了重置权限为了提高效率又增加了绕过审批的能力为了方便排障再允许他关闭部分安全检查。最终这个角色同时拥有了修改规则、绕过规则、关闭记录和触发执行的全部能力。硬件也会经历同样的过程最开始它只负责保护密钥后来增加签名能力再后来为了提升自动化程度它开始接收云端命令并自动签名。到最后只要上游请求格式正确这台可信硬件就会完成任何操作。AI Agent 更是如此先让它读取信息再让它调用几个低风险工具随后是写入权限、生产权限、长期凭证。每一次扩权单独看都有充分理由但这些权限叠加在一起就悄然构成了一个能够独立完成不可逆执行的主体。这就是可信组件的悖论它越值得信任人们越容易不断给它加权限权限越集中它一旦出错后果越难收拢。所以安全设计不能只审查这次授权是否合理还必须定期审查权限累积之后的整体能力。单次授权的合理性可以逐项论证但权力的总和从来不会自己提醒你它已经越界了。五、安全硬件同样必须被限制安全硬件常被视为系统中最可信的一层。它可以隔离密钥、保护固件、执行密码运算并通过物理结构大幅提高攻击成本。这些能力非常重要也确实构成了很多系统的信任起点。但硬件的可信性主要来自它在特定任务上的可控性而不代表它能够理解业务。它可能知道某个签名请求在密码学上完全有效却不知道这笔转账是否符合公司的真实意图它可能确认某份审批凭证未被篡改却不知道审批人当时看到的对象和最终执行的对象是否一致它可能安全地保存着一把私钥却无法独立判断此刻是否应该动用这把私钥。如果系统因为硬件足够安全就允许它依据上游命令直接执行那么这台硬件不过是一个更坚固的自动执行器。攻击者不一定需要攻破硬件他只需要让硬件收到一个看起来完全合法的错误请求。因此安全硬件不应被赋予无限的业务权力。它应当拥有明确而有限的职责验证必要条件是否完整验证意图、审批与执行对象是否严格绑定验证当前状态是否仍处于允许边界之内在未知、缺失、过期或冲突时拒绝执行在完成裁决后生成独立、可核验的证据。硬件可以成为边界但不能成为没有边界的权威。六、AI 越强越需要来自外部的能力约束在 AI Agent 时代这个问题会变得格外尖锐。过去限制软件能力相对容易因为传统软件只能执行预先编写好的流程行为空间是可枚举的。AI Agent 不同。它可以根据目标动态生成步骤、选择工具、组合接口、解释返回结果并据此决定下一步行动。这意味着系统很难通过穷举所有可能行为来预判它最终会做什么。模型能力越强它能组合出来的行动路径就越多。因此面向 AI 的安全设计不能只依赖模型是否聪明测试是否通过或提示词是否写得足够严格。提示词是一种行为引导不是一道不可突破的执行边界。模型可以被诱导可以误解上下文也可能在多个局部都合理的步骤之间拼出一个整体错误的行动。这类失败最难防因为它在每一步都通不过直觉审查。真正有效的约束必须位于模型之外AI 可以决定如何完成任务但不能自行扩大自己的能力范围AI 可以生成操作参数但最终参数必须经过独立策略验证AI 可以调用工具但每个工具都应有明确的权限、对象范围、额度和有效期AI 可以提出高风险行动但不能同时担任请求者、审批者和最终执行者。这不是因为 AI 一定比人更不可靠而是因为一个能够自主组合行动的系统更不能拥有无边界的执行能力。七、可信组件不能自己定义自己的边界如果一个组件既能行动又能修改约束自己行动的规则那么它实际上并未受到任何真正的约束。一个 Agent 当前只能执行一万元以内的付款但它同时拥有修改额度策略的权限——那么一万元上限根本不是它的真实边界一个管理员需要多人审批才能删除数据但他可以修改审批人名单并重置他人凭证——那么多人审批只是一层形式一台硬件只有在策略允许时才签名但它可以接收远程命令更新策略而新策略无需独立验证——那么边界最终仍由上游随意决定。能被自己修改的边界从来不是边界。因此真正的能力边界必须独立于被约束者它可以提出变更但不能单方面让变更生效 它可以请求更高权限但不能自行授予 它可以报告自身状态但不能把自己的报告当作唯一证据 它可以参与规则执行但不能同时控制规则的定义、解释与最终裁决。这也是 Havenlon 强调分层不信任的原因。分层不信任并不是说每一层都不可信而是说任何一层都不能仅凭自身陈述证明自己应该获得更大的权力。八、边界应当描述最多能做什么许多权限系统只关心一个问题这个组件是否被允许进入系统但对于高风险执行是否允许访问远远不够。真正需要明确的是允许它访问哪些对象允许它执行哪些动作允许的金额、频率和时间窗口允许在哪种现实状态下执行需要哪些独立证据才能放行出现异常时是否自动失效执行结果必须留下什么证明。边界描述得越具体组件出错后的影响就越容易被圈住。举例来说不是简单允许 AI访问财务系统而是允许它在指定时间窗口内对指定账户生成不超过特定额度的付款请求且最终收款对象必须与审批对象一致不是允许硬件签名而是只允许它对满足完整执行证明的特定意图签名不是允许管理员管理系统而是把策略配置、设备管理、证据删除、紧急恢复拆分为彼此独立的能力。真正的能力边界不是一个抽象的角色名称而是一组可以被逐条验证的限制条件。九、约束必须在执行之前生效很多系统也记录操作日志也在事后审计管理员行为。但事后审计解决的是责任追溯不是执行控制。当资金已经转走、生产环境已经被删除、设备已经停机日志再完整现实也不会自动回滚。所以关键约束必须在不可逆执行之前生效。系统不能只在事后追问谁做了这件事而必须在动作发生之前先回答清楚这个角色是否只能做这类操作当前参数是否落在允许范围内最终执行对象是否与原始意图一致必要证据是否完整当前环境是否仍满足执行条件任何一个关键条件无法被证明都不应该生成执行许可。约束的价值不在于事后解释错误为何发生而在于错误成为现实之前系统仍然保留说不的能力。十、可靠性与约束解决的是两个不同问题强调约束并不意味着不需要提升组件自身的可靠性。系统仍然应该选择更安全的硬件、更稳定的软件、更可靠的模型和更严格的管理制度。但必须看清可靠性降低错误发生的概率约束限制错误发生后的影响。只追求可靠性系统会陷入一场无止境的寻找——不断寻求更不容易出错的组件却始终无法回答它一旦出错怎么办。只强调约束而忽视可靠性系统则会频繁拒绝正常操作最终因为难以使用而被绕过——而被绕过的安全机制等于不存在。成熟的安全工程必须同时具备两者让组件尽可能可靠让它即使不可靠也无法造成无界后果。这正是 Havenlon 所强调的对抗性完整系统不能只在所有部分都正常时才保持正确还必须在部分组件出错、失陷或状态不可确认时依然守得住执行边界。十一、真正的信任是敢于限制它一个系统是否真正信任某个组件不该看它给了这个组件多少无限权力。恰恰相反成熟的信任建立在三件事之上职责明确、权限有限、边界可验证。我们信任刹车系统不是因为它能控制整辆汽车而是因为它只负责在明确输入下减速 我们信任保险丝不是因为它能决定整个电网如何运行而是因为它在电流越界时拥有明确的断开职责 我们信任安全硬件也不应该是因为它能替代所有决策而应该是因为它在确定的边界内执行确定的裁决。清晰的约束不会削弱可信组件。它让可信变得可验证让责任变得可解释让错误变得可控制。Havenlon 从不把信任理解为无条件授权。它更接近一种工程承诺我们相信你能完成被分配的职责但不会让整个系统依赖你永远不犯错。管理员需要边界。 AI 需要边界。 SaaS 需要边界。 策略需要边界。 安全硬件同样需要边界。组件越重要、越可信、越接近最终执行它的能力边界就越应该清楚。因为一套安全系统真正需要的从来不是一个永不犯错的可信中心而是一种结构——可信不是解除约束的理由。真正的可信恰恰来自边界清晰、权力有限以及错误无法越界。