在 Havenlon 的执行控制模型里，Intent 和 Execution 的区别非常重要。过去讨论这个问题时，我们更多是从系统哲学和架构边界出发，强调“意图不等于执行”，也就是一个请求、一个愿望、一个计划、一个操作描述，并不应该自动变成真实世界里的动作。

但在对抗性完整系列里，我们需要换一个角度来看这个问题。

这里要讨论的重点不是“Intent 和 Execution 在概念上有什么不同”，而是：为什么在真实对抗环境中，Intent 本身就可能被污染、伪造、误导、替换、重放或错配。只要 Intent 会被污染，它就不能被系统直接当成执行依据。

这才是本文真正要讨论的问题。

在执行控制系统里，Intent 不是一个干净、稳定、天然可信的对象。它只是执行链的输入。既然是输入，它就必须被验证、约束、绑定和追踪，而不能被直接信任。

一、Intent 不是事实，而是一个待验证的请求

在很多系统里，用户提交一个请求，系统就默认这个请求代表用户真实意图。比如用户点击转账，系统认为用户要转账；用户点击添加成员，系统认为用户要添加成员；AI Agent 生成一个操作计划，系统认为这是用户目标的合理拆解；SaaS 平台生成一条执行建议，系统认为它是经过策略判断后的结果。

这种设计在普通业务系统里可以工作，因为很多操作可以撤销、可以修改、可以补偿。但在执行控制系统里，这种假设非常危险。

Intent 首先不是事实，而是一个声明。它声明“有人或某个系统希望发生一件事”，但它不能证明这件事应该发生，也不能证明这件事在当前上下文中是安全的，更不能证明最终执行的内容就是最初请求的内容。

一个 Intent 可能来自真实用户，也可能来自被盗账号；可能来自清醒判断，也可能来自社工诱导；可能来自 AI Agent 的正确理解，也可能来自 prompt injection 后的错误计划；可能来自合法业务流程，也可能来自被攻击者精心构造的上下文。

所以 Havenlon 不能把 Intent 当作执行事实。它必须把 Intent 当作一个待验证对象。

这就是对抗性完整视角下的第一个判断：Intent 进入系统，不代表执行链已经获得授权。它只是进入了风险分析和执行控制流程。

二、Intent 可以被来源污染

Intent 的第一个污染点，是来源。

一个请求看起来来自某个用户，不代表它一定代表这个用户的真实意图。账号可能被盗，Session 可能被劫持，设备可能被远程控制，浏览器可能被恶意扩展污染，手机可能处在不安全环境里，甚至用户本人可能正在被社工诱导。

在这种情况下，系统看到的是一个合法账号发起的 Intent，但这个 Intent 的来源已经不干净。

传统权限系统经常在这里停止判断：账号合法，权限足够，请求格式正确，于是继续执行。但 Havenlon 不能这样做。因为执行控制关心的不是“请求来自谁”，而是“这个请求是否应该变成动作”。

身份只能证明发起者，不足以证明执行合理性。

一个 Owner 账号发起的治理 Intent，仍然可能是被攻击者控制后的结果。一个审批者提交的确认 Intent，仍然可能是在错误上下文里完成的。一个 AI Agent 以用户身份生成的操作 Intent，仍然可能并不代表用户真正理解和授权的动作。

所以，Havenlon 必须把身份和意图拆开。身份是 Intent 的来源属性，但不是 Intent 的可信证明。即使来源合法，Intent 也仍然需要经过策略校验、上下文验证、审批绑定、本地仲裁和硬件边界确认。

如果一个系统把“合法来源”直接等同于“可执行意图”，那么来源一旦被污染，整个执行链就会被污染。

三、Intent 可以被上下文污染

Intent 不只是由用户输入组成，它还受到上下文影响。

同样一句“执行这笔操作”，在不同上下文里含义完全不同。同样一个地址、金额、API 调用或治理动作，在不同时间、不同策略状态、不同成员关系、不同设备状态下，风险也完全不同。

这说明，Intent 的风险不只在内容本身，也在它所依赖的上下文。

攻击者可以不直接修改 Intent，而是修改 Intent 周围的上下文，让系统和用户误解它。例如，攻击者可以伪造业务背景，让审批者相信某个操作是正常支出；可以通过聊天记录诱导 AI Agent 认为某个地址是可信地址；可以把高风险动作包装成日常维护任务；可以让用户在紧急氛围中快速确认；也可以通过错误标签、错误解释、错误提示，让一个危险 Intent 看起来很普通。

在 AI Agent 场景里，上下文污染尤其严重。因为 AI 的判断高度依赖上下文。攻击者不一定需要控制系统，只要能把错误信息塞进 AI 的输入环境，就可能改变 AI 生成的 Intent。

比如，AI 读取了一段被污染的文档，误以为某个地址是官方地址；AI 接收了被构造的任务描述，误以为某个 API 调用是安全步骤；AI 在多轮对话中逐渐被诱导，把一个原本需要人工确认的动作推进成自动执行计划。

这些问题的本质不是 AI 有没有权限，而是 AI 生成的 Intent 本身已经被污染。

因此，在 Havenlon 中，Intent 不能因为“看起来合理”就被信任。系统必须把上下文也纳入执行控制。一个 Intent 是否可以继续，不只取决于它写了什么，也取决于它在什么状态下生成、由谁生成、经过了什么策略、要触发什么结果，以及是否和后续审批及执行对象保持一致。

四、Intent 可以被表达污染

Intent 的另一个风险，是表达本身。

很多系统会把用户或 AI 生成的自然语言描述，转换成结构化操作。比如用户说“帮我处理这笔付款”，AI 或业务系统把它转换成一笔转账；用户说“把这个成员移出去”，系统把它转换成治理变更；用户说“按计划执行部署”，系统把它转换成生产环境操作。

问题在于，自然语言 Intent 本身是模糊的。

它可能省略关键条件，可能包含隐含假设，可能被不同系统解释成不同结果，也可能被 AI 过度补全。用户说的“这个地址”，到底是哪个地址？“小额测试”，金额是多少？“临时授权”，有效期多久？“移除成员”，是否会影响治理阈值？“执行部署”，是否包含数据库迁移、配置变更、密钥调用和回滚策略？

这些如果没有结构化定义，就很容易在 intent 到 execution 的过程中被重新解释。

攻击者可以利用这种表达模糊性，让一个看起来正常的 Intent 被系统解释成高风险动作。AI Agent 也可能在模糊指令中自行补全参数，而补全结果并不符合用户真实预期。

所以 Havenlon 不能把自然语言 Intent 当成执行依据。自然语言可以作为入口，可以作为说明，可以作为辅助交互，但进入执行链之前，必须被转换成明确、可验证、可哈希、可展示、可确认的结构化 Intent。

这个结构化 Intent 必须包含关键执行字段。比如动作类型、目标对象、金额、链 ID、策略版本、设备状态、审批要求、时间窗口、风险标签、执行槽、payload digest 等。只有当 Intent 被结构化以后，系统才有机会验证它和后续 execution 是否一致。

没有结构化的 Intent，只是表达；结构化并被绑定的 Intent，才有资格进入执行控制链。

五、Intent 可以被传输和链路污染

即使 Intent 在源头是正确的，在传输和处理过程中也可能被污染。

一个 Intent 从 App 到 SaaS，从 SaaS 到 Hub，从 Hub 到 Arbiter，从 Arbiter 到 Security，可能经过多个系统边界。在每个边界上，都可能发生替换、裁剪、重放、乱序、延迟、状态错配或版本不一致。

例如，用户发起的是 A Intent，但 SaaS 处理过程中生成了 B 决策；审批者确认的是 A 的摘要，但 Hub 收到的是 A 的变体；Security 模块最终看到的是另一个 payload；或者某个旧 Intent 被重新提交，在新的上下文中触发执行。

这类攻击不一定需要完全攻破系统。攻击者只需要找到某两个环节之间缺少强绑定的位置，就可能让执行链发生偏移。

这就是为什么 Havenlon 需要 IntentHash 和 Step Hash。它们不是为了增加协议复杂度，而是为了在每个步骤中固定“我们到底在处理哪一个 Intent”。

如果没有哈希绑定，系统只能依赖各层之间的口头约定。如果有了 IntentHash，系统就可以验证当前步骤处理的对象是否仍然是最初那个对象。如果有了 Step Hash，系统就可以验证每一步是否按照预期顺序发生，是否存在裁剪、插入或替换。

在对抗性完整视角下，Intent 不仅要被生成，还要被链式保护。否则，一个正确的 Intent 也可能在执行链中变成错误的 execution。

六、Intent 可以被时间污染

时间也是 Intent 的一部分。

一个 Intent 在生成时可能是合理的，但过了一段时间后可能不再合理。策略可能改变，成员可能变化，风险状态可能更新，设备可能进入异常状态，额度窗口可能被消耗，链上环境可能发生变化，外部地址风险可能升级。

如果系统允许旧 Intent 长时间有效，攻击者就可以利用时间差进行重放或延迟执行。

例如，一个审批在上午是合理的，但下午策略已经变化；一个成员在发起时仍然有效，但执行时已经被移除；一个设备在生成 Intent 时在线正常，但执行时证据链已经出现异常；一个小额操作在额度窗口内可以通过，但多个旧 Intent 被集中重放后会突破风险边界。

这类问题说明，Intent 不能脱离时间上下文存在。

Havenlon 需要为 Intent 设置明确的生命周期。它应该有生成时间、有效窗口、策略版本、状态依赖、审批窗口和执行超时机制。超过时间窗口的 Intent，不能继续被当作有效执行依据。状态发生关键变化后，旧 Intent 也应该失效或重新校验。

TimeGuard 这类机制的意义就在这里。它不是单纯防止请求过期，而是防止一个原本在旧上下文中成立的 Intent 被拿到新上下文里继续执行。

对抗性完整要求系统承认：Intent 的可信度会随时间衰减。一个成熟的执行控制系统不能让旧 Intent 无限期漂浮在系统里。

七、Intent 可以被策略错配污染

Intent 是否可执行，必须和策略状态绑定。

但在复杂系统里，策略本身可能变化。SaaS 有策略，本地 Hub 有策略，组织有治理规则，设备有安全状态，执行层有硬件限制。如果这些策略之间没有明确绑定和优先级，就可能出现错配。

例如，SaaS 根据策略版本 V1 判断某个 Intent 可以执行，但 Hub 本地已经更新到 V2，V2 下这个操作应该被拒绝。或者审批流程基于某个成员结构生成，但执行时成员结构已经改变。又或者 AI Agent 根据旧规则生成 Intent，但新的治理规则已经要求更高审批门槛。

攻击者可以利用这种策略错配，在规则更新前生成 Intent，在规则更新后执行；或者利用 SaaS 和本地状态不同步，让系统选择更宽松的一边。

因此，Havenlon 不能只验证 Intent 内容，还要验证 Intent 所绑定的策略版本。

一个可执行 Intent 必须明确：它是在什么策略状态下生成的，在什么策略状态下被审批的，在什么策略状态下进入本地仲裁的，在什么策略状态下被硬件最终确认的。如果策略状态不一致，系统应该重新校验，甚至直接拒绝。

这也是 Havenlon “SaaS 与本地策略并行，取更严格者”这一原则的对抗意义。它不是为了保守而保守，而是为了防止攻击者利用策略层级之间的不一致。

如果 Intent 不绑定策略，它就可能被更宽松的规则污染。如果执行链不验证策略一致性，它就可能在错误规则下被放行。

八、Intent 可以被审批错配污染

在多人治理系统里，Intent 往往需要审批。审批看起来是一道强安全边界，但如果审批和 Intent 没有强绑定，审批本身也会成为污染源。

审批者可能看到的是一个描述，而不是完整 Intent。审批者可能确认的是某个摘要，但最终执行对象发生了变化。审批可能在一个上下文里发生，但执行在另一个上下文里完成。审批结果可能被延迟使用，也可能被拿去匹配另一个相似操作。

这就形成了审批错配。

例如，审批者确认的是“向供应商付款”，但最终 payload 的地址并不是供应商地址。审批者确认的是“小额测试”，但执行金额被替换。审批者确认的是“添加临时成员”，但这个成员获得了长期治理能力。审批者确认的是 AI Agent 的任务描述，但没有看到它将调用哪些真实工具。

这些问题说明，审批不能只是对文字描述的同意，而必须是对结构化 Intent 的确认。

Havenlon 的审批应该绑定 IntentHash，而不是绑定界面描述。审批者确认的内容，必须和后续进入 Hub、Arbiter、Security 的对象保持一致。最终执行时，硬件边界也应该验证审批链和当前 payload 是否一致。

如果审批和 Intent 之间没有强绑定，攻击者就可以让人同意 A，再让系统执行 B。这样日志里会有审批记录，但审批并不能证明执行合法。

对抗性完整要求审批成为执行证据链的一部分，而不是一个独立的流程动作。

九、Intent 可以被 AI 过度补全污染

AI Agent 带来的一个特殊问题，是它会补全 Intent。

人类给 AI 的目标往往是不完整的。用户可能说“帮我完成这个操作”“按之前的流程处理”“把这个事情推进一下”“把这笔款安排了”“把成员权限调整好”。这些说法对人来说依赖上下文，对 AI 来说则需要推理和补全。

AI 补全本身不是坏事，它是 Agent 能力的一部分。但在执行场景里，补全就意味着 AI 正在参与定义 Intent。

它可能补全目标地址，补全金额，补全调用顺序，补全工具选择，补全审批理由，补全风险解释，补全执行时机。这些补全如果错误，就会让 Intent 从一开始就偏离用户真实意图。

更危险的是，AI 的补全通常表现得很自然。它会用合理语言解释自己的选择，让人误以为这是确定事实。用户可能在 AI 的解释下确认一个自己并未真正定义过的执行对象。

所以，在 Havenlon 中，AI 生成或补全的 Intent 必须被标记和约束。系统应该区分哪些字段来自用户明确输入，哪些字段来自 AI 推理，哪些字段来自 SaaS 策略，哪些字段来自设备状态，哪些字段来自外部数据源。

AI 生成的字段不能天然等同于用户授权。对于高风险执行，AI 补全的关键字段必须被显式展示、确认和绑定。否则，系统实际上是在让 AI 参与执行定义，而用户只是被动确认 AI 的解释。

这不是拒绝 AI，而是给 AI 加边界。AI 可以帮助生成 Intent，但不能让 AI 的补全直接变成 execution。

十、Intent 被污染后的正确处理方式不是修饰，而是阻断

很多系统面对不确定的 Intent，会尝试继续处理。比如信息不完整就自动补全，状态不一致就选择最近状态，审批描述不清楚就让用户大概确认，策略冲突就选择更方便的一边，时间超期就允许重新提交，证据缺失就先执行后补日志。

这些做法在普通业务系统里也许能提升体验，但在执行控制系统里非常危险。

因为 Intent 一旦存在污染迹象，继续推进就可能把污染传递到 execution。

Havenlon 对 Intent 污染的处理方式应该更接近安全系统，而不是普通工作流系统。也就是说，当系统无法确认 Intent 的来源、内容、上下文、策略版本、审批绑定、时间窗口或 payload 一致性时，正确动作不是继续猜，而是拒绝、降级、重新确认或进入 Safe Mode。

这也是对抗性完整与用户体验之间天然存在张力的地方。执行控制系统不能永远追求顺滑。有些时候，系统必须反直觉，必须显得冷硬，必须拒绝用户以为“很正常”的操作。

因为 Havenlon 要保护的不是流程顺畅，而是错误动作不能发生。

如果 Intent 已经被污染，最危险的不是污染本身，而是系统仍然把它当成干净输入继续执行。

十一、从 Intent 污染重新理解 Execution Control

把 Intent 视为可污染对象之后，Havenlon 的执行控制模型就更加清晰了。

SaaS 的作用不是把 Intent 直接变成执行，而是参与策略判断和协同治理。

Hub 的作用不是盲目接收 Intent，而是进行本地仲裁、状态验证和边界检查。

Auth Key 和 Pass Key 的作用不是简单确认按钮，而是把身份、授权和真实 Intent 绑定起来。

硬件执行层的作用不是看到 payload 就签名，而是在最终边界验证当前 payload 是否仍然属于被允许的 Intent。

证据链的作用不是事后写日志，而是证明这个 Intent 如何被提出、如何被判断、如何被确认、如何被执行或拒绝。

这些设计共同回答一个问题：一个可能被污染的 Intent，如何在进入真实执行之前，被层层验证和约束？

这就是 Havenlon 对抗性完整中非常核心的一环。我们不是假设 Intent 干净，而是默认它可能被污染。我们不是相信某个层级能完全理解 Intent，而是让每一层都只能在受限范围内处理 Intent。我们不是让 Intent 自动流向 execution，而是在它们之间建立不可绕过的执行控制链。

十二、结语：Intent 只能进入执行链，不能替代执行链

在真实世界里，很多危险执行并不是因为系统完全被攻破，而是因为系统过早相信了某个 Intent。

它相信账号发起的请求就是用户真实意图，相信 AI 生成的计划就是合理执行方案，相信 SaaS 的判断就是最终授权，相信审批者点了同意就代表理解全部后果，相信自然语言描述足以代表结构化 payload，相信旧 Intent 在新状态下仍然有效。

这些信任在对抗环境中都可能失效。

所以 Havenlon 必须坚持：Intent 可以进入执行链，但不能替代执行链。

一个 Intent 只有经过来源验证、结构化表达、策略绑定、审批绑定、时间约束、本地仲裁、硬件确认和证据链记录之后，才有资格接近 Execution。即使如此，最终执行层仍然必须保留拒绝能力。

这就是对抗性完整的第四条原则：

Intent 可以被污染，所以 Intent 不能等于执行。

从这个原则出发，Havenlon 的执行控制不再是简单的“用户提出请求，系统完成操作”，而是一个面向敌意环境的过滤、绑定、验证和拒绝机制。它承认意图本身不可靠，承认上下文会被污染，承认 AI 会补全错误，承认审批会错配，承认策略会不一致，承认时间会改变风险。

正因为如此，Havenlon 才需要在 Intent 和 Execution 之间建立一层真正的执行控制边界。

这层边界的价值，不是让系统更复杂，而是让错误意图不能轻易变成真实后果。