Claude Code 正在尝试构建一个插件化的 AI 安全体系：钩子机制、技能加载、上下文集成协议（MCP）等模块一应俱全，结构复杂度在同类工具中颇为罕见。

Gitee CodePecker 团队近期完成了一项关于 Claude Code 安全治理机制的结构性评估，报告中发现，这些机制虽然形式完备，却无法构建出一个可信、安全的执行链条。根本原因在于：关键安全判断仍然依赖模型的上下文理解与行为幻觉。

报告以企业级研发环境为背景，系统评估了 Claude Code 在代码生成、审查与上下文集成环节中的行为模式，并揭示其在可复现性、误报控制、边界约束等方面的核心风险。

本文基于 Gitee CodePecker 团队发布的《Claude 代码质量安全插件分析》，对其插件机制、调用链设计与实测表现进行结构性解读与风险复盘。

插件机制本身具备启发性，但不能替代工程化防线

Claude Code 所采用的插件设计，是一种将 AI 能力包裹进微型代理、指令与钩子的轻量编排系统。特别是 PreToolUse 钩子的使用，使得模型可以在执行写入或命令前进行「安全检查」，这是当前 LLM 编程接口中少见的尝试。

但报告中指出，该钩子机制高度依赖正则匹配和模型的上下文判断能力，缺乏对 AST、CFG 等语义层的理解，无法识别路径变换、变量拼接、编码混淆等现实攻击模式。换句话说，它在面对显式危险操作时表现尚可，但对结构性设计失误缺乏识别能力。

技能体系（Skills）与渐进加载：灵活但不可控

Claude Code 推出的技能定义系统以SKILL.md文件为载体，支持模型在对话中根据用户意图动态加载任务指令，表面上看提供了一「软治理」路径。

但报告指出，该机制的实际效果建立在模型是否「正确理解用户意图」的前提下。这种高度概率化的行为使得关键的安全建议（如认证机制要求、数据加密规范）可能在未被触发的情况下被彻底跳过。这与传统安全系统强调「强约束、强触发」的逻辑完全相悖。

MCP 模型上下文协议是亮点，但执行链条仍存盲区

Claude Code 的一大亮点是其支持通过 MCP 协议与 SonarQube、Snyk 等平台对接，从而实现生成式模型与确定性工具链的结合。

然而，报告明确指出：

• 模型是否调用 MCP 工具，依然由其自身判断；
• 工具返回结果是否被采纳，仍依赖模型自身解析；
• MCP 服务自身缺乏签名与信任机制，可能成为供应链攻击的新入口（Tool Poisoning、Rug Pull）。

这种「靠模型调用工具、靠描述决定行为」的设计，缺乏平台侧的封装与边界控制，无法满足企业级 CI/CD 审计链条的基本要求。

插件机制本身结构复杂，但安全逻辑缺失

从架构设计上看，Claude Code 插件本身具备完整的模块划分与流程串联机制。根据报告分析，其插件系统主要由三部分构成：

• 功能插件（Skills）：按文件能力、操作能力、生成能力等模块进行分组，以 .claude/skills/ 目录和 SKILL.md 为定义入口；
• 指令调度（Actions）：通过 YAML 指令链描述执行逻辑，驱动底层脚本或操作；
• 上下文集成（MCP）：作为 Claude 与外部工具（如 SonarQube、Snyk）连接的桥梁，用于补足模型语义盲区。

在形式上，这些模块构成了一个具备插件化、流程分层、上下文管理能力的完整系统。报告对其 YAML 调用链和钩子执行流程也进行了详细还原（包括输入处理、意图识别、技能加载、指令分发、MCP 工具调用等步骤）。

但问题在于：这些机制中缺乏任何工程级的强约束或边界控制手段。

• 技能触发路径是非强制的：是否加载某个技能，完全取决于模型是否“理解到用户意图”，即依赖 LLM 的概率输出，而非平台规则；
• 钩子行为无平台判定机制：例如 PreToolUse 钩子，虽然号称“可做安全检查”，但实际只通过正则规则过滤关键词，没有抽象语义判断或行为审计能力；
• 上下文集成路径易被绕过或滥用：MCP 工具链虽然支持调用安全扫描平台，但是否调用、是否使用扫描结果、是否中断原请求，完全由模型本身决定，平台无法干预或审计。

报告总结为一句话：Claude Code 插件系统的调用链虽完整，但安全行为的触发机制和响应机制全都建立在「模型能理解、模型会判断」的假设上，这是一种结构性的不可信。

报告实验：误报率高达 86%，审查结果不具可重复性

在报告的实证部分，Gitee CodePecker 团队选取 11 个主流开源 Python Web 项目，使用 Claude Code 的 code-review 插件进行审查。结果显示：

• 真阳性率仅为 14%，误报率高达 86%；
• 相同代码，多轮模型调用的审查结果完全不同；
• 某些高风险段落，模型根本未发现问题。

这些结果直接指出了其最大缺陷：生成式模型本身并不具备安全审计所需的确定性与可复现能力，也难以满足企业对「可信结果链条」的最基本要求。

安全防御体系的根基，不应建立在模型的假设上

报告最后指出，Claude Code 当前的架构建立在一个危险的前提之上：模型将会「理解用户意图」、「正确调用安全技能」、「准确解读 MCP 工具返回值」，并「合理拒绝危险请求」。

但安全不是概率游戏，而是对最坏情况的防范。真正具备工程可用性的安全体系，应具备以下三个特征：

• 安全判断从模型行为中抽离
• 结果链条具备可审计性与复现性
• 所有关键规则来自平台定义，而非提示词诱导

Claude Code 当前尚未满足这三项。

面向企业的启示：构建 AI 安全体系的三条底线与实践建议

从 Claude Code 的架构中可以看到，当前不少 AI 编码工具在形式上具备插件机制、工具集成与安全提示等能力，但其安全能力本质上依然依赖于模型本身的行为正确性与理解准确性。这对任何以结果稳定性为前提的工程体系而言，都是不可接受的前提假设。

Gitee CodePecker 团队认为，企业在评估与接入 AI 编码工具时，应明确划定以下三条安全设计底线：

决策链条必须「可预测」而非「可对话」

所有关键行为（如插件加载、安全检查、指令触发）都应来源于平台规则，而非提示词引导。要避免「模型理解不到，规则就失效」的概率风险。

实践建议：

• 将所有关键限制写CLAUDE.md / SKILL.md 等插件入口文件，明确禁止事项（如禁用硬编码密钥、要求参数化 SQL 等），确保规则对模型具备锚定作用。
• 不依赖「善意 prompt」，而是让平台主导决策链条。

安全控制应「外置于模型」而非嵌入逻辑

所有关键操作的权限判断、指令拦截与策略生效机制，应由平台或中间件控制执行，而不是交由模型自身判断是否执行某个调用。

实践建议：

• 构建混合验证流程：将 Claude Code 插件输出强制接入 SAST 工具链，通过 MCP 协议实现自动化扫描。
• 要求模型根据扫描结果进行代码修复，人类再进行最终审阅，形成 「生成 → 检查 → 修复 → 审阅」 的闭环。

安全边界必须「物理隔离」，而非逻辑假设

Claude Code 插件具备文件写入与终端调用能力，如果直接运行在宿主环境中，任何误调用都可能带来灾难性后果。

实践建议：

• 使用 DevContainers、Docker 等轻量容器封装 Claude Code 的执行环境，实现进程级隔离。
• 启用只读权限、定期销毁容器、限制网络访问范围，从架构层切断外溢风险。

以上三条底线看似基础，但正是在当前的大模型接入实践中，常常被忽视、弱化甚至绕过。

企业不能假设「模型总会理解」、也不能接受「结果偶尔出错」。只有将判断权、规则定义权和执行控制权牢牢掌握在平台手中，才能真正建立一个可控、可审计、可复现的 AI 安全体系。

我们为什么要做这份报告

Gitee CodePecker 是面向企业场景构建的代码质量与安全分析引擎。我们关注的不只是代码行里的 bug，更是工具架构背后的可信边界。

当 AI 正在渗透开发流程的每个环节，Gitee CodePecker 团队认为有必要重新审视：

• 安全工具的触发机制该由谁控制？
• 安全策略应写在提示词里，还是平台规则里？
• 安全判断能否被复现，而非仅仅「感觉合理」？

安全从不是大模型能力的附属品，而是平台机制的第一责任。只有把控制权交还给平台，企业才能在 AI 编程时代建立起真正可信的防线。