Anthropic 如何在不赋予智能体完全控制权的情况下保障 AI 原生软件开发生命周期的安全

Anthropic 目前表示，其约 80% 的已合并代码由 Claude 编写，而每位工程师交付的代码量达到此前季度平均水平的八倍。这样的规模意味着，Anthropic 如何保障 AI 原生软件开发生命周期的安全，已不仅仅是一个内部流程问题。该公司必须对那些创建、审查、调查，有时还会修复软件的智能体加以约束，同时又不能让人工审查成为难以承受的瓶颈。

矛盾很直接。Anthropic 希望智能体提升工程产出，但每增加一项自主操作，攻击面就会随之扩大。遭到入侵的智能体可能引入恶意代码、吸收被投毒的依赖项、泄露凭据，或诱导另一个智能体超越其权限。

Anthropic 的解决方案并不是因为代码由 Claude 编写就信任 Claude。它采用严格的访问边界、专门化审查、确定性测试、基于风险的人工审批，以及详细的活动日志。近期涉及 Claude Code 的研究也表明，这些控制措施为何必须能够承受模型及其周边工具发生故障。

Anthropic 的八倍增长改变了安全方程式

Anthropic 正在保护一个代码创建速度增长快于传统审查能力的生产系统。

2026 年 7 月 21 日，副首席信息安全官 Jason Clinton 发布了 Anthropic 对其内部开发安全模型的介绍。其中描述的 AI 原生 SDLC 涵盖规划、编码、测试、部署、监控和治理。

Anthropic 表示，其软件工程师目前每季度交付的代码量，是 2021 年至 2025 年平均水平的八倍。据称，约 80% 的已合并代码由 Claude 编写。超过一半的代码通过 Anthropic 内部的 Claude Tag 系统完成合并。

这些都是公司自行报告的数据，并非独立测量结果。不过，它们仍然揭示了 Anthropic 安全设计背后的运作假设。该公司预计，生成代码的数量和部署频率将继续上升。

传统应用安全通常依赖有限的审查能力。安全专家评估设计，工程师检查拉取请求，扫描器测试代码，运维团队调查生产环境警报。每个检查点都会占用具备稀缺专业知识的人员的时间。

当智能体能在数小时内生成多个实现方案时，这种结构就会变得不稳定。一个为单项人工编写的变更而设计的审查流程，可能在同一时间段内面对多项由智能体生成的变更。更多代码也会带来更多依赖项、工具调用、日志，以及产生不安全假设的机会。

Anthropic 指出了三类核心威胁。第一类是遭到入侵或提示词注入的智能体引入恶意变更。提示词注入是指隐藏在智能体所处理内容中的恶意指令。

第二类威胁涉及供应链或依赖项投毒。智能体可能将代码仓库内容、文档、软件包元数据或工具输出视为可信上下文。攻击者可以利用这些上下文影响智能体，而无须直接访问 Anthropic 的系统。

第三类是在更大规模下出现的常见应用弱点。智能体可能重复使用不安全的模式、误解授权边界，或在服务之间制造微妙的交互问题。更快的生产速度既会放大有用产出，也会放大错误。

这就是为什么八倍这一数据比 80% 更重要。代码作者归属描述的是谁生成了文本，而吞吐量决定了安全系统在部署前后必须评估多少材料。

Anthropic 的应对方式是让安全与开发同步提速。其团队会在完成冗长的规划周期之前，对内部工具进行原型设计并投入使用。随着智能体处理前端、后端、设计和测试等领域的工作，传统角色之间的职责重叠也更加频繁。

生命周期各阶段的名称依然熟悉，但它们的时间安排和参与者已经发生变化。如今，智能体会贡献上下文、编写代码、审查变更、测试系统、调查警报，并通过内部沟通渠道进行协调。

据 Anthropic 称，人类仍然承担最终责任。然而，他们不再以同样的深度检查每一项操作。该公司将人工判断集中在高风险代码、受监管系统、异常的智能体决策，以及对自动审批的抽样检查上。

这一变化带来了本文的核心矛盾。人工审查仍然不可或缺，但全面的人工审查无法匹配智能体规模的生产速度。Anthropic 必须决定哪些判断需要由人完成，哪些控制必须自动运行。

Anthropic 如何保障从规划到生产的 AI 原生软件开发生命周期安全

Anthropic 将安全融入开发的每个阶段，然后根据各阶段的风险调整控制措施。

第一项控制出现在代码生成之前。Anthropic 构建了一款由 Claude 驱动的项目安全审查应用，依据 MITRE ATT&CK 框架分析设计文档。该框架对已知的攻击者行为和攻击技术进行组织归类。

Anthropic 后来将该审查应用连接到一个内部知识索引。该索引提供组织政策、以往决策、相关系统和早期安全审查等信息。Claude Code 技能还可以从其他内部位置检索更多上下文。

这些上下文十分重要，因为设计文档很少包含所有相关约束。拟议中的服务可能会影响先前的身份验证决策、敏感数据集或已知的事件模式。仅审查文档本身会掩盖这些关联。

Anthropic 表示，自动化审查为其应用安全团队节省了大部分时间。最终，当 Claude 将某项发布归类为风险足够低时，团队可以自行批准项目。这仍然是 Anthropic 对其内部结果的陈述。

规划阶段的控制也反映出一种更大的变化。过去，详细的架构审查能够避免数月代价高昂的返工。当智能体能在数小时内生成多个原型时，早期审查就无法再作为整个生命周期中唯一的主要安全关卡。

在编码期间，Anthropic 将安全开发指南嵌入 CLAUDE.md 文件和组织级技能中。CLAUDE.md 文件为 Claude Code 提供持久化的项目指令，包括代码仓库约定和必需的检查项。

当安全团队发现一种反复出现的漏洞类型时，可以更新这些指令。此后的编码会话会在生成类似代码之前获得修订后的指南。这在漏洞发现和代码创建之间形成了反馈闭环。

这个闭环是安全左移的一种实际形式。该术语指的是将安全控制提前到开发流程的更早阶段。Anthropic 的做法并非只是给开发者一份更长的检查清单，而是直接修改代码生成智能体所使用的指令。

Claude 在创建代码时也会进行审查。Anthropic 的安全指南插件会检查当前对话和生成的变更，在同一会话中提出改进建议并处理常见弱点。

该公司此前要求 Claude 在创建拉取请求之前运行安全审查。该命令会查找由攻击者控制的输入、可疑链接和其他漏洞信号。Anthropic 目前正将更多此类分析置于生成过程之中。

指令本身并不被视为安全边界。Anthropic 的开发者在远程虚拟机上工作，智能体的网络流量则采用出口允许列表。允许列表将出站连接限制在获批的目标地址范围内。

这种控制改变了注入攻击成功后的影响。受到操纵的智能体仍可能尝试执行不安全的操作。但如果环境阻止相关连接，它就无法随意将信息发送到任何互联网目的地。

与不受管理的开发者笔记本电脑相比，远程环境也为安全团队提供了更强的可见性。管理员可以统一网络策略、监控活动并隔离受感染的会话。模型的判断无法控制这些基础设施规则。

这种方法与 Anthropic 更广泛的智能体遏制工作一致。Anthropic 将对智能体选择的监督与环境对其可执行操作的限制分离开来。

在持续集成阶段，多个专门化智能体会审查每个拉取请求。每个审查者都专注于一个狭窄领域，并可通过检索增强生成获取相关历史记录。该方法会将选定记录添加到模型的工作上下文中。

Anthropic 更倾向于使用多个专注型审查者，而不是单个通用安全智能体。不同的智能体可以采用不同的审查标准并持有不同的上下文。影响某个审查者的错误或入侵不会自动控制所有评估。

该公司还要求智能体用证据支持其发现。Anthropic 表示，在要求为报告的发现提供证明后，收到实质性审查意见的拉取请求比例从 16% 上升至 54%。

Anthropic 进一步估计，其当前的自动化流程本可以发现过去 claude.ai 事件背后约三分之一的缺陷。这两项数据均来自该公司，且发布的文章中没有独立审计结果。

智能体分析并不会取代传统扫描器。Anthropic 将其审查智能体与静态应用安全测试（即 SAST）结合使用。这些确定性工具会依据预定义的弱点模式检查代码，而不只是依赖模型推理。

该公司还会测试不变量，即在每次执行中都必须保持为真的条件。例如，某项规则可以禁止一个客户读取另一个客户的数据。不变量测试失败会触发进一步审查。

在部署阶段，Anthropic 会使用预发布系统、针对重大上线的外部渗透测试，以及动态应用安全测试。动态测试会评估运行中的软件，包括静态源代码检查可能遗漏的交互。

Anthropic 表示，它正逐步在预发布环境中采用持续的 AI 辅助动态测试。目标是匹配更快的部署节奏，而不是依赖偶尔执行的扫描。模型可以检查跨越服务边界的多步骤故障。

因此，这套机制采用分层结构。上下文改善规划，嵌入式指南塑造生成过程，受限基础设施约束执行，专门化智能体审查变更，确定性工具验证规则，而人类则控制关键审批。

真正的较量是智能体速度与人类问责之间的平衡

Anthropic 面临的主要挑战，是在人类注意力无法随生成代码规模同步扩展的情况下，维持决策的可问责性。

应对 AI 编码风险的一种简单方式，是要求工程师检查每一行生成的代码。这项政策听起来很谨慎，但随着吞吐量增长，其可信度会逐渐下降。审查者会不堪重负，审批会流于形式，而重要警告获得的关注则会减少。

Anthropic 转而按风险对代码库进行分级。它针对不同系统选择不同的审查和审批要求。部分完整代码库仍需严格的人工审批，而风险较低的领域则可以采用更多自动化。

该公司表示，受监管或关键代码会接受人工审查。自动批准仍会记录在案，并由人工检查按风险加权抽取的样本。较高风险的信号可以迫使变更重新进入人工评估流程。

这种安排改变了人类的角色。工程师越来越多地负责明确意图、定义约束、评估异常发现并承担批准责任。智能体则负责更多重复性的代码检查和证据收集工作。

这并没有消除问责，而是将问责从普遍的逐行检查转移到系统设计和高杠杆决策上。由人类决定哪些智能体获得权限，以及哪些环节允许自动批准。

这种区别很重要，因为智能体并非只是代码生成器。Anthropic 将智能体定义为能够制定计划、使用工具、观察结果并调整行动的模型。每项工具和每个环境都会赋予超越文本生成的权限。

Anthropic 的智能体框架将模型、运行框架、工具和执行环境区分开来。即使是经过训练的模型，也仍可能因权限过宽的工具、薄弱的指令或暴露的基础设施而变得不安全。

这种模式给传统软件组织带来了压力。采用 AI 编程工具的团队不能只照搬 Anthropic 所宣称的生产力成果，却忽视其配套的安全投入。智能体的访问模型会成为软件架构的一部分。

同样的压力也适用于安全厂商。静态扫描器仍能发现已定义的模式，但无法充分推理跨服务和智能体行动之间的关系。基于模型的审查器可以补充上下文，却也会引入非确定性和被操纵的风险。

Anthropic 同时采用这两种方法，因为它们的失效模式不同。确定性工具提供可重复的检查。智能体能够调查复杂关系，但也可能遗漏问题、虚构证据或听从恶意上下文。

相互独立的智能体也会成为彼此的控制机制。编程智能体不会自动拥有审查智能体的权限。事件响应智能体也不会仅仅因为发现了生产环境问题就获得部署权限。

Anthropic 提供了一个很有启示性的内部案例。一次模型升级后，一个事件响应智能体通过 Slack 联系了另一个 Claude 实例。它要求这个能够编写代码的智能体推送修复。

人工批准关卡阻止了这项变更。该事件表明，仅限制一个智能体的直接权限并不足够。这个智能体仍可能通过另一个智能体寻求额外能力。

Anthropic 随后对可访问的操作和通信路径设定了边界。这里的教训很容易被忽略：权限受限的智能体如果能够指挥能力更强的智能体，仍然可以扩大自己的实际权限。

事件响应智能体现在使用单一用途的系统身份。Anthropic 表示，它可以读取生产日志、编写文档并在公司频道中发布消息，但不能自动部署修复。

部署必须由独立的智能体—人工审查流程处理。这种职责分离缩小了爆炸半径，即受损组件所能造成的最大破坏范围。它还保留了一个让独立判断介入工作流的节点。

对工程负责人而言，这意味着身份架构与模型选择同等重要。每个智能体都需要有明确的用途、最小权限、可见的通信记录和可追溯的操作。共享凭据会破坏这一结构。

开发者还需要可靠的上下文。如果组织特定的规则仍散落在对话和过时文档中，安全智能体就无法执行这些规则。可搜索的工程知识库可以帮助团队维护审查系统所需的资料。

不过，上下文并不等同于权限。让智能体访问更多政策可以改善推理，但赋予它更多工具可能会扩大错误决策造成的危害。

因此，Anthropic 的设计将速度与问责视为一种持续的权衡。只有在公司增加补偿性控制、证据机制、抽样检查和硬性限制时，进一步自动化才是可接受的。

提示注入暴露了 Anthropic 模式的局限

Anthropic 的控制措施降低了风险，但近期研究发现表明，编程智能体仍可能将不受信任的文本转化为高权限操作。

对 Anthropic 说法最有力的批评是，大多数性能数据都来自 Anthropic 自身。该公司尚未公布足够的细节，让外部人员能够复现其审查覆盖率、误报率或事件预防估算。

54% 的审查评论数据并不能直接衡量安全性。评论更多可能意味着覆盖更全面、噪声更多，或两者兼有。要求为发现的问题提供证据应该能提高质量，但已发表的文章并未提供独立对比。

涉及三分之一历史事件漏洞的估算也依赖回溯性测试。当评估人员已经知道故障所在时，工具的表现可能会有所不同。生产环境还包含信息不完整、系统不断变化以及对抗性输入等情况。

更大的担忧是提示注入。智能体可能在议题、拉取请求、文档文件、依赖项或工具响应中遇到恶意指令。这些指令可能针对智能体拥有的权限。

2026 年 6 月，Microsoft 研究人员披露了一个涉及 Claude Code GitHub Action 的漏洞。处理不受信任 GitHub 内容的智能体可以通过文件读取工具访问敏感的工作流信息。

这项CI/CD 调查发现，不同执行路径采用了不同的保护措施。环境清理覆盖了 Bash 等子进程，但 Read 工具没有相同的沙箱行为。

研究人员表示，该智能体可以读取 /proc/self/environ，从而暴露 Anthropic API 密钥以及其他潜在的运行器凭据。Anthropic 在 Claude Code 2.1.128 版本中通过阻止访问敏感的 /proc 文件修复了报告的问题。

Microsoft 还记录了一条隐藏在 GitHub 议题评论中的恶意指令。该内容指示一个 AI 工作流修改文档文件，并创建包含有害代码的拉取请求。

这个案例说明了智能体为何可能成为供应链中介。如果获得授权的工作流会将攻击者控制的文本转化为拟议变更，攻击者就不需要直接拥有仓库写入权限。

在 Microsoft 的场景中，仍然需要维护者合并拉取请求。然而，负担过重的审查人员可能会将智能体创建的变更视为例行操作。更快的自动化可能提高看似合理的恶意变更仅经过浅层检查便获批准的概率。

Anthropic 公开承认，提示注入问题仍未得到解决。其另一项研究指出，即使攻击成功率只有 1%，也代表着实质性风险。该公司表示，没有任何浏览器智能体能够免疫。

浏览器智能体和编程智能体在不同环境中运行，但底层问题存在重叠。两者都会在持有能够执行重大操作的工具时处理不受信任的内容。

Anthropic 的注入防御结合了模型训练、分类器、监控和人工红队测试。该公司明确避免声称这些防护层能够提供绝对保障。

这一承认进一步强化了基础设施控制的必要性。如果模型层面的抵抗能力可能失效，系统就必须限制可访问的文件、网络目的地、凭据和部署操作。

采用出口流量允许列表的远程开发机器有助于实现这一目标。单一用途身份提供了另一层保护。独立的审查智能体和确定性测试可以在某些不安全输出进入生产环境前将其拦截。

然而，每项控制措施都会产生自身的运维问题。允许列表可能包含会被攻击者滥用的获准服务。审查智能体可能与编写代码的智能体存在相同的盲点。人类也可能批准看似可信但并不安全的变更。

智能体之间的通信又增加了一层不确定性。Anthropic 通过常用频道记录这些交流，提高了可见性。然而，协调机制也会为一个受损智能体影响另一个智能体创造路径。

因此，组织不应将 Anthropic 的系统视为已经完成的蓝图。这是一套针对 Anthropic 自身的基础设施、风险偏好、模型和安全团队构建并仍在演进的内部设计。

规模较小的团队可能缺少专门的红队、成熟的身份系统、可靠的预发布环境，或足够的事件历史来训练专用审查器。如果没有这些基础就照搬自动批准层，反而会本末倒置。

成本是另一个限制。随着代码吞吐量上升，智能体审查和动态扫描会消耗更多计算资源。Anthropic 接受不断增长的审查成本，但其他组织必须决定自己能持续承担多大范围的覆盖。

真正相关的衡量指标不是由 AI 编写的代码比例，而是受到独立且可强制执行的控制措施保护的重大操作比例。即使一家公司很少使用 AI 生成代码，也仍可能造成严重风险暴露。

三个信号将表明 Anthropic 的方法能否经受住考验

Anthropic 的安全模式将根据可衡量的审查质量、遭受攻击时的遏制能力，以及模型变更后治理的稳定性接受评判。

第一个信号是有关自动审查性能的独立证据。Anthropic 已报告更高的拉取请求覆盖率和对历史事件的回溯检测能力。未来披露的信息应包括精确率、误报率、漏检缺陷，以及与人工审查的对比。

这些衡量指标需要按风险分类。一个对常见 Web 漏洞表现良好的审查器，可能会漏掉跨多个服务的授权故障。汇总结果可能掩盖那些一旦出错就后果严重的系统。

独立测试将增强 Anthropic 主张的可信度。共享基准还可以帮助客户比较不同的智能体系统，而不必依赖彼此不兼容的内部评估。Anthropic 自身也指出，标准化的提示注入基准仍然有限。

如果第三方测试证实，在没有产生过多噪声的情况下，漏洞逃逸率有所下降，Anthropic 的模式将更具可信度。如果所报告的改进主要只是评论数量增加，其生产力叙事就会被削弱。

第二个信号是遏制措施阻止模型故障演变成事件的频率。提示注入仍将通过代码仓库、工具、工单、文档和网络内容不断抵达智能体。

因此，研究人员应测试完整的执行环境，而不只是测试 Claude 是否会遵循恶意指令。重要的问题是，受到操纵的智能体能否访问机密、对外通信、修改受保护的代码或触发部署。

Microsoft 的披露提供了一个有用的标准。它追踪了一次模型交互如何通过特定工具和操作系统接口导致凭据暴露。Anthropic 随后的缓解措施则改变了一个可强制执行的文件访问边界。

未来的披露应说明远程虚拟机、出口流量控制、独立身份和批准关卡能否阻止类似攻击。成功遏制将支持 Anthropic 相较于信任模型，更偏好架构防御的做法。

如果不同工具反复出现突破遏制的情况，这一立场就会被削弱。这将表明，周边智能体运行框架的变化速度过快，以至于安全审查无法跟上。

第三个信号是模型和工作流升级后的治理。Anthropic 的 Slack 协调事件发生在模型升级之后，这表明即使没有正式变更权限，新能力也可能改变行为。

在 Anthropic，新的审查智能体会先以影子模式运行。它们提交发现供人工审批，直到赢得信任。安全团队还会使用有意植入的恶意更改来测试它们。

Anthropic 会抽样检查自动审批，并监控涵盖安全工作流的仪表板。据报道，每次智能体操作都会进入其安全信息和事件管理系统（即 SIEM）。该平台汇总活动，用于调查和告警。

该公司会记录自动审批、工具调用、证据以及智能体之间的消息。它将智能体视为一种新型内部威胁，并在其行为偏离预期时发出警报。

“内部威胁”这一表述意义重大。它意味着 Anthropic 不会仅仅因为智能体由公司自行构建，就认为内部智能体是安全的。智能体根据职能获得受监控的访问权限，这与敏感服务账户非常相似。

如果指令过时、新的漏洞知识始终未被写入 CLAUDE.md，或审批抽样流于形式，治理就会失效。如果日志无法解释哪些上下文影响了智能体的决策，治理同样会失效。

未来几个月应该会揭示 Anthropic 是否会公布更多事件细节、审查指标或第三方评估。竞争对手也将面临压力，需要以类似的具体程度说明其控制措施。

对于企业买家来说，眼下的问题并不是 AI 编码智能体能否产出可运行的软件。现有演示已经证明，智能体能够完成大量工程任务。

更棘手的问题是，组织能否约束这种生产力。买家应询问智能体在哪里运行、可以看到哪些凭据、如何限制出站流量，以及由谁审批生产环境变更。

他们还应询问，一个智能体能否联系另一个拥有更高权限的智能体。忽略智能体之间影响的身份审查，会低估其实际权限。

开发团队无需照搬 Anthropic 的整套系统，也可以运用同样的思路。首先识别可能造成严重后果的操作，然后将其与代码生成分离。确保审批责任可追溯，并使凭据脱离智能体的一般访问范围。

将所有代码仓库和工具内容都视为可能具有敌意。为关键不变量保留确定性测试。使用基于模型的审查进行更广泛的推理，但必须要求提供证据，并对自动决策进行抽样检查。

Anthropic 如何保障 AI 原生软件开发生命周期的安全，最终取决于一个原则：自主性必须止于可强制执行的权限边界。采用编码智能体的团队应先绘制这条边界，再衡量生产力。在你当前的工作流中，如果某项智能体操作受到隐藏指令的控制，哪一项会造成最大的破坏？