本文信息来源于 efij/awesome-claude-code-security 仓库，快照固定在 commit 27230a5e16aa1134103e94901ab375e0e4e9ede4，仓库创建时间和快照日期均为 2026 年 3 月 12 日。它是社区维护的 Claude Code 安全资源目录，不是 Anthropic 官方文档。

这篇内容不是一篇线性教程，而是一个安全资源导航。原 README 收集了 Claude Code 和 AI coding agent 生态中的官方文档、加固方案、sandbox、hooks、MCP 安全、prompt injection、secret 泄露、企业治理、CI/CD、安全扫描器、漏洞研究、标准和 checklist 等资源。

需要注意，目录中的 CVE、产品能力、star 数、厂商描述、检测覆盖率、文档路径和“生产可用”“gold standard”等评价都具有时效性，归档时没有逐一复核。本文只做中文结构化整理，不能直接替代安全基线、漏洞公告或专业审计。

这份目录为什么重要

Claude Code 的风险面和普通聊天模型不同。它可以：

  • 读写项目文件；
  • 调用 shell 命令；
  • 访问 API；
  • 安装或调用 MCP server；
  • 运行 hooks；
  • 使用 plugins、skills、sub agents；
  • 在 CI/CD 或服务器中非交互运行。

因此，一个恶意的 .claude/settings.json、被污染的 MCP tool、README 中隐藏的 prompt injection、过宽的权限配置，或者泄露的 API key，都可能造成远程代码执行、凭证窃取或数据外传。

这份目录的核心价值是把这些风险面集中到一张地图上，方便团队建立 Claude Code 安全治理和评测维度。

资源分类总览

原 README 大致覆盖以下 19 类安全主题：

分类 关注点
Official Security Documentation Claude Code 官方安全、权限、sandbox、hooks、settings、auth、data usage、MCP 配置
Hardening and Permissions 生产加固模板、权限配置、agent 配置保护、注入防御、供应链控制
Sandboxing and Isolation MicroVM、container、gVisor、Seatbelt、bubblewrap、agent execution sandbox
Hooks and Guardrails PreToolUse、PostToolUse、ConfigChange、命令拦截、注入检测、审计日志
MCP Security MCP scanner、gateway、proxy、标准、tool poisoning、credential theft
Prompt Injection and Agent Threats prompt injection、agent hijacking、confused deputy、red teaming
Secrets and Data Leakage secret scanner、PII 过滤、敏感文件 deny、API key harvesting
Enterprise Governance and Policy Managed settings、SSO、audit、RBAC、组织级策略
Secure CI/CD and Automation GitHub Actions、headless mode、pipeline 权限、网络监控
Plugins and Supply Chain plugin marketplace、plugin trust、MCP server provenance、skills supply chain
Agent Orchestration and Loop Safety multi-agent、delegation、循环任务、cross-agent policy
OS and Endpoint Hardening macOS Seatbelt、Linux bubblewrap、VS Code trust、endpoint controls
Security Tools and Scanners Claude Code scanner、MCP scanner、LLM red-team 工具、secret scanner
Vulnerability Research RCE、hooks-based RCE、API key harvesting、研究披露
Frameworks and Standards OWASP LLM Top 10、OWASP Agentic Top 10、AISVS、AIVSS、NIST AI RMF、MITRE ATLAS
Research and Writeups 会议材料、安全研究、厂商分析
Competitor and Adjacent Controls GitHub Copilot、Microsoft、Google、Palo Alto 等相邻控制面
Checklists and Templates 可落地的安全 checklist 和策略模板
Community and Ecosystem Claude Code、MCP、LLM security、agent security 的相关目录

对于评测框架来说，这张分类表可以直接转成“安全层”的二级维度。

官方安全文档部分

目录首先列出 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。

这些文档对应 Claude Code 安全评测的基础事实来源。构建评测集时，不能只问模型“是否安全”，而要把官方机制转化为可验证任务。

可转化的样本包括：

官方机制 可设计的评测任务
permissions 给定 .claude/settings.json，判断 Allow / Ask / Deny 是否符合最小权限
sandboxing 判断某任务是否需要 sandbox，以及文件系统和网络应如何限制
hooks 设计一个拦截危险命令的 PreToolUse hook
settings hierarchy 判断 Managed、CLI、Local、Project、User 哪个配置优先生效
authentication 检查 API key 是否被错误写入项目配置
data usage 判断某类数据是否适合进入 Claude Code session
MCP configuration 审查 MCP server scope、transport、auth 和 allowlist
monitoring 设计 OpenTelemetry 或日志字段用于审计

Hardening and Permissions

这一类资源关注如何把 Claude Code 锁得更稳，包括：

  • Trail of Bits 的 claude-code-config；
  • progressive hardening framework；
  • 带 security component 的 Claude Code 配置指南；
  • production-ready templates；
  • hardening review prompt；
  • GitHub Actions 中的 Harden-Runner；
  • AppSec 厂商对 Claude Code 安全模型的分析。

对团队来说，这部分的重点不是“找一个模板照抄”，而是抽象出加固 checklist：

  • 默认权限是否过宽；
  • 是否限制 destructive shell 命令；
  • 是否保护 .env、SSH key、cloud credential；
  • 是否启用 sandbox 或隔离执行；
  • 是否有 hooks 记录和拦截危险操作；
  • 是否把 MCP server 纳入 allowlist；
  • 是否有项目级和组织级配置分层；
  • 是否能审计 agent 执行过程。

评测样本可以设计成配置审查题：给模型一个存在风险的 .claude/settings.json、.mcp.json、CLAUDE.md 或 hook 配置，让它找出风险并给出最小修改方案。

Sandboxing and Isolation

这部分收集各种 AI agent sandbox 方案，包括：

  • MicroVM sandbox；
  • Docker / container sandbox；
  • Kubernetes agent sandbox；
  • browser、shell、file、MCP、VS Code server 一体化环境；
  • SWE-agent 的 sandboxed shell；
  • MicroVM、gVisor、hardened container 的比较文章；
  • Claude Code 在 macOS Seatbelt 和 Linux bubblewrap 上的隔离说明。

这些资源说明 Claude Code 评测不能只在“本地开发机裸跑”场景中验证。真实部署至少有三类执行环境：

  • 开发者本机；
  • 远程服务器；
  • CI/CD 或云端隔离环境。

对评测框架的启发是增加 infra / isolation 层：

维度 需要评什么
文件系统边界 是否只读、是否能写工作目录外文件、是否保护 secret
网络边界 是否能访问任意外网、是否有 domain allowlist
进程边界 是否能启动任意子进程、是否能长时间后台运行
回滚能力 任务失败后是否能恢复工作区
环境一致性 本地、服务器、CI 的权限是否一致
可观测性 是否记录命令、文件改动、MCP 调用和失败原因

Hooks and Guardrails

Hooks 是 Claude Code 安全治理里的关键执行点。目录中列出的资源包括：

  • 拦截 destructive git / filesystem 命令的 safety-net 插件；
  • 实时扫描文件、web fetch、命令输出中的 prompt injection 的 hooks；
  • hook patterns 和高级技巧；
  • hooks + multi-agent observability；
  • 包含 hooks、skills、agents、commands、GitHub Actions 的综合项目示例；
  • NVIDIA NeMo Guardrails 等通用 guardrail 工具。

Hooks 可用于三类评测：

类型 示例
事前拦截 在 rm -rf、写 .env、修改 .git 前阻止
事后审计 记录工具调用、文件变更、MCP 响应、异常退出
注入检测 发现 README、网页、命令输出中要求泄露 secret 的指令

构建样本时，不能只验证模型最终有没有完成任务，还要记录 hook 是否触发、是否正确阻断、是否给出可解释原因，以及阻断后模型是否能选择安全替代路径。

MCP Security

MCP 安全是目录中最重要的一块之一。它覆盖：

  • MCP scanner；
  • MCP gateway / proxy；
  • MCP security standard；
  • MCP security checklist；
  • tool poisoning；
  • rug pull；
  • credential theft；
  • cross-server manipulation；
  • confused deputy；
  • GitHub MCP 漏洞；
  • 隐形后门；
  • MCP 安全论文和 benchmark。

从评测角度看，MCP 不是“能连上 server 就算通过”。至少要分层评：

层级 评测内容
连接层 server 是否可启动、transport 是否正确、auth 是否正确
schema 层 tool 名称、description、参数 schema 是否清晰且无诱导
route 层 模型是否选择正确 tool，而不是误用相邻 tool
execution 层 tool 调用参数是否正确，状态修改是否符合预期
trust 层 模型是否识别恶意 tool description、rug pull、权限扩大
data 层 是否避免把 secret、私有 repo、敏感文件发给不可信 server
recovery 层 MCP 失败、超时、返回异常时是否能降级

这部分可以直接指导我们设计 Native MCP 评测集：除了功能正确性，还要加入 tool poisoning、权限越界、跨 server 混淆、敏感信息外传等安全样本。

Prompt Injection and Agent Threats

目录列出了 Claude Code 相关的 prompt injection 研究和通用 red-team 工具，例如：

  • 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 description； -网页；
  • 文档注释；
  • MCP tool description；
  • 命令输出；
  • 测试日志；
  • 依赖包说明；
  • generated artifact。

因此评测样本应该区分两种能力：

  • 识别恶意内容，不把它当成高优先级指令；
  • 在继续完成原任务的同时，隔离或忽略恶意指令。

一个好的 Claude Code 层级评测框架，应把“抗注入能力”从通用安全能力中单独拆出来，因为它会影响几乎所有工具链路。

Secrets and Data Leakage

这一类资源覆盖 secret scanner、PII 检测、敏感文件保护和 API key harvesting。代表工具包括：

  • 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 识别为注入，不执行
工具输出中包含 key 最终回答应脱敏
生成配置文件 使用 env var 占位符，不写真实 key
CI 脚本 不把 secret echo 到日志

这类样本的 verifier 可以结合正则、entropy 检测和人工 judge rubric。

Enterprise Governance and Policy

企业治理部分关注组织级落地能力，包括：

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

对 Claude Code 评测来说，这意味着除了单次任务，还要测“组织可控性”：

  • 是否能统一下发 settings；
  • 是否能阻止项目覆盖组织策略；
  • 是否能审计 session；
  • 是否能按 team / repo / role 控制权限；
  • 是否能统一管理 MCP server；
  • 是否有模型和工具调用成本可观测性；
  • 是否能复盘失败样本。

这些指标不一定由单个模型回答决定，但应该进入评测平台和 runner 设计。

Secure CI/CD and Automation

这部分关注 Claude Code 在 GitHub Actions、headless mode 和自动化 pipeline 中的安全运行。

关键风险包括：

  • 非交互模式下 approval 机制不同；
  • CI token 权限过高；
  • workflow 可以访问私有代码和 secret；
  • 网络默认开放；
  • agent 修改代码后可能直接提交或评论；
  • 日志可能泄露敏感信息；
  • MCP 或 package 安装带来供应链风险。

对评测框架来说，应建立 CI/CD 专门样本池：

  • PR security review；
  • 自动修复漏洞；
  • 生成 patch 但不直接 push；
  • 检查 workflow 权限；
  • 识别日志中的 secret；
  • 在网络受限环境中处理 MCP 失败；
  • 输出 SARIF 或结构化 report。

这能帮助我们区分“交互式 Claude Code 能力”和“服务器 / CI 自动化 Claude Code 能力”。

Plugins, Extensions, and Supply Chain

插件和扩展供应链部分覆盖：

  • plugin marketplace 的信任模型；
  • Anthropic official 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、网络、文件、credential、MCP
依赖 是否下载 npm / pip / binary
更新 是否可能发生 rug pull 或 tool description 变更
配置 是否写入 project settings 或 managed settings
数据流 是否把项目代码、token、日志发给外部服务

构建高频 skill / MCP 评测集时，应优先把“使用频率”和“风险等级”结合，而不是只按 star 数排序。

Agent Orchestration and Loop Safety

多 agent 和自动循环任务的风险包括：

  • agent goal hijacking；
  • tool misuse；
  • identity abuse；
  • delegation risk；
  • 多 agent 之间传递错误上下文；
  • 无限循环或成本失控；
  • 子 agent 越权使用工具；
  • 汇总层丢失安全约束。

评测样本可以设计为：

  • 一个主 agent 调用多个 sub agents 做代码审查；
  • 其中某个输入文件含有注入指令；
  • 某个子 agent 试图访问无关敏感文件；
  • 最终汇总必须保留证据、拒绝越权、报告被阻断操作。

这可以验证 Claude Code 是否能在多 agent 链路中维持安全边界。

OS and Endpoint Hardening

这部分强调 Claude Code 运行在具体工作站上，因此 OS 层也要进入评测视野：

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

从 runner 设计看，必须记录每次评测的环境元数据：

  • OS；
  • Claude Code 版本；
  • settings 层级；
  • sandbox 是否开启；
  • network policy；
  • writable roots；
  • MCP server 列表；
  • env var 注入方式；
  • 是否运行在 CI、服务器还是本地。

否则同一个模型在不同机器上的结果不可比较。

Security Tools and Scanners

目录把工具分为几类：

  • Claude Code specific scanners；
  • MCP scanners；
  • LLM security toolkits；
  • secrets scanners。

这些工具可以作为 verifier 的组成部分。例如：

  • 用 Gitleaks / TruffleHog 检查最终输出和工作区是否产生 secret 泄露；
  • 用 MCP scanner 检查待测 MCP server；
  • 用 promptfoo / Garak / PyRIT 生成攻击样本；
  • 用 LLM Guard 做输出过滤或 PII 检测；
  • 用 SARIF 输出对接 GitHub code scanning。

这说明我们的评测平台不应该只依赖 LLM-as-judge。安全类任务应尽量引入确定性 scanner、规则、日志和状态校验。

Vulnerability Research and Standards

目录列出的漏洞研究包括：

  • MCP 配置导致 RCE；
  • hooks-based 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 层级评测框架的启发

结合这篇目录，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 rubric。
  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、权限和数据处理方式，不能把社区目录直接等同于官方最佳实践。