《玄枢体系化建设的阶段性成果与思考--续集》

玄枢
玄枢

玄枢战队-Arcane Hub

2026年10月31日 21:40
陕西

去阅读

《玄枢体系化建设的阶段性成果与思考》

玄枢，公众号：玄枢战队-Arcane Hub《从“科研”里的安全，到“实践”里的安全——玄枢体系化建设的阶段性成果与思考》

书接上回，智能体的出现让token用的越来越快，人用起来也越来越爽。顺着上期的《玄御》产品进一步拓展思考，作为网络空间安全学院、密码学院的“交叉领域专家”，有全生命周期的AI Agent安全检测与防御，更需要探索细粒度的AI Agent数据安全边界，谈及数据安全就离不开密码学，尤其是在国产模型，开源智能体框架及闭源商用智能体蓬勃发展的当下，国密算法的适配性改造与性能优化，或许是智能体可信落地的关键一环。

一、玄御：让智能体的每一步行动，都有任务依据

从资产与能力基线，到任务授权、执行控制与证据复核，构建面向 AI Agent 的安全治理体系。

当 AI 开始操作文件、调用接口、执行命令、委派子任务，安全检查就需要贯穿从信息进入到动作落地的全过程。模型接收了什么、工具具备什么能力、用户允许做什么、最终发生了什么，必须能够相互核对。

01｜建立安全基线，先看清智能体究竟具备什么能力

一个智能体的能力分散在多个地方，部署配置声明了可访问的资源，Skill 描述了工作流程，MCP 工具向模型暴露了接口，处理函数决定了接口真正能够执行的操作，运行记录则留下了已经发生的行为。这些描述可能并不一致。

例如，一个名为“会议纪要整理”的 Skill，声明的权限只有知识读取，正文中却夹带读取敏感配置的要求；一个介绍为查询用途的接口，其实现可能同时包含文件写入或网络访问。仅看名称、说明或一张工具清单，难以判断它在业务中会产生怎样的影响。团队之前对公开的SKILL仓库进行披露面测量，提出一种HPWAR五维的披露面测量框架，发现公开SKILL普遍存在控制面与权限的披露不足情况。

玄御的资产治理思路，是把Agent、模型、Skill、MCP 服务、工具、依赖与业务资源组织成有关联、有来源的资产图谱，再从两个维度还原能力事实。

首先，分别记录资产的“存在、配置、加载、活跃、观察”状态及对应证据。一个组件安装在环境中，被系统实际加载，以及已经参与工具调用，对应着不同的事实和管理优先级。其次，交叉比较五种能力：声明了什么、向模型展示了什么、流程要求做什么、代码实现了什么、运行中观察到了什么。能力之间的差异，可以指向隐藏功能、技能越权、接口描述与实现不一致，或运行行为发生偏移。

这一步的价值，是为后续控制建立依据。发现某个工具可以读写文件之后，还需要知道它属于哪个智能体、访问哪些目录、由哪段实现提供能力，以及这些事实如何影响调用策略。围绕这一基础，玄御将整体架构组织为三个相互衔接的平面：

三者沿同一条业务链路工作：资产与能力基线 → 任务授权 → 调用前核验 → 执行与结果治理 → 证据复核。

02｜把用户的任务，变成执行时能够核验的约束

工具具备某种能力，只能说明系统有条件执行相应操作。一次具体调用能否发生，还取决于当前任务的授权。玄御采用的任务治理机制，将经过身份确认的用户要求组织为任务语义图，保留动作、资源、前置条件、禁止事项及原文依据，再编译为带版本的任务权限合同。这里的“合同”是一份供系统核验的结构化约束，描述谁可以对什么资源执行什么操作，以及需要满足哪些条件。当智能体提出候选工具调用时，系统结合工具画像和完整参数，解析这次调用真正涉及的读取、写入、删除、网络访问、命令执行或委派行为，再逐项核对授权。

这种核验深入到参数与执行效果。例如，一个网络请求虽然使用“读取”接口，但查询参数中携带了敏感配置值，它仍然具有数据外发效果；一条命令虽然以目录切换开头，后续重定向仍可能产生文件写入。判断必须覆盖完整动作及其目标。

多轮对话也会改变任务。用户补充要求、修改目标、撤回授权或批准方案后，系统更新有效权限及版本，让后续动作依据当前要求重新核验。已经形成的执行事实则保留在历史记录中。在这一过程中，外部文档、工具返回和长期记忆始终保留各自的来源身份。它们可以提供业务信息，新的执行权限则需要有可信任务依据。

任务授权由此成为连接自然语言与真实执行的中间层：既保留用户要求的含义，也能落到工具、参数、资源和条件上。

03｜让安全判断在工具执行之前生效

对提示注入的识别，是这条链路的重要入口。系统对用户输入、外部资料、工具描述、工具返回和记忆内容开展检查，通过字符规范化、编码还原、跨片段关联，以及规则、分类模型和受控语义分析，定位可疑指令及其来源。这些内容风险信号，与任务授权共同进入执行决策。最终动作分为放行、请求确认和阻断三类，并通过接入执行器的控制环节落实。这里有三个直接影响实际防护效果的技术设计。

第一，审批绑定具体动作。

审批关联执行主体、工具、完整参数、目标资源，以及任务合同和策略版本。审批后如果目标地址、文件路径或正文改变，系统重新核验。用户对一个动作的确认，因而能够对应到随后真正准备执行的内容。

第二，执行许可随调用一起核验。

通过裁决的动作获得短期、一次性的执行许可。许可携带参数摘要、有效期和唯一标识，并使用 HMAC-SHA256 认证。执行入口根据实际参数复核许可，持久化登记唯一消费，再调用真实工具。这一机制将安全判断与执行对象绑定，并约束旧许可重复使用。

第三，结果根据实际产物与回执确认。

工具是否完成操作、产生了什么文件、是否收到业务回执，进入结果记录；结果内容能否继续提供给模型，则经过相应治理。出现超时或状态不确定时，系统保留执行状态，并通过产物或回执进一步核对。

04｜把委派和记忆纳入同一套权限秩序

智能体的工作往往跨越多个轮次，甚至多个会话。主智能体把检索、分析或执行交给子智能体，长期记忆又把过去的信息带入下一次任务。权限和来源需要跟随这些过程持续传递。在委派机制中，子任务的权限由父任务当前授权、明确委派范围和角色上限共同约束。父级授权收紧后，后续子任务动作重新核验；主任务确认执行结果时，关联子任务的许可消费、真实执行和结果回执。

在记忆治理中，正文之外还保存来源、租户与项目范围、版本、摘要、敏感标签及派生关系。写入时关联实际动作和回执，召回时检查作用域与治理状态。某条记录被隔离或撤销后，相关派生记录的后续使用资格随之调整，同时保留原有事实和治理记录。这使一次发现能够影响后续使用：被识别的问题内容，可以在下一次召回或派生任务中继续受到约束。跨会话协作也因此有了可持续维护的依据。

05｜实验验证

在包含14 项服务的容器化真实场景中，识别出100 个资产、305 条资产关系和 91 项静态风险，并与预先封存的人工真值逐项比对。该集合中的资产与静态风险均完成匹配。把分散在配置、源码、工具定义与运行信息中的对象关联起来，为风险定位和策略制定提供可复核的环境依据。

同时，对1,054 条 InjecAgent 攻击样本开展静态内容识别，检出1,009 条，约 95.73%，另有 45 条未被内容层识别。在另一组执行前对齐测试中，向系统提供可信任务参考约束与候选工具调用，1,054 个攻击案例均受到阻断，与工具类型匹配的 1,054 个良性控制均获放行。

两组结果呈现了内容识别与行为约束的互补关系：即使攻击文字未被识别，实际调用仍可依据任务范围、资源和参数接受核验。这也是玄御同时保留内容检测与执行控制的技术依据。

然后，在真实部署的 OpsPilot、Langflow 与 MCP 服务上，使用模型 Stub 回放预设工具调用轨迹。在5,200 条请求中，80 条恶意请求均检出并实际阻断，5,120 条良性请求均完成预期业务。在接入 OpenHands SDK、业务模型和自建 MCP 工具服务的场景中，覆盖36 个用例、43 个业务阶段。按各用例最近一次复验记录，15 个正常业务及良性对照用例完成规定业务核验，21 个攻击类用例完成攻击触达、安全处置与禁止副作用核验。

这些场景包含资料阅读、多源审查、批准写入、测试报告、主子任务协作与跨会话记忆。业务完成由真实读取、文件产物和业务记录确认，攻击影响由来源、处置与资源变化核对。

06｜让安全能力进入研发、运行和复盘的日常流程

对于研发团队，玄御的价值首先体现在接入和变更阶段。新增 Skill、MCP 服务或工具时，可以检查它声明、请求和实现的能力是否一致，定位新增资源访问与依赖关系，并将这些事实用于后续策略。安全问题能够对应到具体组件、实现和版本。

对于业务运营，价值体现在任务执行期间。读取资料、修改文件、提交内容和对外发送，可以依据不同的任务要求分别处理；需要确认的动作关联具体对象与参数。团队由此能够为智能体划定清晰、可更新的工作范围，并让经过授权的业务继续推进。

对于安全与审计人员，价值体现在事件复盘。通过请求时间线、来源关系、策略决策、调用记录及实际回执，可以追查一段外部内容如何影响了候选动作，哪条规则参与判断，以及处置后资源是否发生变化。证据摘要校验与工件版本关联，为复核提供进一步依据。

这些能力最终汇合到一个业务目标：让企业能够说明，智能体为何执行这一步、依据来自哪里，以及执行结果如何得到确认。

二、把国密保护接进智能体业务的实践与思考

当前无论是开源智能体框架LangChain、LangGraph、AutoGen和MCP SDK；亦或者商业智能体产品Qoder、CodeBuddy Code和Deepseek Harness等，对于国密似乎都没有做适配以及垂直向的优化。对于熟悉开发的人员来说，这个难度并不高，但对于涉及到自建垂直领域智能体的单位来说，国产密码算法支持下的开源与闭源适配性改造与优化是个交叉领域的复杂过程。基于此，我们在5月份就尝试开发了一套基于国密体系的，易迁移、低侵入的国密智能体保护框架，在后来的时间看到更多国产商用产品的诞生，在此之上做了进一步优化和适配增强。具体来说。

GM-AgentGuard 是一种面向异构智能体的可迁移国密业务数据保护方案。我们希望通过框架扩展点、外置代理和产品 Hook，把业务授权、密码保护与模型可见数据控制接入实际调用，在保护数据的同时，让任务继续完成，同时降低使用者的重复开发与适配的过程，优化国密参与后的性能。

目前，开源框架侧已经有 LangGraph、LangChain、AutoGen 及 MCP SDK 的运行证据；产品侧已经接入 Qoder CLI、DeepSeek Harness 和 CodeBuddy Code。这项工作的优势在于低侵入接入、保护能力复用，以及安全效果和业务结果可以同时检查。下面想结合这些实践，讲清楚我们做了什么，以及为什么这样做。

01 先把问题放回业务里

实验中有一笔合成订单，因为重复支付回调，被重复计入账本。智能体需要读取订单和诊断日志，检查代码，生成补丁，执行测试，最后创建处理工单。正确的账本合计是15500 分。这类任务有一个好处：结果能被检查。补丁是否生效、金额是否正确、工单是否落地，都有具体依据。同时，问题也藏在这个普通流程里。订单结果可能把客户姓名、完整账号和身份号码一起返回；智能体修复计算逻辑，需要金额、事件编号和业务状态，却未必需要这些身份原文。模型也可能请求读取另一个任务的材料，或把结果发往当前任务没有授权的目的地。

我们逐渐把问题拆清楚了：业务授权决定请求能不能执行，密码保护负责已接入边界上的报文安全，数据可见性控制决定模型最后可以看到什么。这三件事应当在同一次业务调用里配合起来。保护要跟得上任务的执行，也要保留工具完成业务所需的事实。

02 围绕一次调用，把保护组织成一个框架

GM-AgentGuard 的设计，首先考虑的是接入位置。使用开源框架开发应用，可以利用节点包装、回调、工具和状态等扩展点。使用现成智能体产品，则更多依赖它公开的 MCP、Hook 等接口。两种情况下能控制的边界不同，接入方式也应有所区别。因此，我们把框架组织为接入适配、业务策略、国密封装和执行证据几个相互配合的部分，让接入层承担差异，让保护机制尽量复用。

接入层，让保护能够随应用迁移

框架侧的适配器把节点、工具和状态边界交给保护逻辑处理；产品侧的网关则发现原 MCP 工具的名称和结构，把调用转交给接收代理。验证通过后，原业务服务仍接收自身定义的参数，执行原来的函数。

这种设计带来的直接好处是，保护可以通过公开扩展接口与外部组件接入。已验证的接入没有修改相关开源框架源码；CodeBuddy 的官方入口包核对了3549 个文件，修改数为 0。切换产品时，可以继续复用已经配置的网关和策略。

业务服务也有独立迁移检查。另一组 FastMCP 发票服务没有导入 GM-AgentGuard，通过上游配置和字段策略接入后，三种模式都得到4600 分的正确结果，服务源码保持不变。

这使“可迁移”有了两端的证据：既能切换智能体客户端，也能接入另一组业务工具。

策略层，把权限与数据范围交给可信配置

工具参数是模型生成的，但授权来自当前任务的可信配置。模型把参数改成另一个任务编号，不会因此获得访问权；把目的地改成外部地址，也不能自行扩展授权范围。在返回路径上，策略继续处理模型可见的数据：任务需要的金额、状态、事件关系应当保留，不必要的敏感原文则按配置进行最小化或引用替换。

密码层，让保护与调用上下文绑定

Full 模式为网关与接收代理之间的请求和响应增加国密封装。SM4 保护载荷，SM2 用于数据密钥包裹和签名，SM3 用于摘要计算并参与完整性验证。封装绑定任务、工具、请求编号、策略摘要和结构约束。接收端在执行业务前验证签名和上下文，检查持久化重放记录，再复核业务权限。返回结果沿受保护路径回传，由网关验证并处理模型可见字段。

核心是密码在这条调用链中，报文不能被直接读出，修改能够被发现，重复发送受到约束，有效签名也不能替代业务授权。

03 从开源框架，走到开源与商用智能体应用

我们最初在能够控制执行边界的框架中验证保护，再把同样的目标带到真实产品中。

在开源框架侧，运行时和协作边界已经实际接通。LangGraph 使用真实 StateGraph 和 checkpoint；LangChain 使用真实提示模板与 Runnable 流水线；AutoGen 使用真实 Swarm、AssistantAgent、工具调用和交接；MCP SDK 使用真实 ClientSession 与 FastMCP 服务端。

保护能够进入真实框架运行时，并在这些已测试路径上保持任务和工具功能。

在现成产品侧，真实模型、工具调用和业务产物也已经跑通。Qoder CLI 和 CodeBuddy Code 提供了商用产品样本，DeepSeek Harness 提供了开源应用样本。真实模型实验统一选择 DeepSeek，覆盖重复支付回调修复、跨币种换算和退款状态核对。

三个产品的 Full 正常业务都达到各自批次的6/6 完成，登记敏感明文在客户端可见结果中的观测均为0。它们也都留下了原生子智能体实际调用工具、执行测试的协作记录，父子会话和工具回执可以对应。

做到这里，可迁移性的含义比最初清楚了。已有证据分别来自真实开源框架、开源应用和商用产品；对产品接入这条线，三者复用了相同的网关、策略和密码实现。这是我们当前最有实证支撑的优势之一。

04 任务照常完成，数据流转的方式发生了变化

框架接上之后，还需要一个更直接的对照：同样的任务，保护前后到底改变了什么。我们保留三种模式。Raw 作为无保护实验对照；Policy Only 启用授权和模型可见字段控制；Full 沿用相同策略，再增加国密封装、验证和防重放。CodeBuddy 的正式对照是三个业务案例、三种模式、每组两次，共18 次运行。

这张图把两种保护效果分开了。仅策略模式已经减少了模型可见结果中的敏感原文。但在代理之间，原始业务内容仍会经过。Full 将这段流转纳入密码保护，在本组实验中，代理间明文观测从36 次降至 0 次，同时72 份封装签名全部通过独立验证。

业务结果也保留下来了。重复回调、跨币种换算和退款状态三个案例，分别得到15500 分、70158 分和 8000 分的正确结果，三种模式一致。

这些结果由真正执行过的补丁产生。代码在无网络、只读、无宿主挂载的 Docker 环境中运行。

我们认为，这组对照很能体现框架的实用价值：业务处理仍在继续，模型能够获得必要依据，敏感数据的可见范围和流转方式则受到控制。保护与任务完成有了同一组可检查的结果。

05 保护要起作用，也要说清楚是谁起了作用

实验推进中，早期 24 次诱导会话里，模型都没有真正发出越权请求。后来，我们补充了明确要求模型发起的合成越权探针：尝试读取其他任务材料，尝试向本机测试接收器外发，然后继续修复原来的业务。只有网关实际收到请求，才能判断后续控制是否有效。

在 Qoder 与 Harness 的这组测试里，Raw 的12 次越权调用全部达到目标；Policy Only 与 Full 各12 次请求被网关拒绝，均未派发至业务端。全部 18 个会话仍完成原来的合法业务。

我们还在代理间主动修改补丁报文、重复发送已有报文。仅策略模式仍会接受测试中的在途修改和重放，Full 则在执行前拒绝篡改与重复报文，保留第一次合法执行。这部分才是密码完整性和防重放的直接贡献。

CodeBuddy 的 Hook 测试又把接入往产品原生工具推进了一步。模型确实发起了受限文件读取，Raw 的两次读取成功，两个保护模式的四次读取被我们的 PreToolUse Hook 拒绝；公开文件读取和后续业务都正常完成。

这几组结果分别证明授权、密码控制与扩展接口的作用。把它们放在一起，框架的优势就更具体了：既能控制标准 MCP 调用，也能通过产品开放的 Hook 接入其他已配置边界，而且拒绝越权之后，合法任务仍能继续。

06 轻量化，要同时看接入和开销

接入时少改业务代码，是轻量化的一部分。运行时增加多少等待、占用多少资源，也必须能够体现出来价值。

我们的第一版性能结果并不理想。＜1M的请求、短回执的局部转发测试中，Full 与 Policy Only 两组 p95 耗时之差为532.74 ms。之后保留协议和校验流程，优化密码实现。

优化后，上述差值降至86.11 ms，达到既定目标；Full 局部转发 p95 为106.39 ms。在同一新核心中仅切换密码实现的交替对照，也观察到 Full p95 从521.85 ms 降至 99.27 ms，补充验证了实现优化的收益。实际任务里，CodeBuddy Full 累计封装与打开耗时的中位数为507.16ms。

这部分实践让“轻量化”有了两个可检查的落点：一端是通过外置组件和配置接入、保留原业务函数，另一端是保留保护检查之后，局部性能达到了预设目标。

07 几个优点

回看整个过程，我们越来越重视保护能力能否进入别人正在使用的系统，能否让人低成本、低改动的迁移。

首先，接入方式能够适应不同控制条件。开源框架有节点与状态扩展点，现成产品有 MCP 和 Hook。已有实验覆盖这两类路径，采用现成产品的使用者，也有机会通过公开接口为已接入业务增加保护。

其次，几种控制在业务中各有职责，又能够共同工作。授权约束操作范围，国密保护代理间报文，字段策略控制模型可见结果。三模式对照让各部分贡献能够被单独观察，也避免把全部效果归给其中一个机制。

更重要的是，保护后的任务结果经过了独立检查。补丁、计算值、测试回执和业务工单都有实际产物。对使用者而言，数据受到保护且原来的工作能够完成，才有继续接入的价值。

三、总结

往深里想，手头这两条线其实还有不少没挖完的东西。任务权限合同现在靠可信配置来写，可如果任务本身是开放式的，谁来写、怎么版本化、能不能编译成一种子智能体可以独立向第三方证明的委托令牌，这些问题都还悬着。国密这块，软件层封装已经能把代理间明文降到0，但硬件TEE和芯片内生商密正在起来，哪些保护该留在软件层、哪些可以下沉，边界还没系统回答。记忆治理我们做到了写入时绑来源，可一条被投毒的记忆经过一次合法摘要或派生之后，来源标签还准不准，派生传播下权限怎么衰减，这是个硬缺口。证据审计也一样，执行许可本身已经带着HMAC、一次性消费和参数绑定，它其实可以不只是安全控制，还能长成一条第三方可独立验证的因果链。 我们没打算把这些问题都包装成“体系”，但会接着往下做。安全如果只停在报告里，业务跑不动，迟早被绕过；可信也不是给智能体套层壳，得让它每一步说得清依据，同时原来该完成的事还能完成。 路还长，问题还多，我们继续。