Havenlon 对抗性完整（二）：攻击者不是黑客，而是任何能改变执行结果的人

在传统安全语境里攻击者通常被想象成黑客。他们利用漏洞进入系统绕过登录窃取数据篡改权限或者控制服务器。这个理解并没有错但对于 Havenlon 这样的执行控制系统来说它还远远不够。因为 Havenlon 关注的核心不是“系统有没有被入侵”而是“某个动作是否被错误地执行”。一旦系统连接到真实资产、真实密钥、真实 API、真实证书、生产环境或者自动化任务攻击的本质就会发生变化。攻击者不一定需要完全攻破系统也不一定需要拿到最高权限。只要他能够让系统在错误条件下放行一个动作或者让系统执行一个原本不应该发生的动作他就已经达到了攻击目的。所以在 Havenlon 的对抗性完整模型里攻击者不是狭义上的黑客而是任何能够改变执行结果的人、系统、流程或上下文。这个定义非常重要。因为它会直接改变我们设计系统的方式。如果我们认为攻击者只是黑客那么系统设计会主要围绕账号安全、服务器安全、网络安全、加密传输、漏洞修复和访问控制展开。这些当然都重要但它们更多是在保护系统入口。而 Havenlon 要解决的问题更靠后也更危险即使入口看起来合法流程看起来合规审批看起来存在最终执行是否仍然可能是错误的这才是执行控制系统真正需要面对的问题。一、执行系统里的攻击不一定表现为入侵很多人判断系统是否安全时会先看有没有被黑、有没有泄露、有没有异常登录、有没有服务器漏洞。但在执行控制场景里攻击可能完全不表现为这些形式。一个账号可以是合法登录的一个审批可以是真实发生的一个 API 请求可以带着正确的 Token一个签名设备可以没有被拆开一个 SaaS 后台也可以没有被攻破。可是只要最终执行的动作不是用户真实想要的或者不是组织策略允许的系统就已经发生了执行层面的失败。比如一个 AI Agent 被恶意上下文诱导生成了一个看似合理但实际危险的操作请求。它没有攻击服务器也没有绕过权限但它改变了执行方向。再比如一个内部成员通过合法权限发起了资产转移请求但这个请求背后的业务理由是伪造的或者它利用了审批者的认知盲区。整个流程看起来是合法的但执行结果是错误的。再比如用户在前端看到的是一个普通操作确认但最终进入硬件签名边界的 payload 已经被替换。用户点击确认是真的设备签名也是真的但用户确认的内容和最终执行的内容并不是同一个东西。这些场景的共同点是攻击不一定发生在系统入口而是发生在“意图到执行”的转换过程中。这也是 Havenlon 为什么不能只做访问控制。访问控制回答的是“谁可以进入系统”而执行控制要回答的是“这个动作是否应该发生”。二、攻击者可以是被控制的账号在很多系统里只要账号登录成功就会被认为是合法用户。系统会根据账号权限判断是否允许操作。这个模型在普通业务系统里很常见也很高效。但执行控制系统不能只相信账号。因为账号本身可能已经不再代表真实用户。密码可能泄露Session 可能被盗设备可能被远程控制浏览器环境可能被污染用户可能被钓鱼网站诱导登录甚至用户本人可能在被社工欺骗的情况下主动完成了某些步骤。这时候系统看到的仍然是“合法账号”但这个账号背后的真实意图已经不可靠。如果系统把账号身份等同于执行授权那么账号一旦被控制攻击者就可以借用合法身份发起高危动作。这种问题在很多系统里都非常严重因为它表面上不像攻击而像正常业务操作。Havenlon 需要把身份和执行分开看。身份只能证明“谁在发起”但不能直接证明“这个动作应该执行”。一个合法身份发起的请求仍然需要经过策略、审批、设备确认、payload 绑定和硬件边界验证。也就是说身份是执行链的输入之一不是执行链的终点。如果一个系统只要账号合法就允许关键动作发生那么它本质上是在把账号当作最终执行权。但在真实对抗环境里账号是会失效的身份是会被借用的用户环境是会被污染的。Havenlon 要做的是承认这种失效而不是假设它不会发生。三、攻击者可以是被诱导的用户在安全系统里用户经常被放在最后一道确认环节。系统显示信息用户点击确认操作继续执行。表面上看这是把最终决定权交还给用户。但现实问题是用户并不总是理解自己正在确认什么。尤其是在复杂执行场景里用户看到的可能只是简化描述而不是完整 payload。用户可能不知道地址背后的风险不知道合约调用的真实含义不知道 API 调用会触发什么后续流程也不知道某个策略变更会影响未来哪些执行权限。更复杂的是用户可能被诱导。他可能收到一条看似来自同事的消息可能看到一个伪装成正常业务流程的请求可能在紧急气氛下做出快速确认也可能在 AI 生成的解释中误以为某个动作是安全的。在这种情况下用户本人并不是恶意的但他的确认可能被攻击者利用。这类攻击非常危险因为系统日志里会显示“用户已确认”。很多传统系统会把这视为责任闭环但从执行控制角度看这并不一定足够。因为关键问题不是用户有没有点确认而是用户确认的内容是否真实、完整、可理解并且是否和最终执行内容绑定。Havenlon 不应该把用户当成完美安全边界。用户是执行控制链中的重要参与者但不是唯一边界。用户确认必须被策略约束必须与真实 payload 绑定必须在可信设备上呈现关键内容必须形成可验证证据。否则攻击者只需要改变用户看到的上下文就可能改变最终执行结果。四、攻击者可以是 AI AgentAI Agent 的出现让“攻击者”的定义进一步扩大了。过去系统通常由人直接操作。人点击按钮系统执行动作。即使流程复杂人的操作路径仍然比较明确。但 AI Agent 进入之后系统开始出现一种新的模式人提出目标AI 理解目标AI 拆解任务AI 调用工具AI 推动执行。这个模式会极大提高效率但也带来一个关键问题AI Agent 可能成为执行结果被改变的中间层。AI 不一定是恶意的但它可能被诱导。它可能被 prompt injection 改变任务目标可能被上下文污染可能错误理解用户意图可能过度自信地调用工具也可能把一个本该等待确认的动作当成普通步骤继续推进。在普通信息处理场景里AI 错误可能只是回答不准确。但在执行场景里AI 错误可能会变成真实操作。它可能发起转账调用 API修改配置发出生产变更提交审批请求甚至生成一个看起来非常合理但实际危险的执行 intent。这就是 Havenlon 必须强调的一点AI 可以生成意图但 AI 不能拥有最终执行权。AI Agent 在 Havenlon 里应该被视为一个高效率的请求生成者而不是可信执行者。它可以建议可以整理信息可以生成草案可以解释风险可以提出 intent但它的输出必须经过执行控制链而不能直接进入最终执行。对抗性完整要求我们把 AI Agent 也放进攻击面里。不是因为 AI 一定会作恶而是因为 AI 可能在错误上下文里改变执行方向。只要它能够影响最终动作它就必须被约束。五、攻击者可以是 SaaS 策略层SaaS 在现代系统中承担了大量治理功能。组织管理、策略配置、审批流、日志展示、风险提示、设备管理、成员权限很多都依赖云端平台完成。但在 Havenlon 的模型里SaaS 不能被视为天然可信的最终裁决者。SaaS 也可能成为改变执行结果的来源。比如策略配置错误导致本应被阻止的动作被放行审批流设计错误导致高危操作走了低风险流程后台账号被盗导致攻击者修改组织策略API 权限过宽导致外部系统可以发起不该发起的请求或者 SaaS 本身被攻击攻击者试图通过云端影响本地执行。这里的重点不是 SaaS 是否有价值。SaaS 当然有价值而且对于复杂组织治理非常必要。问题在于SaaS 不应该拥有绕过本地边界和硬件边界的能力。如果 SaaS 可以单独决定并完成执行那么 SaaS 一旦出错或被攻破整个执行系统就会失去最后防线。因此 Havenlon 需要把 SaaS 放在 Decision Layer而不是 Execution Layer。它可以参与判断可以生成策略可以组织审批可以记录证据可以协同多方但它不能单独完成最终执行。最终执行必须经过 Hub、本地策略、硬件确认和执行边界。这意味着即使 SaaS 变成攻击者它的能力也应该被限制在“影响提案和决策输入”而不是“直接完成动作”。这就是受限组件的思想。我们不是假设 SaaS 永远可信而是设计它即使不可信也不能单独造成灾难性执行。六、攻击者可以是内部成员内部人风险是执行控制系统必须正视的问题。很多系统对外部攻击非常敏感却对内部人过于乐观。系统默认管理员是可信的Owner 是可信的审批者是可信的团队成员是可信的。但真实组织中人的关系和状态是变化的。内部成员可能作恶也可能被盗号可能被社工诱导可能因为利益冲突发起危险操作可能在离职前保留权限可能与外部攻击者串通也可能只是误操作。对于 Havenlon 来说内部成员之所以重要是因为他们通常拥有合法身份和真实权限。他们的行为很难被简单识别为攻击因为从权限系统角度看他们本来就有资格做某些事情。但执行控制系统不能只看“有没有权限”还要看“这个动作是否应该由这个人在这个条件下推动发生”。比如Owner 是否可以单独移除关键成员管理员是否可以单独替换设备审批者是否可以在不了解最终 payload 的情况下放行某个成员是否可以通过添加新成员来改变治理结构离职成员是否可以拖延退出导致系统治理僵住这些问题本质上不是单纯的权限问题而是执行结果控制问题。Havenlon 的共同治理设计需要承认内部人风险。一个成员可以参与治理但不能轻易成为系统的单点控制者。Owner 可以拥有更高职责但不应该等于上帝。审批者可以参与授权但审批必须被 payload 绑定。成员变化可以被治理但治理动作本身也必须受到约束。内部人不是系统之外的风险而是系统内部必须建模的攻击者。七、攻击者可以是被替换的 payload在执行控制系统里还有一类非常关键的攻击者不是人而是数据本身。用户发起的 intent、SaaS 生成的 policy decision、审批界面展示的内容、Hub 收到的请求、Security 模块最终签名的 payload这些对象如果没有被强绑定就可能出现替换、重放、裁剪、拼接或上下文错配。比如用户确认的是 A 操作但最终执行的是 B 操作。审批者看到的是小额转账但最终 payload 被替换成大额转账。SaaS 通过的是某个策略版本下的请求但 Hub 执行时使用了另一个策略状态。某个合法请求被重放到新的时间窗口中或者一个旧的审批结果被拿来触发新的执行。这类攻击不一定需要攻破所有系统。攻击者只需要找到意图、审批、策略和执行之间没有绑定的地方就可以改变最终结果。这也是 Havenlon 为什么需要 IntentHash、Step Hash、FinalSigningPayload、Evidence Chain 这一类机制。它们的意义不是为了增加技术复杂度而是为了回答一个根本问题系统最终执行的东西是否就是最初被提出、被审批、被策略允许、被硬件确认的那个东西如果答案不能被验证那么执行链就是可被替换的。在对抗性完整的设计里payload 不是普通数据而是执行事实的核心对象。它必须被绑定、被摘要、被签名、被记录并且在关键步骤之间保持一致性。八、攻击者可以是时间和顺序很多执行风险并不来自内容本身而来自时间和顺序。一个操作在某个时间点是安全的换一个时间点可能就不安全。一个请求在某个上下文里是合理的放到另一个上下文里可能就是危险的。一个审批结果如果被延迟使用可能已经不再符合当前策略。一个设备状态如果没有及时同步可能导致系统基于旧信息继续执行。这说明攻击者不一定需要修改 payload只要改变执行的时间、顺序或上下文就可能改变结果。比如一个本来应该在短时间内完成的审批被延迟到风险状态变化之后才执行。一个旧的合法请求被重放。多个请求被重新排序导致额度、频率、策略窗口判断失效。设备和 SaaS 之间的状态不同步导致一方认为可以执行另一方其实已经进入风险状态。因此Havenlon 的执行控制不能只验证内容还要验证时间、顺序和状态连续性。这也是为什么 TimeGuard、DistanceGuard、Safe Mode、Evidence Backpressure 这类机制重要。它们解决的不是传统意义上的权限问题而是执行链在时间维度上的完整性问题。如果系统不知道当前状态是否仍然可信正确动作不是继续执行而是暂停、降级或进入安全模式。一个成熟的执行控制系统不能在不确定时假装确定。九、攻击者可以是系统集成方式很多安全问题不是单个组件造成的而是集成方式造成的。一个组件本身可能安全另一个组件也可能安全但它们连接起来之后边界可能变得模糊。比如 SaaS 和 Hub 之间的职责划分不清审批系统和执行系统之间没有强绑定AI Agent 和 API 工具之间缺少执行隔离硬件签名器只负责签名但不验证上下文日志系统只记录结果但不能证明过程。这些问题不是漏洞扫描就能发现的因为它们属于架构级风险。在 Havenlon 里系统集成方式本身也必须被视为攻击面。谁可以调用谁谁可以改变策略谁可以发起 intent谁可以解释 payload谁可以最终执行哪个环节可以绕过另一个环节哪个层级的错误会传播到下一个层级如果这些边界不清楚攻击者就不需要攻破系统只需要利用系统之间的缝隙。这就是执行控制基础设施最难的地方。它不是把几个安全组件堆在一起而是要把每个组件的职责、权限、输入、输出、失败方式和证据关系定义清楚。Havenlon 的设计不能只看单点能力而要看整个执行链是否存在绕行路径。只要存在某条路径可以从 intent 直接跳到 execution而不经过策略、审批、设备和硬件边界那么整个系统就没有完成对抗性闭环。十、从攻击者定义开始重新理解 Havenlon如果我们把攻击者重新定义为“任何能够改变执行结果的人或因素”那么 Havenlon 的设计逻辑就会变得更清晰。为什么 SaaS 不能拥有最终执行权因为 SaaS 可能成为攻击者。为什么 AI Agent 只能提出 intent因为 AI 可能成为攻击者。为什么用户确认不能只是点按钮因为用户可能被诱导。为什么 Hub 不能成为上帝因为 Hub 也可能被攻击或误用。为什么硬件必须有 final veto因为最终执行必须有不可绕过的拒绝边界。为什么需要证据链因为执行结果必须能够被追溯和证明。为什么需要 Safe Mode因为系统不确定时继续执行本身就是风险。这些设计不是为了让系统显得复杂而是因为真实攻击路径本来就复杂。Havenlon 需要面对的不是一个单一黑客而是一整条可能被污染、被诱导、被替换、被误用、被拖延、被重放、被绕过的执行链。所以对抗性完整的第二条原则可以这样表达攻击者不是黑客而是任何能改变执行结果的人。从这个原则出发Havenlon 的安全边界就不再只是登录、权限、加密和服务器防护而是贯穿 intent、policy、approval、arbitration、execution 和 evidence 的完整链路。只有当系统能限制所有这些环节中的错误传播才能真正控制执行而不是只控制入口。