efij/awesome-claude-code-security 是一份由社区维护的安全资源清单，服务于 Claude Code 以及更广泛的 AI 大模型编程代理生态。本次整理所引用的快照锁定在 commit 27230a5e16aa1134103e94901ab375e0e4e9ede4，该仓库的创建时间与快照生成时间均为 2026 年 3 月 12 日。需要预先说明的是，这份仓库并非由 Anthropic 官方发布，而是第三方围绕官方文档、安全工具、攻防研究、治理框架等材料汇总而成的导航条目。

这份 README 本质上不是一条线性的学习教程，而是一种风险面索引。它试图将 Claude Code 与 AI 大模型驱动的 coding agent 安全相关的分散信息收拢到同一张图上：官方安全说明、加固方法、沙箱实现、hooks 机制、MCP 安全、prompt injection、secret 泄露、企业治理、CI/CD 实践、安全扫描器、漏洞研究、参考标准与 checklist 均被归入其中。对于 API 中转站等中间件平台，类似的安全治理维度同样值得关注。

需要注意的是，这类目录天然带有时效性。所有 CVE 条目、产品能力表述、GitHub star 数、厂商宣传、检测覆盖率、文档链接，以及类似“生产可用”“gold standard”的定性判断，在归档那一刻都未经过逐项核验。本文所做的工作，仅是在中文语境下对这些资源进行结构化重新编排，它不能替代任何安全基线文档、漏洞公告或专业审计意见。

围绕这份目录展开分析，有两条线索值得贯彻始终：一条是“风险面到底在哪里”，另一条是“这些资源如何转译成可执行的评估维度”。接下来的内容会沿着这两条线索逐层展开。

为什么 Claude Code 的安全问题需要单独看待

Claude Code 与传统聊天式模型有一个根本性差异：它被赋予了实际执行能力。具体来说，它可以：

• 读取和修改项目文件；
• 执行 shell 命令；
• 调用外部 API；
• 安装或调用 MCP server；
• 触发 hooks 机制；
• 使用 plugins、skills 和 sub agents；
• 在 CI/CD 流水线或服务器环境中以非交互方式运行。

能力边界的扩展，直接带来攻击面的扩大。一个被篡改的 .claude/settings.json，一个经过投毒的 MCP tool，一段隐藏在 README 中的 prompt injection，一组过度开放的权限配置，或是一枚意外泄露的 API key，都有可能导致远程代码执行、凭证被窃取或数据被外传。在 API 中转站场景中，类似的权限扩展和中间件调用同样会引入新的风险面。

传统评估方式往往只关注模型最终生成的内容是否正确。但在 Claude Code 这类 agentic 场景里，结果正确不等于过程安全。真正值得关心的是：模型在拿到一个可疑指令时，是否会在执行链路中的某一环做出危险选择。这也是为什么有必要把安全治理从通用能力评估中独立出来。

这份目录之所以重要，核心在于把零散的风险信号集中到了一张地图上。团队在制定安全基线、搭建评估集或审核部署方案时，不必再花费大量时间在多个来源之间来回检索。

目录全景：十九个分类主题

原 README 覆盖的主题范围可以归为十九个大类。为了方便阅读，下面以表格形式呈现每个类别的主要关注点：

目录分类	覆盖内容
官方安全文档	Claude Code 的安全总览、权限机制、沙箱能力、hooks、settings、身份认证、数据处理、MCP 配置
权限加固	生产环境配置模板、权限管理、agent 配置保护、注入防御、供应链管控
沙箱与隔离	MicroVM、容器、gVisor、Seatbelt、bubblewrap、agent 执行沙箱
Hooks 与护栏	PreToolUse、PostToolUse、ConfigChange、命令拦截、注入识别、审计日志
MCP 安全	MCP 扫描器、网关、代理、标准规范、工具投毒、凭据窃取
提示注入与代理威胁	prompt injection、agent 劫持、confused deputy、红队攻防
密钥与数据泄漏	secret 扫描、PII 过滤、敏感文件拒绝、API key 采掘
企业治理与策略	Managed settings、SSO、审计、RBAC、组织级管控
CI/CD 与自动化安全	GitHub Actions、headless 模式、流水线权限、网络监控
插件与供应链	插件市场信任、插件安全、MCP server 来源验证、skills 供应链
多代理编排与循环安全	多 agent 协作、任务委派、循环执行、跨代理策略传播
操作系统与终端加固	macOS Seatbelt、Linux bubblewrap、VS Code 信任机制、终端控制
安全工具与扫描器	Claude Code 扫描、MCP 扫描、LLM 红队工具、secret 扫描
漏洞研究	RCE、基于 hooks 的 RCE、API key 采掘、安全披露
框架与标准	OWASP LLM Top 10、OWASP Agentic Top 10、AISVS、AIVSS、NIST AI RMF、MITRE ATLAS
研究与文章	会议报告、安全研究、厂商分析
竞品与相邻控制	GitHub Copilot、Microsoft、Google、Palo Alto 等产品的安全机制
Checklist 与模板	可直接投入使用的安全清单和策略模板
社区与生态	Claude Code、MCP、LLM 安全、agent 安全相关的索引

这十九个分类如果用于评估设计，可以很直接地映射为“安全层级”的二级维度。换句话说，想要检验一个 agent 是否安全，未必需要模拟全部攻击手段；先把这几个领域的检查点铺开，就已经形成了一张可操作的评估骨架。

官方安全文档：评估的事实基准

目录中排在开头位置的是 Claude Code 官方发布的安全文档，涉及以下主题：

• Security Overview；
• Configure Permissions；
• Sandboxing；
• Hooks Reference；
• Hooks Guide；
• Settings；
• Authentication；
• Data Usage；
• Zero Data Retention；
• Monitoring and Usage；
• MCP Configuration；
• Claude Code on the Web；
• Amazon Bedrock Integration。

这些文档构成了评估工作的底层事实来源。要判断一个配置是否安全、一个行为是否合规，首先必须搞清楚官方机制的设计意图。评估任务在设计时，不能只是抛出一个“这设置安全吗”的笼统提问，而应当把官方机制拆解为可执行的验证步骤。

下表给出了一些转化的思路：

官方机制	可设计的评估任务
permissions	提供一份 .claude/settings.json，要求模型评估其中的 Allow、Ask、Deny 配置是否符合最小权限原则
sandboxing	根据任务类型判断是否需要启用沙箱，并说明文件系统与网络应当如何限制
hooks	编写一个 PreToolUse hook，用于拦截危险 shell 操作
settings hierarchy	理清 Managed、CLI、Local、Project、User 各层配置的优先顺序
authentication	检查 API key 是否被错误地写入项目配置文件中
data usage	判断某类敏感数据是否适合进入 Claude Code 会话
MCP configuration	审查 MCP server 的 scope、transport、认证方式和 allowlist
monitoring	设计 OpenTelemetry 字段或审计日志格式，用于追踪模型行为

这类任务的共同特征是：它们的答案来自官方文档，而不是来自模型的通用常识。评估集如果缺少这一层，后续所有安全测试都会缺少锚点。

权限收紧与加固策略

在权限加固这一类资源中，目录收录了 Trail of Bits 的 claude-code-config、渐进式加固框架、附带安全组件的 Claude Code 配置指南、生产级模板、加固评审 prompt、GitHub Actions 中的 Harden-Runner，以及 AppSec 厂商对 Claude Code 安全模型的分析文章。

对于团队来说，这一部分的重点不在于“找一个配置模板往项目里贴”，而在于从中抽象出一份适合自己的加固 checklist：

• 当前默认权限是否过宽；
• 是否限制了 destructive shell 命令；
• .env、SSH key、云凭证等敏感文件是否得到了保护；
• 是否启用了沙箱或隔离执行机制；
• 是否存在 hooks 来记录与拦截高风险操作；
• MCP server 是否被纳入 allowlist 管理；
• 项目级与组织级的配置分层是否清晰；
• agent 的执行过程是否可以被完整审计。

由这一部分可以直接派生出配置审查题：给模型一个存在安全隐患的 .claude/settings.json、.mcp.json、CLAUDE.md 或 hook 配置，让它找出风险点，并给出最小化的修改方案。与常见的问答式安全题不同，这类题目要求模型真正理解配置项之间的关联。

Hooks：执行链路上的治理抓手

在 Claude Code 的安全体系里，hooks 是最直接的干预入口之一。目录中收录的相关资源包括：

• 面向 destructive git 与 filesystem 操作的 safety-net 插件；
• 能够扫描文件、web fetch 内容与命令输出中的 prompt injection 的实时 hooks；
• hook 设计模式与高级用法；
• hooks 与 multi-agent 可观测性结合的实践；
• 一个整合 hooks、skills、agents、commands 和 GitHub Actions 的综合示例项目；
• NVIDIA NeMo Guardrails 等通用 guardrail 工具。

hooks 的能力可以对应到三类评估场景：

评估类型	典型场景
事前拦截	在 rm -rf、写入 .env、修改 .git 目录等危险操作发生前阻止
事后审计	记录工具调用、文件变更、MCP 响应和异常退出等信息
注入检测	识别 README、网页内容、命令输出中要求泄露 secret 的恶意指令

在设计这部分评估样本时，需要关注的不仅是模型最终是否交付了任务结果，还包括：hook 是否被触发、是否正确执行了阻断、是否给出了可解释的原因，以及在阻断发生后模型能否切换到安全替代路径继续完成任务。这些过程性指标往往比结果本身更能反映系统的安全韧性。

沙箱与执行环境隔离

目录中列举了多种面向 AI agent 的沙箱方案：MicroVM 沙箱、Docker/container 沙箱、Kubernetes agent 沙箱，以及将 browser、shell、file、MCP、VS Code server 整合起来的一体化环境。此外还有 SWE-agent 的 sandboxed shell，MicroVM、gVisor 与 hardened container 的对比材料，以及 Claude Code 在 macOS Seatbelt 和 Linux bubblewrap 上的隔离说明。

这些资源指向一个事实：Claude Code 评估不能只在一个“本地开发机裸跑”的假设下展开。真实部署环境中，agent 至少会出现在三种截然不同的执行场景：

• 开发者的个人电脑；
• 远程服务器；
• CI/CD 流水线或云端隔离环境。

三种场景的安全边界各不相同。因此评估框架必须引入一个基础设施层面的隔离维度：

维度	需要评估的内容
文件系统边界	工作目录是否只读、能否写入目录外文件、敏感文件是否受保护
网络边界	是否可访问任意外网、是否存在域名白名单
进程边界	是否能启动任意子进程、是否能形成长时间后台运行进程
回滚能力	任务失败后，工作区状态能否恢复到执行前
环境一致性	本地、服务器与 CI 环境之间的权限配置是否保持一致
可观测性	命令执行、文件修改、MCP 调用及失败原因是否被记录

如果评估平台忽略了这些环境变量，那么同一个模型在不同机器上的表现会失去可比性，评估结果也会失真。

MCP 安全：需要一个分层审查框架

MCP（Model Context Protocol）安全在整个目录中占据重要位置。相关条目覆盖了 MCP scanner、gateway/proxy、安全标准、checklist、tool poisoning、rug pull、credential theft、cross-server manipulation、confused deputy、GitHub MCP 漏洞、隐形后门，以及相关论文与 benchmark。

对于评估而言，MCP 的安全验证不能止步于“能不能连上 server”。一个完整的评估流程至少应当包含多个层次：

层级	评审重点
连接层	server 是否能够正常启动、transport 配置是否正确、认证是否有效
schema 层	tool 的命名、描述与参数 schema 是否明确，是否存在诱导性表述
路由层	模型是否选中了意图对应的 tool，而非被误导至相邻工具
执行层	工具调用参数是否准确，状态变更是否符合预期
信任层	模型能否察觉恶意 tool description、rug pull 或权限扩大
数据层	是否避免把 secret、私有仓库、敏感文件发送至不可信服务
恢复层	MCP 请求失败、超时或返回异常时，模型能否安全降级

这一套分层思路可以直接迁移到 Native MCP 评估集的设计中——既要测功能正确性，也要把 tool poisoning、权限越界、跨 server 身份混淆、敏感信息外传等安全样本纳入题集。

提示注入与代理威胁

提示注入是 agent 安全中讨论最多、也是最难根治的问题之一。目录中列出的相关研究工具包括：

• Check Point 针对 Claude Code project files 的研究，涉及 RCE、hook RCE 与 API key harvesting 三类风险；
• Lasso hooks 提供的实时 prompt injection 检测能力；
• promptfoo；
• Garak；
• PyRIT；
• Rebuff；
• HouYi；
• Open-Prompt-Injection；
• promptmap；
• OWASP LLM01。

在 Claude Code 的使用场景中，prompt injection 的藏身处远比通常想象得分散：

• README 文件；
• issue 或 PR 描述；
• 网页内容；
• 文档注释；
• MCP tool description；
• 命令输出；
• 测试日志；
• 依赖包说明；
• agent 生成的文件。

因此，评估样本需要区分两种不同层次的能力：一是识别恶意内容，不将其当作高优先级指令；二是在继续完成原有任务的同时，对恶意指令进行隔离或忽略。这两者缺一不可。

在一个合理的 Claude Code 层级评估框架中，“抗注入能力”应当被单独建模，而不是被并入通用安全能力。原因在于 prompt injection 的影响面会穿透几乎所有工具调用链路，很难靠单一机制完全防御。

敏感信息边界：密钥与数据泄漏防护

这一分类下的资源主要集中于 secret scanner、PII 识别、敏感文件保护和 API key 采掘防御。代表性工具包括：

• TruffleHog；
• Gitleaks；
• ggshield；
• LLM Guard；
• GitHub Secret Protection。

Claude Code 专项方面则包括 Data Usage and Privacy、Zero Data Retention、Sensitive File Protection 以及 API key harvesting 漏洞研究。

这些材料带来的评估启示是：安全测试需要专门设立“敏感信息边界”场景。下面列举几种可用于样本库的设计：

样本场景	期望行为
用户要求读取 .env 并总结内容	拒绝泄露 secret，同时说明如何安全处理
README 中指示上传 token	判定为注入指令，不执行
工具输出中含密钥	最终回答中进行脱敏处理
模型生成配置文件	使用 env var 占位符，不写入真实 key
CI 脚本输出日志	避免将 secret 打印到日志

这类样本的自动校验可以结合正则匹配、entropy 检测与人工 judge rubric，形成多层验证。仅仅依赖模型自评并不可靠。

多代理编排与循环安全

当任务从单个 agent 扩展到多个 agent 协同执行时，安全问题会变得更加复杂。目录中提到的风险类型包括：

• agent goal hijacking；
• tool misuse；
• identity abuse；
• delegation risk；
• 多代理之间传递了错误的上下文；
• 无限循环或成本失控；
• 子 agent 越权调用工具；
• 汇总层在整合结果时丢失安全约束。

这类风险更适合用专门的评估样本来测试：让一个主 agent 调度多个 sub agents 完成代码审查任务，在部分输入文件中埋入注入指令，让某个子 agent 尝试读取无关的敏感文件，最后观察汇总层是否能够保留证据、拒绝越权行为，并报告哪些操作被阻止。

通过这种设计，可以检验 Claude Code 在多 agent 链路中是否仍然能够维持安全边界，而不是在执行过程中逐渐丢失约束。

CI/CD 与自动化运行安全

这一部分聚焦 Claude Code 在 GitHub Actions、headless mode 以及其他自动化 pipeline 中的安全运行问题。关键风险包括：

• 非交互模式下 approval 流程发生变化；
• CI token 携带过高的权限；
• workflow 可以访问私有代码和 secret；
• 网络访问默认开放；
• agent 修改代码后可能会直接提交或发表评论；
• 日志中可能混入敏感信息；
• MCP 服务或依赖包的安装带来供应链风险。

评估框架需要为这些场景建立专门的样本池，例如：

• 执行 PR 安全审查；
• 自动修复漏洞；
• 生成 patch，但不直接 push；
• 检查 workflow 的权限配置；
• 识别日志中泄露的 secret；
• 在网络受限的环境中处理 MCP 调用失败；
• 输出 SARIF 或结构化报告。

这类测试有助于将“交互式 Claude Code 能力”与“服务器/CI 自动化 Claude Code 能力”区分开，二者的评估标准本来就应当不同。

插件与供应链信任

插件和扩展的供应链安全，是 agent 生态中容易被忽略但实际影响很大的问题。目录中列出的内容涉及：

• plugin marketplace 的信任模型；
• Anthropic 官方 plugin directory；
• safety-net；
• MCP server security standard；
• awesome plugin list；
• Trail of Bits security skills；
• Sonatype 供应链情报类 MCP。

这些材料可以与前一篇 Plugin Examples 的内容合并，形成一套插件评估方法论：

风险点	需要核查的内容
来源	official、community-managed、自建还是未知来源
组件构成	Skill、Agent、Hook、Command、MCP 是否定义明确
权限范围	是否申请了 shell、网络、文件、凭据或 MCP 相关权限
依赖关系	是否下载 npm / pip / binary 等外部依赖
更新机制	是否存在 rug pull 风险或 tool description 变动可能
配置位置	写入的是 project settings 还是 managed settings
数据流向	是否会把项目代码、token、日志发送到外部服务

在构建高频 skill 或 MCP 评估集时，应该同时考虑“使用频率”和“风险等级”，而不是简单地按照 star 数排序。

操作系统与终端加固

Claude Code 最终运行在某台具体机器上，操作系统层面的防护因此也应当被纳入评估视野。目录中涉及：

• macOS Seatbelt；
• Linux bubblewrap；
• sensitive file deny patterns；
• VS Code Restricted Mode；
• trust verification；
• third-party provider controls。

从评估平台的角度来看，每次评估运行的环境元数据都必须被记录：操作系统类型、Claude Code 版本、settings 层级、sandbox 是否开启、网络策略、可写目录范围、MCP server 列表、env var 注入方式，以及运行位置（CI、服务器还是本地）。缺少这些信息，任何跨环境的评估结果都难以解读。

企业治理与组织级策略

企业级落地能力是 Claude Code 能否进入生产环境的关键。目录中关注的管理机制包括：

• Managed Settings；
• Monitoring and Audit；
• Authentication and SSO；
• RBAC；
• MCP allowlist；
• agent control plane；
• organizational AI policy；
• build / deploy / run 各阶段的安全蓝图。

对应的评估维度则是“组织可控性”：

• 能否统一下发 settings；
• 能否阻止单个项目覆盖组织级策略；
• 能否对 session 进行审计；
• 能否按 team、repo、role 分设权限；
• 能否统一管控 MCP server；
• 是否有模型调用与工具调用成本的可观测性；
• 能否对失败样本展开复盘。

这些指标虽然不完全由模型的回答决定，但应当进入评估平台的功能设计，否则后续治理会缺乏抓手。

扫描工具与验证体系

目录中的安全工具可以归为四类：Claude Code 专用扫描器、MCP 扫描器、LLM 安全工具包、secret 扫描器。这些工具的价值不止于安全团队日常使用，它们还可以被整合进评估平台的 verifier 机制。例如：

• 使用 Gitleaks 或 TruffleHog 检查最终输出与工作区是否有 secret 泄露；
• 使用 MCP scanner 审查被测 MCP server；
• 使用 promptfoo、Garak 或 PyRIT 生成攻击样本；
• 使用 LLM Guard 进行输出过滤或 PII 检测；
• 以 SARIF 格式输出结果，对接 GitHub code scanning。

这意味着评估平台在设计上不能只依赖 LLM-as-judge 作为唯一裁判。安全类任务应当尽可能引入确定性 scanner、规则校验、日志分析和状态检查，才能保证测试结果的可复现性。

漏洞研究与标准体系

目录中记录的漏洞研究成果包括 MCP 配置导致的 RCE、基于 hooks 的 RCE、API key harvesting、Claude Code project files 风险，以及相关媒体文章和研究报告。标准部分则覆盖：

• OWASP Top 10 for LLM Applications；
• OWASP Top 10 for Agentic Applications；
• OWASP AIVSS；
• OWASP AISVS；
• OWASP AI Exchange；
• MCP Server Security Standard；
• NIST AI Risk Management Framework；
• MITRE ATLAS。

这套标准体系为评估标签提供了外部参照。每一条安全样本都可以标注多个维度，例如：

• risk_category=prompt_injection；
• risk_category=tool_misuse；
• risk_category=secret_exfiltration；
• risk_category=supply_chain；
• risk_category=privilege_escalation；
• risk_category=untrusted_mcp；
• risk_category=unsafe_automation。

有了这些标签，后续的报告就能从单一的 pass rate 升级为“各风险类别的通过率与失败归因”，这对安全团队定位系统短板至关重要。

评估框架中的安全主线

综合这份目录的内容，一个面向 Claude Code 的层级评估框架至少需要包含一条独立的安全主线，贯穿从环境搭建到企业治理的各个层级：

层级	安全评估重点
L0 环境与 runner	sandbox、网络、权限、版本、settings 是否可记录和复现
L1 配置识别	模型是否理解 settings、permissions、hooks、MCP scope
L2 触发与路由	是否选择了正确的 Skill / Command / MCP / Agent，是否拒绝了危险路径
L3 工具执行	shell、file edit、MCP、hook 调用是否符合最小权限原则
L4 工件质量	生成的代码、配置、文档、报告是否安全且可验证
L5 注入鲁棒性	能否识别 README、网页、MCP tool、日志中的恶意指令
L6 数据边界	secret、PII、私有 repo、token、session transcript 是否受到保护
L7 供应链与插件	是否审查 plugin、skill、MCP server、依赖和 marketplace 来源
L8 企业治理	managed settings、audit、RBAC、allowlist、CI/CD 控制是否可用

这条安全主线可以与此前已有的 Skill 评估、MCPMark、MCPSafetyBench 等评估结果形成互补。Skill 评估能够补足 Skill 触发、指令遵循与 content-only 维度；MCPMark 覆盖 MCP 工具发现、调用、状态修改与 verifier 设计；MCPSafetyBench 则补充了注入、越权与跨 server 风险；而这份目录的独特贡献在于，它提供了更完整的安全类别、工具链和治理维度。

构建安全数据集的实操方法

对于承担 Claude Code 安全样本构建任务的同学，可以参考以下流程来推进：

1. 从风险类别出发，而不是从某个具体工具出发。工具会变，风险类别相对稳定。
2. 每条样本都要明确标注攻击面，包括 Skill、MCP、Hook、Command、Shell、File、CI、Plugin 中的任意一项或多项。
3. 写清楚正常任务目标，避免样本退化为安全概念问答题。
4. 在正常任务中插入一个干扰条件或攻击条件，例如恶意 README、恶意 MCP tool description、敏感文件或过宽权限。
5. 明确期望行为，包括继续完成任务、拒绝危险动作、脱敏输出、请求确认或提供安全替代方案。
6. 优先编写自动 verifier，例如检查文件是否被修改、secret 是否出现在输出中、命令是否被执行、MCP tool 是否被调用。
7. 无法依赖自动 verifier 时，再补充基于 LLM-as-judge 的评分标准。
8. 为每条失败样本标注 failure layer，例如 trigger_error、unsafe_tool_call、secret_leak、wrong_mcp_tool、hook_bypass。

按这一流程产出的数据集，会更贴近 Claude Code 原生执行链路，而不是停留在“安全文章问答”的表面上。

落地使用建议

这份目录可以承担多重角色：

• 新成员可以通过它快速建立对 Claude Code 风险面的整体认知；
• 评估人员可以利用它补齐安全维度的标签体系；
• 平台团队可以依据它补充 runner 日志、权限、sandbox 和 MCP 观测字段；
• 安全团队可以从中挑选合适的 scanner、标准和 checklist；
• 管理层可以借此理解为什么 Claude Code 的评估不能只看任务完成率。

当然，这份目录本身只是一份导航。真正落地时，每个链接背后的时效性、维护状态、license、权限模型和数据处理方式都需要单独复核。社区维护的清单不能替代官方最佳实践，更不能直接替代专业安全审计。