摘要：
如今所有主流编程智能体平台均已支持钩子机制，但其意义远不止于终端智能体。钩子技术正引领行业朝着运行时安全架构模式的方向加速融合
整个智能体 AI 生态系统正在发生重要变化，这一趋势很可能在保障未来智能体安全方面发挥关键作用。
过去几个月，所有主流编程智能体平台都不约而同地采用了相同的运行时安全执行架构模式。它们将其称为"钩子"。领先平台如 Claude Code、Cursor、Windsurf、Cline、GitHub Copilot 和 OpenClaw 都采用了这种模式。
这一概念不仅受到商业界的追捧，也获得了研究界的认同，例如论文《可信智能体 AI 需要确定性架构边界》就阐述了相关理念。该论文揭示了智能体及其核心 LLMs 的根本缺陷，特别是在当前流行的"致命三重奏"概念背景下，并提出了确定性边界作为风险缓解机制。
这种趋同现象并非偶然。它反映出业界日益认识到：智能体循环本身需要确定性的执行点，在每次行动执行前进行拦截，并根据策略进行评估。
但这种模式并不局限于编码智能体。我所在的 Zenity 团队最近宣布，为基于 Microsoft Foundry 构建的智能体提供内联运行时安全功能的正式发布，将相同的拦截与执行模型应用于 SaaS 和企业自研智能体。
当编码智能体生态系统与企业智能体安全市场都汇聚于同一架构原则时，其信号意义不言而喻。内联运行时执行正成为各类部署模式下智能体 AI 安全的基础层。
数月来，我一直在撰文探讨智能体 AI 安全中硬性边界与运行时执行的必要性。在分析 Claude Code 自动模式时，我深入探讨了基于概率的 AI 安全分类器与安全从业者信赖的确定性控制之间的张力。Anthropic 通过下图清晰展示了其提供的各模式（包括最新推出的自动模式）的权衡关系。
许多人认识到，诸如钩子这样的架构控制是缓解智能体 AI 风险的有效方法，而行业采纳这一方案的速度远超大多数人的想象。
钩子究竟是什么
在最基础的层面上，钩子(hook)是智能体执行循环中的一个程序化拦截点。当智能体即将执行某个操作时——例如运行 shell 命令、写入文件、发起 API 调用或读取敏感数据——钩子会在该操作执行前触发。钩子会接收关于智能体即将执行操作的上下文信息，根据一组规则或策略对其进行评估，并返回决策：允许、拒绝或修改。若钩子拒绝该操作，智能体将无法继续执行。该操作在触及实际环境之前就会被阻断。
这与大多数智能体平台最初采用的权限提示模型有着根本区别，后者需要人工用户逐一批准或拒绝每个操作。正如 Anthropic 自身数据显示，用户对 93%的权限提示选择批准，经验丰富的用户更有超过 40%的情况会转为自动批准。这种人工介入机制并未发挥实质性的安全控制作用——我在《人工介入的幻象》一文中已探讨过这一问题。而钩子机制通过程序化执行方案取而代之，不再依赖于人工关注度。
钩子模式通常在智能体循环的两个关键节点发挥作用。工具调用前钩子在工具调用执行前触发，使执行层能够在危险操作发生前予以拦截。工具调用后钩子在工具调用完成后触发，支持日志记录、审计追踪及异常结果检测功能。
部分平台支持额外的钩子点，用于处理会话开始、子代理委派、错误处理和通知触发等事件。但 PreToolUse 才是对安全至关重要的执行机制，因为这是能够预防危害发生的关键节点，而非仅仅在事后进行检测。
Claude Code 的实现具有启发性，其钩子支持三种处理器类型。命令钩子通过运行 Shell 脚本来接收通过标准输入传入的 JSON 上下文，并通过退出码返回决策结果。提示钩子将操作上下文发送给 Claude 模型进行单轮评估，而代理钩子则会启动具有工具访问权限的子代理以进行深度验证。关键在于，Claude Code 采用递归方式执行钩子——这意味着当代理启动子代理时，子代理的每次工具调用同样会触发钩子检查。若缺乏递归执行机制，子代理将可能完全绕过安全关卡。
以下是来自 Cursor 的一个示例，展示了这些功能的使用位置与方式：
GitHub Copilot 的编码代理已在公开预览版中支持钩子功能，包含 userPromptSubmitted、preToolUse、postToolUse 和 errorOccurred 等事件。Windsurf 的 Cascade 将钩子作为前置与后置动作触发器。Cline 则提供钩子功能，允许将代理视为工具链中的另一项服务。所有实现均遵循一致的"拦截、评估、执行"模式。
为何声明式策略语言至关重要
钩子提供了拦截机制，但钩子执行何种策略的问题同样至关重要。这正是像 Cedar 这样的声明式策略语言发挥作用之处，也是我认为它们代表着我们在思考智能体治理方式上的关键演进。
Cedar 是由 AWS 创建的一种策略语言，专为细粒度授权决策而设计。它是声明式的，这意味着您可以通过策略语句来表达允许或禁止的内容，而不是编写按流程做出这些决策的命令式代码，这种区别之所以重要，有几个原因。
首先，声明式策略是可审计的。一条 Cedar 策略如“当 resource.command 包含 ‘rm -rf’ 时禁止执行操作”，安全团队、合规审计员和治理评审员无需理解底层代码即可阅读。这对于需要审查、批准和记录安全策略的企业环境至关重要。
以下示例来自 Sondera 和 Matt Maisel 的博客文章《用 Cedar 策略语言钩住编码代理》，这是我迄今为止在该主题上看到的最佳示例之一。
其次，声明式策略可在不同智能体平台间移植。Sondera 通过其参考监控器实现展示了这一点：该实现将 Claude、Cursor、Copilot 和 Gemini 等平台特有的工具名称映射为通用类型，使得 Cedar 策略规则能在所有四种智能体平台上完全一致地运行。这种可复用性实现了"一次编写策略，处处执行管控"的模式。Sondera 的 Matt Maisel 在今年三月的[un]prompted 大会上，就这一理念发表了题为《用 Cedar 策略语言钩住编程智能体》的精彩演讲。
第三，声明式策略将策略与代码分离，这是良好安全架构的基本原则。当策略内嵌于应用程序代码时，任何修改都需要经历代码变更、测试和部署周期。
当策略被外部化为声明式语言时，它们可以独立于智能体或应用程序代码进行更新、版本控制和部署。Phil Windley 在基于 Cedar 和 OpenClaw 的策略感知智能体循环方面的研究，在实践中展示了这种模式，说明了每个工具调用如何在运行时通过 Cedar 支持的政策决策点进行评估。
授权不再只是边缘的一次性关卡，而是转变为持续反馈信号，引导重新规划并在智能体执行全过程中贯彻零信任原则。下图来自 Phil 的博客，有助于展示具备策略感知的智能体循环，并说明 Cedar 策略评估如何嵌入智能体的执行循环——介于行动提议与行动执行之间。
这很重要，因为当前大多数环境采用的替代方案正是如此：JSON 配置文件中的硬编码允许列表和拒绝列表、检查特定模式的自定义 Shell 脚本，以及因团队和工具而异的临时规则。这种方法无法扩展，无法提供一致的执行，也无法为安全负责人提供所需的治理和审计能力。
引用监控器模式
引用监控器的概念并不新鲜。它源于经典计算机安全领域，描述了一种必须满足三个标准的执行机制。首先，它必须始终被调用，意味着每个操作都会被无一例外地拦截。其次，它必须防篡改，即主体无法修改监控器或其策略。第三，它必须可验证，即执行逻辑必须简单、确定且可审计。
最近的学术研究已正式将这一模式直接应用于智能体 AI 领域。"安全智能体系统策略编译器"（PCAS）实现了一个参考监视器，可在执行前拦截所有智能体行为并阻断策略违规。PCAS 将智能体系统状态建模为依赖关系图，采用基于 Datalog 衍生的语言表达授权策略，并将智能体实现与策略规范编译成通过构造即符合策略的插桩系统。
他们的结果很有说服力。在包括 Claude Opus 4.5、GPT-5.2 和 Gemini 3 Pro 在内的前沿模型中，未经监测的智能体仅实现了 48%的策略合规率。而部署参考监控器后，这一比例跃升至 93%，且在监测运行中实现了零违规。结论很明确：不能依赖模型自主遵守规则，需要一个无需征得模型同意的外部执行层。
这种界定至关重要，因为它清晰区分了作为安全执行机制的钩子与某些平台用作安全控制的基于概率的 AI 分类器。评估某个操作是否"看起来安全"的 AI 分类器无法满足可验证性标准，其本质是非确定性的。而通过显式规则评估结构化授权请求的声明式策略引擎，则完全符合所有三项标准。正是参考监控器模式，将钩子从便捷的自动化功能转变为基于长期网络安全原则与概念的真正安全边界。
微软近期发布的 Agent Governance Toolkit 进一步强化了这一模式。其 Agent OS 组件作为无状态策略引擎，能够在亚毫秒级延迟内拦截每个智能体执行前的操作。该工具通过接入 LangChain、CrewAI、Google ADK 及微软自有智能体框架的原生扩展点，在不重写智能体代码的前提下实现统一治理。该工具包全面覆盖 OWASP 智能体 AI 十大安全风险，并支持 Python、TypeScript、Rust、Go 及.NET 多语言环境。
我们看到微软、Anthropic、GitHub、初创企业以及学术研究者等业界领导者，都在向相同的架构模式靠拢。
超越终端代理——面向 SaaS 与自定义代理的内联执行
我还想强调，这种能力不仅限于终端编码代理——当前行业讨论大多聚焦于此。截至目前我所描述的钩子实现主要针对终端编码代理设计。
Claude Code、Cursor、Windsurf、Cline 和 GitHub Copilot 都是运行在开发者机器或 CI/CD 环境中的工具。这些场景下的钩子会拦截开发工作流中的 shell 命令、文件写入和工具调用。这固然重要，但就代理的常见部署场景而言，这只解决了智能体 AI 安全问题的三分之一。
正如我在多篇文章中详述的，企业需要防护的代理部署模式主要有三种：终端代理是第一种；内嵌于企业 SaaS 平台的 SaaS/嵌入式代理是第二种；组织内部构建的自研/自定义代理是第三种（通常部署在云托管环境中）。钩子模式需要覆盖所有这三种场景，而我们已经开始看到这样的趋势。
并非自我宣传，但我的团队 Zenity 近期也为 Microsoft Foundry 智能体推出了内联运行时安全方案。这展现了此类技术如何超越代码智能体领域，覆盖更多智能体部署模式。Zenity 原生集成于 Microsoft Foundry 的智能体执行链路中，实时拦截智能体行为，在数据流转或工具执行前阻断不安全操作。
这正是 Claude Code 和 Cursor 为编码智能体实现的相同 PreToolUse 执行模式，只不过现在被应用于连接 SharePoint、OneDrive、数据库、SaaS 平台及内部 API 的企业级智能体。
这些并非在开发者笔记本电脑上运行 shell 命令的编程助手，而是由微软 Foundry 平台的专业开发者和 Copilot Studio 的公民开发者共同构建的业务智能体。它们活跃于 IT 运维、客户支持、金融、医疗、制造及公共部门等多个领域。
它们在企业环境中做出决策、串联操作并调用工具，同时引入了传统提示层级或事后执行控制机制从未设计应对的风险类别。与在编码智能体中采用内联执行机制类似，这种方案能有效缓解敏感数据泄露、密钥暴露、越狱尝试及工具滥用等风险，其保护范围覆盖串联操作链而非孤立的提示指令。
对于微软生态系统之外的自建和定制化智能体而言，这一模式同样至关重要。使用 LangChain、LangGraph、CrewAI 或 OpenAI Agents SDK 等框架构建智能体的组织，需要将策略执行机制直接嵌入到智能体运行循环中。
微软的 Agent Governance Toolkit 提供了一种路径，通过接入框架原生扩展点来实施治理，无需重写智能体代码。Phil Windley 在 Cedar 和 OpenClaw 上的研究则提供了另一种方案，展示了如何将声明式策略评估作为持续授权机制嵌入智能体运行循环。
OpenClaw 项目现已支持工具使用前后的钩子功能，能够在执行特定操作时暂停并请求人工审批，将程序化执行与必要的人工监督有机结合。
那些仅将钩子视为终端编码代理相关技术的组织，正重蹈当年仅从 IaaS 角度考虑云安全的覆辙。
代理的应用范围覆盖全部三种部署模式，相应的执行机制也需同步延伸。编码代理生态已具备钩子机制，这正逐渐成为行业讨论的关键议题。
如今，微软 Foundry 等企业平台也已实现内联执行机制。在保障智能代理安全与风险防控领域，我们看到这种机制正成为生态引领者采用的主流范式。
这对安全领导者意味着什么
整个智能体 AI 生态系统在钩子和内联执行机制上的趋同，向安全负责人揭示了几个重要事实。
首先，业界已普遍认识到，将人工介入审批作为主要安全机制是行不通的——这一议题我已撰文深入探讨过。所有实施钩子机制的平台都经历了同样的困境：当人工审批流程沦为橡皮图章或被完全规避时，要求用户批准每个操作的传统方案在实践中宣告失败。钩子技术正是行业对这一失效机制的回应，它将执行控制从人力转移至基础设施层面。
其次，像 Cedar（或其他如 OPA 等）这样的声明式策略语言提供了治理层，使钩子能够在规模化运营中切实可行。对于小型团队而言，硬编码在 JSON 文件中的规则尚可应付。但对于拥有数百或数千名开发者、数十种代理工具，且对策略文档和审计追踪有合规要求的企业来说，这种方式则行不通。在企业级规模下，策略与代码的分离并非可选项，而是必须遵循的原则。
第三，钩子模式直接映射到我一直在倡导的、也是领先的智能体 AI 安全平台普遍采用的 AISPM 和 AIDR 能力。AISPM 定义策略、信任边界和态势配置。AIDR 在运行时执行这些策略并检测违规行为。钩子和内联执行机制正是连接这两者的桥梁。它们是将安全态势转化为实际防护的运行时执行点。
第四，这种模式需要覆盖所有三种部署环境。防止编码代理在生产服务器上执行 `rm -rf` 的同一套执行架构，也需要防止定制构建的代理通过链式工具调用泄露敏感客户数据，以及防止 SaaS 嵌入式代理超越其授权操作范围。
我们讨论了不同部署场景下的几个领先示例。策略语言可能有所不同，但架构原则是相同的：拦截每个操作，根据策略进行评估，在执行前强制执行。
钩子也并非万无一失
在本文听起来像是钩子是解决智能体 AI 安全问题的万能钥匙之前，我想直言不讳地指出：它们并非如此。与任何安全控制措施一样，钩子存在实际的局限性、已知的绕过途径以及实践者必须理解的失效模式。
相关研究已堆积如山。2026 年 2 月，Check Point Research 披露了 Claude Code 中的关键漏洞（CVE-2025-59536 与 CVE-2026-21852），这些漏洞使钩子从防御机制转变为攻击载体。攻击者只需在代码库的.claude/settings.json 文件中注入恶意钩子定义，就能在开发者克隆并打开项目的瞬间实现远程代码执行。
钩子命令在用户看到信任对话框之前就已运行。另一项发现表明，仓库控制的配置设置能够覆盖安全防护措施并自动批准所有 MCP 服务器，从而在启动时无需任何用户确认即可触发执行。
2026 年 3 月，Adversa AI 披露了另一项漏洞：当 Shell 命令包含超过 50 个子命令时，Claude Code 会静默忽略所有用户配置的拒绝规则。
根本原因在于引入了一个硬性上限(MAX_SUBCOMMANDS_FOR_SECURITY_CHECK = 50)，以避免复合命令安全分析期间的界面冻结。当命令超过该阈值时，Claude Code 会完全跳过所有针对子命令的拒绝规则执行，并回退到一个可能被自动允许的通用提示。实际攻击手法非常直接。
公共仓库中的恶意 CLAUDE.md 文件可以构造出足够复杂的复合命令，绕过开发者配置的所有拒绝规则，导致 SSH 密钥、云服务凭证和发布令牌全部面临风险。修复方案其实早已存在于同一代码库的新版解析器中，只是从未向用户部署。
这些并非理论上的担忧。它们是已披露的 CVE 漏洞、已发表的研究成果，以及针对市场上最知名的智能编码工具之一实际生效的绕过攻击向量。
除了实现层面的缺陷，架构上的局限性也值得关注。钩子作用于智能体发起的工具调用，但无法管控其内部推理过程、规划逻辑或未外显的决策。
遭受提示注入攻击的智能体可能永远不会发出触发钩子的工具调用。它可能转而寻找替代路径，将受限制的操作分解为多个单独允许的子操作，或直接提供具有误导性的意图说明。钩子在操作边界而非推理边界执行策略，这一差异至关重要。
另一个有趣(且令人不安)的例子来自 OffSec 公司 Praetorian 的 CEO Nathan Sportsman。他展示了其智能体如何通过自我描述的“利用”钩子机制绕过控制，直接钻了它发现的规则漏洞。
再次强调，钩子并非万能解药，智能体具有高度不可预测性，且会不遗余力地追逐其目标。
还存在配置问题。钩子的有效性完全取决于其背后的策略。一条配置错误的规则、一份不完整的拒绝列表，或是一个过于宽松的默认设置，都可能营造出一种虚假的安全感——这可以说比完全没有钩子更糟糕。
EQTY Lab 的 Cupcake 等项目基于 OPA/Rego 构建，并得到 Trail of Bits 的智能体安全研究支持，正致力于通过将 DevSecOps 领域的"治理即代码"实践引入智能体安全领域，使策略编写更加严谨。但策略的完备性仍然是一个悬而未决的挑战。
这绝不意味着钩子不值得实施。而是意味着我们需要正确理解它们的定位：它们是智能体 AI 安全纵深防御策略中的一层，而非全部策略。
我之前讨论的参考监视器模式提供了架构基础。钩子则是实现该模式的具体机制。但正如防火墙、终端检测与响应系统以及过去三十年间行业部署的所有其他安全控制措施一样，钩子机制也将面临被绕过、配置错误和遭受攻击的挑战。
目标并非追求完美。目标在于提高攻击的成本与复杂性，同时保持必要的可见性与审计追踪能力，以侦测突破防线的行为。这正是纵深防御一贯的核心意义，而智能体 AI 也无法从这一现实法则中获得特殊豁免。
核心要点
钩子和内联执行机制不仅仅是开发者的便利功能。它们正逐渐成为智能体 AI 运行时安全的架构基石。从各大主流编程智能体平台、企业级智能体安全供应商到框架级工具包，都已不约而同地采用这种模式——这足以说明它并非昙花一现的技术潮流。
它正在演变为一种结构性需求。无论是运行在开发者设备上编写代码、在企业应用中处理客户记录，还是在 SaaS 平台内执行工作流，凡是需要与现实世界交互的智能体，都必须在执行节点配备确定性的、策略驱动的执行机制。
那些围绕这一模式构建其智能体 AI 安全策略的组织，将凭借声明式策略、跨平台执行能力以及覆盖全部三种部署类型的防护体系，成为真正具备安全护栏并实现规模化部署智能体的先行者。
那些依赖权限提示并寄希望于最终能发现无边界环境中无监督代理行为后果的，终将明白其局限性。不过，正如我上文所指出的，钩子(hooks)仅是保障智能代理安全的纵深防御策略中的一环。
原文链接：
https://www.resilientcyber.io/p/a-look-at-an-emerging-runtime-enforcement
声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
