Claude Code 密钥泄露：Apiiro 在 1,122 个公开 GitHub 文件中发现凭证

Apiiro 报告称，在 1,122 个公开 GitHub 设置文件中发现凭证后，Claude Code 的密钥泄露问题使 Anthropic 的已保存批准机制受到审视。其 11 月 5 日的研究描述了一项会记住包含密钥命令的功能。要将这些信息公开，还需要另一步：提交并推送生成的文件。

矛盾存在于实用的快捷方式与其生成的敏感记录之间。开发者为完成工作而批准一项操作，软件则保留了本应受到单独保护的信息。关于执行的决定变成了关于存储的决定，而用户往往并未将二者视为不同的选择。

Anthropic 已承认这一担忧，同时强调设置文件应保留在本地。Cursor 提供了一个有用的对照，因为其文档同样讨论了自主执行及其风险。在这些产品中，核心问题都是：权限系统如何在保留便利性的同时，避免再创造一个积累凭证的位置。

Claude Code 密钥泄露发现实际衡量了什么

Apiiro 的凭证暴露研究检查了 104,185 个公开的 .claude/settings.local.json 副本。研究在被标记的 1,122 个文件中识别出 1,379 个不同的密钥。研究人员没有测试这些凭证，因此该数量并不能证明访问权限仍然有效，也不能证明发生了成功入侵。

这一头条数据衡量的是暴露的文件，而不是遭到入侵的账户。 这一区别对于事件响应、采购决策，以及任何有关该发现严重程度的说法都至关重要。凭证的存在意味着应展开调查，而其有效性和权限则决定了直接后果。

其底层工作流程并不陌生。编程助手提出一项操作，开发者审核后，持续性批准可减少未来的中断。意外后果则出现在：保存的批准保留了开发者原本认为只是临时信息的内容。

可以将预发布数据库检查视为一个说明性场景。开发者需要助手调查一次失败的连接，并批准了一条包含认证信息的命令。完成这项检查，并不意味着该凭证必须成为持久的项目工件。

然而，批准记录可能恰恰保留了该操作所需的信息。它的用途听起来像行政管理，因此人们很容易在心理上将其与密码和访问令牌区分开来。当审核者以为配置只包含偏好设置、而非敏感的运营数据时，这种区分就会变得危险。

公开仓库又增加了一道边界。原本仅存在于开发者机器上的信息，会变得可供任何能够读取项目的人获取。因此，批准功能和发布工作流程需要分别接受审视。

若称选择该选项会自动将密码发送至 GitHub，便是夸大证据。所报告的流程涉及本地持久化，随后通过版本控制系统发布；版本控制系统负责记录并共享项目变更。每个阶段都提供了预防机会。

但若将问题仅描述为粗心提交，也同样低估了它。产品行为决定了哪些敏感材料会存在，从而可能被人提交。更安全的发布工作流程有所帮助，但避免不必要的凭证副本，解决的是问题更早的环节。

相关变化在于团队在审核时必须考虑什么。代理设置应与应用代码和部署配置一样受到关注。即使文件不包含可执行程序，其保留的信息也可能影响安全性。

这扩展了敏感变更的含义。审核者既要考虑文件揭示了什么，也要考虑它会让应用执行什么。权限记录正处于两者的交汇点。

本地设置文件是一项附带条件的承诺

Anthropic 的本地设置文档指出，持久化的 Bash 批准会成为 .claude/settings.local.json 中的允许规则。Bash 是用于运行程序的命令行 Shell。当 Claude Code 在文档所述条件下首次写入该文件时，会在开发者的全局 Git 忽略配置中添加排除规则。

该文档另行将 .claude/settings.json 标识为团队可提交的共享项目配置。手动创建的本地文件则需要各自的排除规则。这些区别清晰界定了预期边界，但也使文件的创建方式变得重要。

仅仅称一个文件为本地文件，并不能自动确保隐私。 它的名称向人们传达意图，而仓库控制机制决定它是否会随项目传播。这是彼此相关、但失效条件不同的两层保护。

全局排除属于开发者的环境。项目级排除属于仓库的工作流程。每当团队期望一项安全惯例能跨越机器、贡献者或开发环境的变化时，这一区别就尤为重要。

可以将项目交接视为一个分析示例。原作者知道哪些文件包含个人状态，哪些文件应纳入源代码管理。新贡献者看到目录结构时，却未必同时继承这种理解。

当每位贡献者都必须重新理解同一区别时，问题就演变为组织问题。依赖个人知识的规则需要反复关注。以共享项目政策呈现的规则则更容易检查和讨论。

两种方式都不能消除对提交内容进行审核的必要性。排除规则是一种预防性约定，而提交的变更才是真正的发布决定。团队应同时评估两者，而不应假定任一项的存在就能保证另一项。

术语本身也值得关注。设置通常让人想到显示选项或编辑器行为等无害偏好。权限文件却可能携带更敏感的记录，因为其内容源自真实操作。

这种不匹配给产品设计带来压力。如果软件会保留命令参数，它就应在用户将该文件视为普通配置之前，帮助用户理解这种持久化。相关警告应放在创建该记录的决定附近。

这里存在合理的可用性约束。要求用户检查每一个实现细节，会使助手更难使用，并鼓励流于形式的批准。设计挑战在于：既呈现真正重要的后果，又不让操作本身不堪重负。

对企业买家而言，这会成为一个具体的评估问题。管理员能否说明哪些代理文件可以安全共享、哪些应保持个人私有，以及哪些可能包含敏感数据？产品给出的答案应与员工实际使用的仓库控制机制保持一致。

文档中对 Claude Code 权限的说明提供了预期模型。实际检验在于：该模型在日常协作中是否仍然易于理解。文档建立预期；可观察到的行为决定团队能否可靠地遵循这些预期。

这一快捷方式以持久数据换取更少的重复提示

持久化批准的便利性很容易理解。开发者希望助手能持续完成常规工作，而不用在每一步都中断。一个反复请求同样决定的系统，会促使用户寻求更广泛或更持久的授权。

核心权衡在于：一方面减少中断，另一方面保留使这些中断得以减少的信息。 即使界面将两者放在一起呈现，执行权限和凭证存储仍应是独立的决定。

评估这一设计的一个有用方法，是将能力与数据分开。能力描述代理可以做什么，例如运行已批准的开发操作。数据则包括在执行期间提供的具体参数和认证材料。

保留能力并不一定要求保留每一项数据。不过，移除参数可能改变规则的含义。更宽泛的批准可能授权用户从未打算允许的操作，从而产生不同的安全问题。

因此，仅从已保存的命令中删除可疑文本，并不是完整的设计规范。产品必须在避免不必要保留的同时，保留用户预期的范围。当某项操作之后再次请求权限时，其行为也必须保持可理解。

凭证引用提供了另一种设计方向。命令可以引用单独提供的值，而不是直接嵌入该值。这减少了批准记录本身包含凭证的必要性。

引用仍需谨慎处理。程序可能打印解析后的值，错误消息可能泄露它，或其他工件可能保留输出。在一条记录中避免出现明文密码，可以减少暴露，但并不意味着已建立完整保护。

这正是该事件为何超越某个特定按钮的原因。代理软件会产生记录，以支持连续性、调试和协作。每项记录都应有明确的用途、受众和与其内容相称的保留政策。

助手表面上的记忆能力可能掩盖这些问题。用户体验的是一个持续推进工作的对话，而底层实现可能创建具有不同共享规则的文件。产品团队需要让具有重要影响的边界变得可见。

Cursor 的后台代理安全文档提供了有用的比较。它描述了隔离的虚拟机、互联网访问和自动终端执行。它还警告，恶意指令可能通过提示注入导致数据盗取，即不可信内容会重定向代理的行为。

这一比较并不能证明 Cursor 存在 Claude Code 被报告的批准存储行为。它表明，不同的竞争性设计会以不同方式在执行、隔离和用户审核之间分配责任。买家应分别比较这些机制，而不是仅根据批准模式选择产品。

隔离约束操作运行的环境。批准决定操作是否继续。凭证处理决定哪些敏感数据进入环境，以及之后留下哪些记录。

当这些控制措施的边界明确时，它们会相互强化。当一个层面的成功决定被视为其他每个层面都安全的证据时，它们就会令人困惑。已获授权的操作仍可能留下不恰当的记录。

因此，Claude Code 的安全风险应在工作流程层面进行评估。关键问题是：已批准的任务会产生哪些信息，这些信息会持久化在哪里，以及之后谁能检索到它。

Anthropic 承认存在缺口，但自动模式并非修复证明

Claude Code 团队的 Boris Cherny 在权限安全讨论中回应了该报告。他表示，Claude Code 过去缺少敏感信息清理机制，并建议使用自动模式和仓库密钥扫描。他还介绍了用于原型阶段的潜在防护措施，包括基础的敏感信息检测。

一名读者质疑，自动模式是否仍可能进入存在问题的审批路径。Cherny 承认了这一观察。他的评论表明团队正在积极回应，但并不能证明全面修复已经上线。

拟议的防护措施需要针对其意图防范的故障进行验证。 减少人工审批与防止凭据持久化是相关但不同的目标，验收标准也不相同。针对其中一项的证据，不应替代另一项的证据。

持怀疑态度的观点很直接：如果某项敏感操作仍会生成包含凭据的审批记录，那么改变默认执行模式并不会让这一路径失去相关性。回应措施既必须处理由此产生的工件，也要减少提示出现的频率。

Anthropic 强调减少权限中断也有合理依据。反复提示可能消耗注意力，却无法带来认真审查。改善这一体验是有价值的，前提是这种改进不能被包装成笼统的安全声明。

分歧的一部分在于应由何处执行约束。一些用户希望采用不受代理解释影响的固定限制。另一些用户则倾向于自动评估，以区分日常活动和敏感操作。

这些方法回答的问题不同于已保存记录是否包含密码。严格的执行边界可以与过度的数据留存并存。自动审查器可以减少中断，但仍需明确规定哪些内容会被写入磁盘。

企业评估应将这些问题分开看待。采购方可以重视自动任务执行，同时仍要求可预测的存储行为。产品应通过可观察的结果同时证明这两点，而不是要求客户从其中一点推断另一点。

一项可信的验证演练会在受控项目中使用人工凭据。它会在操作后检查审批记录及其他生成的工件，也会审查敏感本地文件已被跟踪时的行为。

这些是建议的评估条件，而非 Anthropic 已完成测试的主张。它们描述了区分有前景的回应与已被证明改进所需的证据。公开结果将使客户能够判断任何变更的范围。

Claude Code 的密钥泄露也暴露出沟通挑战。建议用户启用另一项控制措施是有用的，但这仍留下一个问题：产品本身将承担哪些责任。清晰的发布说明应同时解释新增防护和仍然存在的条件。

最公平的结论应当有限且可执行：Anthropic 已认识到这一担忧，用户提出了相关边界情形，而拟议变更的有效性仍需要观察。无论是轻视问题，还是宣称已完全修复，都不符合现有证据。

安全团队继承了一种不同类型的仓库审查

对安全团队而言，眼前的压力在于可见性。应用审查通常聚焦于在生产环境运行的代码。代理生成的设置可能在应用本身改变行为之前就造成暴露。

审查需要沿着开发工作流追踪敏感信息。 配置文件是否值得审查，取决于其内容和去向。其管理用途并不会让其中的信息变得无害。

GitHub 的推送保护会在发布前阻止受支持的密钥检测。其文档区分了特定提供商、通用、自定义及 AI 检测到的模式，各自的配置要求有所不同。因此，团队需要验证已启用的覆盖范围，而不能假设每一种凭据都会被发现。

扫描器的存在与扫描器已证明的覆盖能力，是两种不同形式的证据。可识别的服务令牌与嵌入命令中的普通密码，面临不同的检测挑战。通过人工示例进行测试，可以揭示已配置的系统是否识别团队实际使用的模式。

这改变了开发人员与安全人员之间的对话。开发人员需要能持续运作的工作流；安全团队则需要证据，证明敏感值不会悄然进入准备共享的材料。

共同目标应是可重复执行的边界。个人代理状态应有明确的存放位置，共享配置应有清晰的审查标准，被检测到的凭据应被交给能够撤销它们的人处理。

事件响应还必须区分遏制与清理。GitHub 的敏感数据移除指南优先要求撤销或轮换已暴露的凭据。该指南说明，移除历史记录需要协调，且副本可能仍存在于克隆、fork 和其他引用中。

这一顺序体现了凭据与包含凭据的文档之间的区别。编辑文档会改变读者在该位置看到的内容；撤销则改变凭据是否继续授权访问。

对处于压力下的团队而言，可见的清理可能让人觉得工作已经完成，因为违规文件已从最新视图中消失。真正相关的安全结果是暴露的值是否仍保有权限。历史清理和访问审查则处理额外后果。

当发现记录的人无法识别其所有者时，责任归属会变得更困难。开发人员可能认得项目名称，却不知道哪个系统签发了令牌。清晰的所有权能够缩短从发现到有效遏制的路径。

团队还需要一种保留教训而不保留密钥的方法。事件记录可以描述受影响的工作流、负责的服务和预防性变更，但应避免为了让说明更具体而复制敏感值。

这一差异同样适用于可搜索的知识库。有价值的工程知识包括经批准的流程和对过往故障的解释。凭据应存放在为访问管理而设计的系统中，而不是一般参考资料中。

当回应机制拥有明确负责人时，Claude Code 的安全风险会更容易治理。开发人员可以说明任务，平台团队可以执行仓库约定，服务所有者可以替换访问凭据。安全人员不应在调查期间被迫重建所有这些关系。

实际的组织变革是扩大审查边界。团队不仅需要检查助手编辑的内容，还需要检查它遗留下来的内容。这使持久化代理状态成为常规工程治理的一部分。

哪些证据能表明暴露路径正在关闭？

下一批有用证据应体现在产品行为、仓库控制和修复结果中。这些信号涉及报告所述流程的不同环节。它们结合起来，可以表明最初的暴露路径是否变得更难复现。

应以阻止持久化和降低凭据权限来衡量进展。 仅凭公告措辞无法证明任一结果。最有力的证据应将具体防护措施与可观察的变化联系起来。

首先，关注是否有记录在案的 Claude Code 发布版本改变敏感审批的存储方式。决定性细节在于，当原本合法的命令包含认证材料时会发生什么。发布说明应解释生成的记录，以及仍需用户干预的情形。

若证据表明人工密钥不再出现在已保存的审批记录中，将增强这是一项有意义产品改进的判断。若证据表明同样的值仍会出现在替代权限路径中，则会缩小这一结论。两种结果都比笼统宣称自动化更安全更有信息价值。

测试范围与标题所描述的行为同样重要。全新项目与已有被跟踪设置文件的仓库代表不同的起始条件。清晰的说明应明确该防护覆盖哪些条件。

其次，关注能够证明覆盖代理配置和嵌入命令凭据的仓库控制。这包括明确的排除策略和经过测试的密钥检测。关键结果是，尝试发布时是否会被阻止，或被导入有效审查流程。

仅有策略文件仍无法确定执行情况。受控演练若显示人工凭据会触发预期响应，将提供更有力的证据。反复漏检将削弱对扫描作为补偿性控制措施的信心。

这一信号对竞争对手同样重要。供应商可以用不同方式描述执行环境，但仍需要解释其保留的工件。对生成文件、共享边界和凭据处理作出清晰说明，将使比较对采购方更有价值。

第三，关注将已移除文件与已失效凭据区分开来的修复报告。仓库外观很容易观察，而访问是否持续则需要来自负责服务的信息。可信的后续报告应将这两类结果分开。

Apiiro 的结果尚未在此独立复现，其收集结果也不应被视为所有 Claude Code 项目的随机样本。所报告的人群由可公开发现的文件组成。这限制了对更广泛用户群体中暴露普遍程度的结论。

这些限制并不影响核心工程关切。保存操作上下文的功能需要针对敏感数据制定清晰策略。用户应能理解该策略，而不必在截止期限内通过重构实现细节来弄清楚。

对于评估 Claude Code 密钥泄露的团队，应从你的工作流实际生成的审批记录开始。使用人工凭据检查哪些内容会持久化，然后验证哪些控制措施能阻止这些材料进入共享仓库。在真实暴露迫使团队处理前，先明确所有权。将发现结果保留为同事无需复现敏感值即可遵循的流程。当真实凭据出现在共享材料中时，应让负责服务的所有者首先确认其剩余权限。要求供应商提供同时涵盖存储与执行的证据。下一次最有价值的审查，应回答一个具体问题：获批任务完成后，还残留哪些敏感信息，谁能够获取它们？