Claude Code 的第一攻击面，可能就是 CLAUDE.md

每一次 Claude Code 会话开始时，都会先读取一个文件：CLAUDE.md。

在你的第一条提示词之前，在任何代码执行之前，在一切正式开始之前，Claude 会先读取这个文件，并把它当成整个会话的“事实基础”。

这句话本身不复杂，但从安全和合规视角看，信息量不小。

这不是不能用，而是要先回答：谁能改这个文件？

如果 CLAUDE.md 会被默认读取，并且对后续会话有持续影响，那它就不只是一个普通说明文档。

它更像是项目里的“启动配置”：

• 里面写什么，模型就可能优先相信什么；
• 它可能影响后续代码建议、操作路径、判断标准；
• 如果被恶意修改，它可能变成隐蔽的提示注入入口。

所以第一个问题不是“Claude Code 好不好用”，而是：

谁有权限修改 CLAUDE.md？
修改之后有没有审计？
使用者是否知道当前会话读到了什么内容？

很多团队会认真管生产密钥、CI/CD 配置、部署权限，但对这种“模型上下文文件”的权限边界还没形成肌肉记忆。

风险点拆开看

1. 提示注入不一定来自聊天框

大家谈提示注入，常常盯着用户输入、网页内容、第三方文档。

但这里的问题是：如果每个会话都会先读 CLAUDE.md，那它天然处在更高优先级的位置。

攻击者不一定要在聊天里诱导模型，只要能把内容写进这个文件，就可能提前影响整个会话。

这类风险不一定很戏剧化。更常见的可能是：

• 让模型忽略某些安全检查；
• 让模型优先使用某种不安全做法；
• 让模型在生成代码时泄露不该暴露的信息；
• 让模型把错误规则当成项目规范。

我不想把它说成“灾难入口”，但它确实是一个需要纳入评审的攻击面。

2. “项目事实”需要来源和边界

CLAUDE.md 被当作 ground truth，也就是事实基础。这个设计很方便：团队可以把项目结构、代码风格、运行方式写进去，减少重复解释。

但方便和可信不是一回事。

如果文件内容过期、错误，或者混入了临时指令，模型可能会继续沿用。尤其在多人协作项目里，没人能保证每次会话前都人工复查一遍。

这里至少要有几个基本问题：

• 这个文件由谁维护？
• 是否需要 code review？
• 是否允许外部贡献者修改？
• 是否有敏感信息写入风险？
• 是否和仓库权限、分支保护、审计日志绑定？

如果这些都没有答案，那它就不是“文档”，而是一个未治理的执行前上下文。

3. 隐私和数据留存也要跟上

很多团队会把项目背景、接口说明、内部约定写进类似文件。写着写着，就可能写进去：

• 内部系统地址；
• 测试账号说明；
• 客户数据样例；
• 合规流程细节；
• 临时绕过方案。

这些内容一旦被每个会话默认读取，就要按“会被模型处理的输入”来管理，而不是按普通 README 管理。

这不是说不能写，而是要先分类：

• 哪些信息可以进入 CLAUDE.md；
• 哪些只能放在内部文档；
• 哪些不能进入模型上下文；
• 哪些需要脱敏或引用占位符。

尤其是做企业接入前风险审查时，我会很关注这一点：模型工具读了什么、谁让它读的、读完有没有留存、日志里能不能追溯。

缓解措施其实不复杂

如果团队已经在用类似机制，建议至少做几件小事。

把 CLAUDE.md 纳入变更审查

不要让它成为随手改的“提示词草稿”。

可以按配置文件处理：

• 修改走 PR；
• 关键项目要求 reviewer；
• 禁止外部贡献者直接改；
• 对高风险指令做显式标注。

写清楚允许内容和禁止内容

比如：

允许写：

• 项目结构；
• 构建和测试命令；
• 代码风格；
• 常见约束；
• 安全开发要求。

不建议写：

• 密钥、token、账号；
• 客户数据；
• 内部绕过流程；
• 未脱敏日志；
• 含糊的“忽略所有限制”类指令。

定期检查是否过期

这类文件最怕的是“没人负责，但一直生效”。

过期信息会让模型做错事，错误安全规则也会被放大。

给使用者一个可见提示

会话开始时，最好让使用者知道当前读入了哪个 CLAUDE.md，来自哪个路径，最近一次修改是什么时候。

这不是形式主义。可见性本身就是一种控制。

我的判断

CLAUDE.md 这种机制的方向可以理解：它降低了模型理解项目的成本，也让协作更顺滑。

但安全上要把它当成一个“默认加载的高影响上下文文件”，而不是普通说明文档。

这不是不能用，而是要先回答三个问题：

1. 谁能写？
2. 写了什么？
3. 出问题时能不能追溯？

能回答清楚，它就是效率工具。回答不清楚，它就是一个很安静、但很靠前的攻击面。