Anthropic Google 安全缺口：AI Agent 沿可信文档进入无主代码

研究人员报告称，编码 Agent 执行了可信企业文档中引用的软件包，Anthropic 和 Google 因此卷入一场安全争议。据称，其中一个测试软件包在四分钟内便在一家《财富》500 强企业的环境中运行。研究人员表示，后续的进程记录中出现了 Claude、OpenAI Codex 和 Nous Research 的 Hermes。

这一发现并不表明 Anthropic、Google 或 OpenAI 故意传播了恶意软件。为实验注册的大多数软件包都只包含无害的信标代码，仅在运行时回传信息。更严重的发现，是一个与认证服务商 Clerk 网站上曾发布指令有关、据称带有恶意行为的无关 npm 软件包。

这一区别很重要，因为最初报道听起来可能像是三家 AI 供应商入侵了企业网络。但证据实际指向的是软件供应链失效。Agent 信任了看似官方的指令，访问公共软件包注册表，并执行了无人确保归属的名称。

Google 之所以进入这起 Anthropic Google 安全事件，是因为其网站审计软件 Lighthouse 支持检查 llms.txt 文件。Claude 和 Codex 则是通过据称遵循安装指令的 Agent 被牵涉其中。共同的问题并非某一个模型或某一家公司，而是文档与可执行操作之间的边界正在消失。

这种边界过去看起来很清晰。开发者可以阅读设置指南、验证软件包，并决定是否安装。自主编码 Agent 则可以将这些步骤压缩为一次操作，往往还会使用开发者已有的权限。

因此，每个部署编码 Agent 的组织都面临一个新的安全问题：当软件读取一份文档时，谁来验证该文档是否仍指向可信对象？

企业 AI Agent 执行了无人拥有的名称

研究人员将陈旧文档变成了可执行的证据，证明可信文本可能成为入口。

安全研究员 Alon Hertz 及其同事审查了 6,214 个在线域名上的机器可读文档。其样本包括国防承包商、大型科技公司和《财富》500 强企业。

研究人员称，他们发现了 8,265 个 llms.txt 和 llms-full.txt 文件。llms.txt 是一种新兴约定，用于为语言模型和 AI Agent 整理网站内容。其更大的配套文件可以在单个机器可读文件中提供更广泛的文档。

据称，在收集到的文件中，有 120 个网站引用了至少一个未注册的软件包或无人认领的域名。该团队统计出 227 条涉及不存在的软件包或目标位置的命令。

这些不一定是恶意指令。其中一些似乎只是普通安装命令，却指向了从未注册的软件包名称。另一些则引用了已过期的域名或不再被认领的服务。

当软件包名称可在 PyPI 上注册时，一行如 pip install package-name 的命令就会变得危险。同样的原理也适用于 npm、RubyGems、NuGet、crates.io、Packagist，或被遗弃的托管子域名。

研究人员注册了少量这类可用名称，随后发布了包含特定代码的软件包，使其在被执行时连接到研究人员的服务器。Hertz 的研究记录称，首个回连在四分钟内便来自一家《财富》500 强企业环境。

据称，在第一个小时内，还有两个系统执行了这些代码。随着时间推移，该团队从初创企业和大型企业收到了数十次回连。

回连记录了父进程链，用于识别启动某个进程所涉及的程序。研究人员称，这些记录将部分安装行为与 Claude、OpenAI Codex 和 Nous Research 的 Hermes 联系起来。

该实验并不需要攻破这些模型，也不依赖新发现的软件漏洞、钓鱼信息或被盗的员工密码。据称，这些 Agent 在合法网站上找到已发布的指令，并利用其环境中可用的权限执行了这些指令。

这正是核心的反转。企业文档通常通过展示开发者获准配置软件的方式来增强安全性。但在这里，文档中的废弃引用让他人有机会定义获准命令实际会执行什么。

这一发现同样需要谨慎表述。研究人员尚未公开受影响企业的身份、披露全部软件包名称，或提供足以让外部人士复现每一项企业归属判断的遥测数据。原始报道发布前，Anthropic、OpenAI 和 Nous Research 均未置评。

即便存在这些限制，该实验仍展示了一种可信机制。公共软件包注册表会将一个名称的含义交给控制该名称的人。官方文档可以在其原本含义消失很久之后，继续保留这个名称。

Anthropic Google 信任链为何失效

这些 Agent 并未无视信任模型，而是遵循了一个已不再适配自主软件运行方式的信任模型。

传统文档默认在指令与执行之间存在一名人类读者。该读者可以注意到奇怪的软件包名称、检查其发布者，或追问为何某条设置命令没有配套代码库。

Agent 也可以执行相同检查，但前提是其指令和环境要求它们这样做。否则，它会以完成被请求任务为目标进行优化。找到官方文档并运行其中的安装命令，看起来可能是最短的有效路径。

Anthropic Google 的关联凸显了多个各自合理的决定如何组合成一条高风险链路。网站发布机器可读指南；Google 的 Lighthouse 工具鼓励开发者让这些指南可被发现；编码 Agent 搜索权威上下文；软件包管理器则让依赖项易于获取和执行。

这些组件本身都不需要带有恶意。危险出现在 Agent 将整条链路都视为已验证身份时。

Google 的 Lighthouse 指南介绍了一项针对 llms.txt 可用性和格式的审计。Lighthouse 不会认证文件中每条命令或每个依赖项。因此，通过格式审计并不能说明软件包归属、发布者身份或代码安全性。

同样，HTTPS 只能证明文件来自浏览器连接中显示的域名，并不能证明每个被引用的软件包仍属于该域名的运营者。

公共注册表也可能从攻击者控制的账户中提供拼写完全正确的软件包。这与经典的拼写抢注不同；在后者中，攻击者注册与热门软件包相似的拼错名称。据称，本次实验中的名称直接复制自官方文档。

这会让这些指令对 Agent 和人类都更具说服力。审查终端记录的开发者可能看到官方域名、熟悉的软件包管理器以及看似合理的依赖名称。每一个可见信号都可能显得寻常。

Agent 的搜索行为进一步加剧了这个问题。用户在请求集成时可能只提到某个供应商。Agent 可以定位该供应商的文档，发现 llms.txt，选择一条安装命令，并调用软件包管理器，而无需从用户那里收到可疑链接。

这正是为何该事件的影响范围超出提示注入。提示注入通常涉及敌对内容试图改变 Agent 的行为方向。这里的指令本身可能无害，且在历史上确实合法。安全失效发生在之后：被引用目标的所有权发生变化，或其所有权从未存在。

新兴的 llms.txt 约定也不等同于拥有既定安全架构的正式 Web 标准。它的价值在于为模型提供简洁、结构化的上下文。而这种便利同样可能将操作指令集中在 Agent 被鼓励信任的位置。

因此，Anthropic Google 安全缺口本质上是一个溯源问题。溯源指的是能够证明某个制品来自何处、由谁控制的证据。Agent 验证了文档所在的位置，却显然没有为命令背后的可执行依赖建立溯源关系。

真正的对手是缺乏溯源的自主执行

决定性的冲突不是 Claude 对 Codex，而是自主执行对已验证的软件所有权。

Claude、Codex 和 Hermes 使用不同的模型、界面和权限系统。若将此次事件简单视为这些工具之间的比较，就会忽略已报道安装行为背后共同的运行条件。

每个编码 Agent 都可以读取项目上下文、查阅文档、编辑文件和调用开发工具。这些能力之所以让 Agent 有用，是因为它们消除了研究与执行之间的手动切换。

但它们也将一项安全决策移入了 Agent 的工作流。必须有人决定某个依赖项是否真实可信、其版本是否可接受，以及其安装脚本是否应当运行。

软件包管理器会在安装过程中例行执行代码。npm 软件包可以定义生命周期脚本，而 Python 软件包可以通过其构建流程执行与安装相关的行为。具体行为各有不同，但安装并不等同于下载惰性文本。

Clerk 的案例说明了这一点。研究人员发现，Clerk 的合法网站上的一个指令文件引用了 npx clerk-next-fix-auth-protection。npx 工具可下载软件包并执行其公开命令，而无需将其永久添加到项目清单中。

根据这项安全调查，有人已认领该软件包名称，并用它传播活跃恶意软件。Clerk 后来修正了文档。

目前仍不清楚该软件包是否通过 AI Agent 导致感染。报道还指出，来自 Clerk 合法 ESLint 插件的一个现有二进制文件是安全的。缺少该合法二进制文件的机器，则可能转而获取攻击者控制的软件包。

这种差异足够微妙，可能逃过匆忙审查者的注意。两条路径都始于真实供应商发布的一条命令，也都使用 npm 基础设施。危险路径取决于预期的二进制文件是否已存在于本地。

这正是企业面临的现实权衡。Agent 在无需每条命令都等待批准的情况下解决依赖、运行测试和修复故障时，能提供更高价值。而同样的权限也会让一次错误的信任决策演变为代码执行。

模型供应商可以通过沙箱和审批机制降低这一风险。企业仍必须配置这些控制措施、维护网络策略，并决定 Agent 可以访问哪些软件包来源。

软件供应商拥有问题的另一部分责任。其文档已成为运营资产，而不再是静态营销内容。软件包引用、示例域名、被复制的命令以及归档的设置页面，如今都需要像可执行代码一样进行生命周期管理。

注册表运营方也会影响结果。命名空间预留、发布者验证、可疑软件包扫描以及所有权历史记录都能有所帮助。然而，注册表并不总能知道某个无人认领的名称出现在第三方文档中。

这种责任划分使得简单归咎于某一方没有帮助。Anthropic Google 的叙事之所以重要，是因为它跨越了产品边界。搜索或文档工具可以让说明更容易被找到，AI agent 可以对其进行解读，而注册表则可以提供被点名的构件。

当每个参与方都假定另一个参与方已验证所有权时，安全就会失效。

现有的 agent 防护措施并不能消除风险

Claude 和 Codex 已经提供了有意义的控制措施，但这些措施只有在组织维持其限制性边界时才能发挥作用。

Anthropic 的 Claude 安全指南将提示词注入描述为试图操纵助手指令的恶意文本。该指南还记录了权限控制，以及对检索任意网页内容的命令所施加的限制。

Claude Code 可以通过沙箱限制文件系统和网络访问。子进程会继承这些操作系统层面的限制，这有助于防止获准执行的命令悄然逃逸到限制更少的进程中。

OpenAI 描述了类似的分层方案。其 Codex 安全模型结合了沙箱边界、审批策略、受管网络访问、规则以及面向 agent 的遥测能力。

OpenAI 表示，其受管部署不会向 Codex 提供不受限制的出站访问。预期目标可以被允许，陌生域名可以要求审批，安全团队则可以导出涵盖提示词、工具调用、审批和网络决策的日志。

这些防护措施很重要，但并不会自动推翻研究人员的发现。组织可以将 agent 配置为拥有更广泛的访问权限。开发人员可以批准命令。本地安装可能会继承运行它们的用户所拥有的权限和网络连接能力。

软件包注册表在许多开发环境中也是预期目标。完全阻断对 npm 或 PyPI 的访问，会干扰日常构建、依赖更新和测试设置。允许这些域名，会移除一个可用于识别恶意安装行为的明显网络信号。

终端检测与响应软件也面临类似挑战。一个编程 agent 启动标准软件包管理器，后者通过加密连接访问知名注册表。在下载的软件包执行明显恶意的行为之前，这一过程可能都与正常开发活动无异。

研究中的信标被刻意设计得极为简约。据报道，它会联系一台服务器并记录执行上下文。真正的攻击者可能会尝试窃取凭据、探测环境、建立持久化机制，或修改源代码。

然而，公开证据并未显示实验性软件包执行了这些操作。它也没有证明数十家公司遭受了生产环境入侵。它们执行的是概念验证代码，这固然严重，但范围比已确认的数据泄露更窄。

这种审慎的区分应当塑造企业的应对方式。团队不应假定每一次使用 Claude、Codex 或 Hermes 都会导致感染。他们应识别这条路径得以成立所需的条件。

agent 需要能够访问相关文档。它需要有权调用软件包管理器。环境必须允许从注册表获取内容。软件包必须执行有意义的代码，而现有控制措施还必须未能遏制其行为。

移除任何一个条件，都可能中断这条链路。限制网络访问是一种选择。要求对依赖安装进行人工审批是另一种选择。在一次性容器中运行 agent，则可以在软件包确实执行时限制后果。

组织还可以强制使用内部依赖代理。该代理可以允许已获批准的软件包和版本，同时拒绝未知命名空间。这种方式将信任决策从阅读公开文档的 agent 手中转移出来。

当审批提示只展示一条熟悉的命令时，其可靠性较低。审核者需要了解软件包所有权、存续时间、发布者身份、下载历史，以及该依赖是否出现在已批准的软件物料清单中。

教训并非防护措施毫无用处，而是围绕明显恶意命令设计的控制机制，可能会漏掉那些解析到不可信所有权的合法命令。

文档如今属于软件供应链的一部分

企业必须将文档中的每一项可执行引用视为一种可能过期、漂移或变更所有者的依赖。

即时响应应从盘点开始。组织应在 llms.txt、llms-full.txt、开发者门户、归档指南、代码示例、支持文章和自动生成的 API 参考资料中搜索安装命令。

每个被引用的软件包、域名、代码仓库、容器镜像和托管子域名都需要有明确所有者。在调查进行期间，任何无人识别的名称都不应继续公开存在。

团队应验证公开的软件包名称是否与组织实际的注册表账户相匹配。他们还应检查：在旧文档中出现全局、非作用域名称时，是否有相应的作用域软件包可用。

文档流水线需要自动化测试。构建过程可以验证每个软件包是否存在、是否属于获批准的发布者、是否解析到预期代码仓库，以及其所有权是否发生变化。

仅做链接检查并不足够。恶意软件包或被重新认领的域名也可能返回成功响应。流水线必须验证身份，而不只是可用性。

公司应在发布文档前预留名称。这类似于围绕重要产品注册防御性域名，但软件包命名空间需要持续维护。

同样的原则也适用于项目退役时。移除一个软件包却不移除其安装说明，会造成所有权缺口。放弃一个托管子域名却保留指向它的链接，可能让另一方继承一条受信任的路径。

AI 生成的文档值得额外审查，但人工编写的页面同样不能豁免。研究人员发现，一些存在疑问的引用早于当前的 agent 时代。将这些页面复制到 llms-full.txt，会让自主软件更容易吸收旧有错误。

部署 agent 的企业需要配套的控制平面。agent 会话应在专用身份下运行，而不是使用开发人员不受限制的账户。凭据应限定在当前代码仓库和任务范围内。

软件包安装应在隔离环境中进行，并且对机密信息的访问应受到限制。如果某个依赖在安装期间需要网络访问，这种访问应当明确且被记录。

团队应将 agent 的推理上下文与操作系统遥测数据一并保留。进程日志可以显示 npm 已启动，而 agent 原生记录则可以显示是哪份文档提供了软件包名称。

这一上下文在事件响应期间至关重要。调查人员需要区分已获批准的项目依赖，与 agent 浏览外部说明后选择的软件包。

依赖允许列表可以降低风险，但需要为新软件包提供例外路径。该例外流程应收集来源证据，并要求指定一名人类所有者。

组织还应维护一份可搜索的记录，涵盖 agent 查阅的来源。这可以包括文档快照、软件包元数据、审批决策和生成的代码变更。受控的技术知识库可以帮助审核者还原 agent 为何选择某个依赖。

更广泛的教训不限于 llms.txt。编程 agent 会消费问题描述、代码仓库文件、搜索结果、软件包文档、Model Context Protocol 响应以及生成的内部指南。

任何这些来源都可能包含一条指令。如果 agent 拥有工具，这条指令就可能变成行动。

这使文档完整性成为软件供应链安全的一部分。企业不能只保护源代码仓库和构建服务器，却让机器可读的指令处于其控制范围之外。

三个信号将表明行业是否吸取了教训

下一阶段取决于文档、agent 权限和注册表身份是否能够同步改进。

第一个信号是 120 个受影响网站的披露与修复。Hertz 的团队表示已联系受影响组织及相关安全团队，但公开记录并未列出大多数域名。

关注企业是否审计 llms.txt 文件、预留软件包名称，并发布事件通知。协调一致的清理行动将强化这样一种观点：行业已认识到机器可读文档是安全敏感的基础设施。

沉默并不能证明没有进行修复。许多组织会在不公开披露的情况下修复暴露的引用，尤其是在研究人员使用了无害代码且未发现已确认的数据窃取时。

第二个信号是 agent 供应商推出产品层面的来源验证。Claude、Codex 和 Hermes 已经可以在执行命令前请求批准，但当界面解释命令背后的依赖时，审批才会更有价值。

有意义的变化包括：警告某个软件包是新发布、未经验证、与供应商已知发布者账户无关，或不在项目现有依赖图中。更强的系统可以要求：只要公开文档指向一个未被识别的软件包，就必须获得明确批准。

这样的功能会强化 Anthropic Google 的安全应对，因为它会在执行之前处理决策点。另一项针对 shell 命令的通用警告，提供的保护会更少。

第三个信号是注册表与企业策略的集成。软件包管理器和内部代理可以公开发布者历史、命名空间存续时间、签名状态和所有权变更。agent 平台可以在选择或安装依赖之前使用这些元数据。

企业策略可以自动允许成熟的软件包，同时将不熟悉的软件包隔离出来供审查。它还可以拒绝名称出现在官方文档中、却与发布者缺乏可验证关联的软件包。

如果可靠的来源验证能够阻断多个 agent 的攻击路径，这一信号将削弱研究人员更广泛的警告。反之，如果 agent 在已有身份数据的情况下仍持续安装新近认领的名称，则会强化他们的警告。

当前证据支持一个审慎的结论。研究人员据称在真实企业环境中演示了代码执行，并将部分活动与知名编程 agent 联系起来。他们并未证明模型供应商有意安装恶意软件，也未证明每一次报告的回调都代表严重入侵。

更重要的发现是结构性的。受信任文档、自主执行和公共注册表如今构成了一条供应链，而许多安全计划尚未将其纳入盘点。

开发人员和企业采购方在扩大 agent 权限之前，应提出直接的问题。agent 能否访问公共软件包注册表？它是否验证发布者身份？安装命令是否在隔离环境中执行？安全团队能否还原是哪份文档导致了某项操作？

Anthropic 与 Google 之间的安全缺口，无法仅靠改进模型行为来弥合。文档所有者、注册表、代理供应商和企业管理员分别掌控着链条中的不同环节。

在赋予编码代理更广泛的自主权之前，先用一个未被识别的依赖项测试这条完整链路。如果代理在未展示来源信息的情况下就安装了它，说明该环境将文档视为权威，而非证据。