When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls
本文揭示了 Claude Code 中存在的一个关键安全漏洞，即 CLAUDE.md 文件中自然语言形式的“不要做”指令往往缺乏相应的内置拒绝控制，仅有 4.4% 到 16% 的提取规则具有可执行的匹配项，导致开发者无法得知其安全规则是否真正得到了执行。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
在现代软件创作的世界中，一种新型的助手已经出现：编码智能体（coding agent）。这些是能够像人类开发者一样编写代码、修复漏洞和管理文件的人工智能程序。为了让这些数字助手保持安全并走在正确的轨道上，开发者会为它们编写指令文件。可以将这些文件想象成一套书面规则，就像食谱或行为准则一样，由人类告诉智能体它被允许做什么，以及它绝对不能做什么。开发者可能会写下：“严禁以明文形式保存密码，”或“在删除重要数据前先询问。”多年来，这种提供指令的方法一直是引导这些智能工具的标准方式。人们一直假设，如果你写下的规则足够清晰，智能体就会理解并遵循它，从而创建一个安全的软件构建环境。
然而，研究人员丁延（Ting Yan）最近的一项研究揭示了这一系统中一个隐蔽但显著的差距。该研究聚焦于一种用于流行编码智能体 Claude Code 的特定指令文件。研究提出了一个简单但至关重要的问题：当开发者用纯英文编写一条安全规则时，软件内部是否真的拥有执行该规则的内置机制，还是说这条规则仅仅是一个人工智能需要去猜测如何遵循的建议？研究结果表明，对于绝大多数此类书面规则而言，答案是后者。该文件就像一条单行道，开发者在说话，但系统从未确认规则是否得到了执行。这创造了一种虚假的安全感，即开发者认为某个危险操作已被拦截，而实际上，系统只是依赖人工智能去记忆并遵守该指令，并没有任何硬性停止机制在起作用。
为了了解这一问题的规模，研究人员收集了来自世界各地开发者的近五百份公开指令文件。他们将这些文件视为一堆手写笔记，逐行扫描以寻找听起来像是安全规则的句子。他们寻找诸如“不得”（must not）、“绝不”（never）或“不要”（do not）之类的短语，这些词汇标志着一种限制。通过这些文件，他们提取出了数千条候选规则。下一步是充当人类语言规则与软件技术语言之间的翻译官。他们询问特定的编码智能体 Claude Code 是否已经拥有内置的开关或设置，可以自动拦截规则中所描述的行为。例如，如果规则说“不要运行这个特定的命令”，研究人员会检查软件是否有一个权限设置，可以简单地在命令发生前拒绝该命令。如果软件没有这样的开关，那么这条规则就留给了人工智能去解读，这意味着智能体必须自行决定是否遵循该指令。
两者的对比结果是触目惊心的。当研究人员应用严格标准——要求内置控制必须覆盖所写规则中的确切动作、确切目标和确切条件时——只有极小部分的规则拥有匹配的安全机制。具体而言，他们发现开发者编写的这些安全规则中，只有约百分之四到六得到了能够无需额外工作即可执行其功能的内置控制的支持。即使采用较宽松的标准（允许部分匹配），该比例也仅上升到约百分之十六。这意味着，在这些文件中编写的安全性规则中，大约有百分之九十五没有自动化的安全网。规则仅作为文本存在，完全依赖人工智能每次都能正确解读。
研究还探讨了为什么这么多规则缺乏匹配。研究人员发现，规则往往要求做一些软件内置工具根本无法察觉或无法完成的事情。一条规则可能会说：“严禁将敏感信息提交到代码库中”，但软件的权限设置可以拦截文件路径或命令，却无法拦截文件内部的实际内容。要执行关于敏感信息的规则，软件需要读取文件并理解其中的内容，而这正是其标准设置无法完成的任务。同样，一条规则可能要求检查系统的状态或获得特定人员的批准，而内置控制无法访问这些细节。在这些情况下，规则不是一个软件可以执行的命令，而是对人工智能运用判断力的请求。研究人员指出，这种区别对开发者来说是不可见的。无论规则是被硬性的系统锁执行，还是由人工智能那易错且软弱的记忆来执行，指令文件的外观都是一样的。
这种缺乏反馈的情况造成了研究人员所称的“只写不读”通道（write-only channel）。在大多数软件开发中，当开发者编写一条规则时，会得到即时反馈。如果他们编写的代码违反了规则，计算机可能会拒绝运行，或者测试会失败，立即告知他们出错了。使用这些指令文件时，却没有任何此类信号。开发者可以写下一条规则，然后继续后续工作，却永远不知道智能体是否真的在遵循它。研究强调，对于新手开发者来说，这尤其危险。他们可能会写下一条规则，以为自己已经加固了系统，却没意识到系统其实根本无法强制执行该特定限制。人工智能可能会在大多数时候遵循规则，但也可能出错、产生困惑或被其他输入误导，从而留下安全隐患。
研究人员并未认为软件本身存在故障，也没有认为开发者在做错事。相反，他们指出这是这些工具与用户沟通方式中的设计缺陷。这些工具允许用户使用自然语言编写规则，这既简单又直观，但它们并未告知用户哪些规则实际上是由系统强制执行的，哪些仅仅是建议。研究表明，为了使这些工具真正安全，它们需要闭合这个环路。它们需要为开发者提供一种方式，让他们看到哪些规则是由硬性控制支撑的，哪些则不是。理想情况下，如果开发者写下一条系统无法执行的规则，软件应当发出警告，或者帮助他们将该规则转化为系统可以实际使用的设置。直到这个反馈环路闭合之前，这些系统的安全性将高度依赖于一种希望——即希望人工智能能完美地记住并服从每一条指令，而数据表明，这种希望往往是难以实现的。
研究结论强调，这是一个可以解决的问题，但它需要改变这些工具的构建方式。开发者所写的规则与系统所执行的规则之间的差距并非谜团，而是一个可衡量的客观事实。通过测量这一差距，研究人员证明了目前保障这些智能体安全的方式是不完整的。解决方案在于让“不可见”变为“可见”，确保当开发者编写一条规则时，他们确切知道这条规则提供了何种程度的保护。这将把指令文件从一份单向的便条转变为一场双向的对话，通过这种方式，系统可以确认规则不仅是被写了下来，而且确实在发挥作用。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。