在 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 本地已经更新到 V2V2 下这个操作应该被拒绝。或者审批流程基于某个成员结构生成但执行时成员结构已经改变。又或者 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 之间建立一层真正的执行控制边界。这层边界的价值不是让系统更复杂而是让错误意图不能轻易变成真实后果。