AI密码应用指引发布了，但有6件事工程上做不到

2026年8月，中国密码学会密评联委会发布了《生成式人工智能系统密码应用指引》。这是国内第一份把密码技术系统性地应用于生成式AI全生命周期的指导文件。

但在实际做智能体安全项目时，我们发现有六条要求照字面意思在工程上做不到。不是技术能力不够，是前提条件不满足——指引隐含了一个假设：智能体交互的所有参与方都具备密码学身份。现实中远非如此。

一、智能体与工具的双向身份认证

指引要求智能体和工具双方互相验证数字证书。实际场景中，智能体调用的数据库、文件系统、GitHub API、各类SaaS接口，绝大部分只支持账号密码或API Key认证，不支持证书认证。我们对主流工具做了一个粗略统计，支持证书双向认证的不到10%。

务实做法：在智能体和工具之间部署代理层，由代理验证智能体身份。工具方不需要做任何改造。代理验证通过后转发请求，验证不通过则阻断。这种单方验证覆盖了双向认证无法覆盖的场景。

二、MCP协议消息的端到端保护

指引要求对智能体通信协议的每条消息做加密和签名。但当前主流的MCP协议本身没有内置加密和签名机制，主流Agent框架和开源MCP Server都不支持消息级签名。指引没有给出在协议层不支持时如何实现。

务实做法：在代理拦截点对请求做完整性签名和审计记录。不是端到端保护，但在代理点形成了可信锚——经过代理的请求有密码学证明。

三、外部工具的身份鉴别

指引要求对智能体调用的每个工具建立身份鉴别和授权校验。这需要工具方主动配合。但大部分工具只认API Key，不认证书。2026年行业报告显示46%的MCP Server没有任何认证机制。

务实做法：代理层维护可信工具白名单，智能体只能调用白名单内的工具。新工具上线时由管理员审核加入。这不是密码学意义上的工具身份认证，但在工程上可落地。

四、智能体任务规划的可验证凭证

指引要求智能体用数字签名对任务规划生成可验证凭证。数字签名需要私钥，但让大模型接触私钥是安全红线——提示词注入攻击可能导致私钥泄露。当前没有任何Agent框架支持在运行时为智能体注入签名密钥。

务实做法：不在规划层做签名，在执行层做验证。智能体的规划最终通过工具调用来执行，代理层在调用点验证当前操作是否在安全策略范围内。效果上同样能防止越权操作。

五、只有授权智能体实例能解密数据

指引要求只有获得授权的智能体实例才能解密敏感数据。这需要一套密钥分发体系——智能体启动时获取解密密钥。但智能体实例是动态创建和销毁的，生命周期可能只有几分钟，当前没有Agent框架支持密钥注入。

务实做法：密钥不分发给智能体，集中在可信执行环境（TEE）中管理。敏感数据在TEE内部解密，智能体拿到的是处理结果，密钥从不出TEE。智能体不需要持有密钥。

六、高权限操作的人工协同确认

指引要求高权限敏感操作须经人工核查确认。在实时推理场景中，智能体可能每秒执行数十次工具调用。如果每次高风险操作都等人工确认，响应延迟从毫秒级跳到分钟级，业务不可用。

务实做法：策略引擎自动裁决绝大多数操作，只有策略引擎无法判定的高风险操作才触发人工确认。人工确认是例外路径而非默认路径。

三个务实原则

上述六条有一个共同点：指引假设所有参与方都具备密码学身份，现实是只有代理侧具备。在此基础上归纳三个原则：

原则一：单侧验证替代双向认证。代理层验证智能体身份，工具方零改造。

原则二：拦截点签名替代端到端签名。在代理点对请求做签名和审计，不要求协议层内置支持。

原则三：自动裁决为主，人工确认为辅。策略引擎实时裁决，仅极少数操作触发人工。