Anthropic 副首席信息安全官 Jason Clinton 详细介绍了安全工程团队如何保护一个由 AI 撰写 80% 合并代码的软件开发生命周期（SDLC）。
- 分类Claude Code企业级 AI智能体
- 产品Claude CodeClaude TagClaude Enterprise
- 日期2026 年 7 月 21 日
- 阅读时间5分钟
- https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
在 Anthropic，代码量和部署速度呈指数级增长。我们的软件工程师平均每季度交付的代码量是 2021 年至 2025 年期间的 8 倍。
我们的审查、监控和其他安全流程也需要随着这一加速步伐同步扩展。否则就会成为瓶颈的公式（阿姆达尔定律）。
我们的软件开发流程也发生了巨大变化。Claude 已从编码助手演变为主要创作者和审查者。如今，Claude 撰写了约 80% 合并到我们代码库中的代码。
超过一半的代码由我们内部版本的 Claude Tag 合并，而人类工程师则专注于方向指引、设定意图并拥有最终审批权。
这意味着我们的安全团队必须防御一个快速扩张的攻击面，并加固一个以非确定性、持续演进的智能体为核心的生命周期。在本文中，我将介绍保护软件开发生命周期（SDLC）的策略。
（本文旨在与我们最近发布的 Zero Trust for Agents 框架结合阅读；本文中的所有内容都在实施中采用了该框架的安全设计理念）。
我们针对设计防御的威胁是具体的：被入侵或提示词注入的智能体引入恶意变更；智能体作为可信输入摄取的供应链和依赖投毒；以及现在以更高数量级出现的更常见的应用漏洞类别。后续的每项控制措施都至少对应其中一种威胁。
我们部署了若干总体策略，以在不显著拖慢开发速度的情况下实现这一目标，包括：
- 将安全左移，并完全集成到代码开发阶段；
- 利用严格的访问和身份边界来限制爆炸半径；
- 在生产环境前后，结合自动化确定性审查与智能体审查；
- 在杠杆效应最高的环节引入人工介入。
在本文中，我们将介绍我们在软件开发生命周期的特定阶段所实施的安全流程，以及这些流程背后的核心原则。这些原则更具持久性，因为随着模型能力的不断演进，安全团队必须重新审视、甚至常常重塑其流程。
不断演进的软件开发生命周期
我们的开发团队已详细阐述了其软件开发生命周期的变化，因此这里仅作简要概述，随后再深入探讨每个阶段。
总体而言，我们的软件开发生命周期是高度压缩的。它由原型和内部采用（dogfooding）驱动，而非冗长的规划周期。创意来自组织各个角落，传统角色（前端、后端、设计）之间的界限也变得模糊。审查和审批环节仍有人工参与，但同样也由智能体循环驱动。
尽管每个阶段都因 Claude Code 和 Claude Tag 而发生了根本性的变革和加速，但各阶段的名称和用途对于来自更传统组织的开发者来说并不陌生。这些是天然的关卡，我们也将其作为 AI 原生 SDLC 安全流程的一部分。
规划
我们最早的安全自动化之一是一个由 Claude Opus 驱动的简单 PSR（项目安全审查）Web 应用。它读取项目设计文档，并对照 MITRE ATT&CK 框架进行分析，以识别潜在漏洞并提出缓解建议。
我们通过将该系统连接到内部知识索引，显著增强了其能力，该索引提供了跨组织政策、过往决策及相关系统的更深层上下文。
这让我们能更好地理解潜在风险，同时也能捕获 PSR 中缺失的信息。这一项实现就节省了 AppSec 团队的大部分时间。一旦我们确信 Claude 在风险评估方面足够准确，只要 Claude 判定项目上线风险足够低，我们就允许各团队自行审批自己的项目。
在这里，我们可以看到 AI 原生 SDLC 的首批关键适应性调整之一。PSR 最初的设计目的是在漫长且昂贵的编码过程之前发现安全问题。在这个阶段发现问题可以节省数月的返工开发时间。
如今，主要功能的多个原型可以在数小时内完成，这使得详细架构审查不再是一个那么关键的关卡。将我们的 PSR 应用连接到知识索引，可以在不制造不必要速度瓶颈的情况下，捕获原本可能被遗漏的上下文。创建一个 Claude Code 技能，让 Claude 能够进一步扩展，并在上下文所在之处捕获更多信息。
持久原则：将安全智能体连接到组织上下文。随着规划周期不断压缩，把这些智能体带到上下文已经存在的地方——聊天线程、过往审查、代码库——远比在可能已不再需要详细文档的阶段强行要求编写文档要有效得多。无论哪种方式，智能体都需要代码本身之外的上下文。
代码
AI 原生工程组织中的安全专业人员拥有一个新的杠杆：他们可以直接塑造代码的生成方式，从源头帮助预防漏洞。
过去，团队观察到反复出现的漏洞，并制定安全编码指南来应对，但这些指南难以执行，且很少实现标准化。
在 Anthropic，这些指南被编码到 CLAUDE.md 文件和指向组织级技能的引用中，这样代码在生成的那一刻就遵循这些最佳实践。这是作为闭环的一部分来完成的。一旦智能体发现一类 bug，相关文件就会被更新，以防止它在未来的代码中再次出现。
当然，这并不意味着所有代码都能完美无瑕。我们团队一开始就准备了一个 CLAUDE.md 文件，指示智能体在提交 PR 之前，最后执行 /security-review 这一步。这个命令已经正式发布，是我们团队内部审查流程的产品化版本，它会查找潜在攻击者可控输入进入的位置，扫描可疑链接，然后核实其发现。
如今，这些审查是在 Claude 生成代码的同时进行的。一旦安装了安全指导插件，Claude 就会边生成边审查对话和代码。它会在生成代码的同一会话中提出安全改进建议，并处理常见漏洞。
在 PR 阶段，其他一些引导措施会推动内部非技术团队将应用托管在我们的低代码应用托管平台上，从而避免传统上困扰安全团队的影子 IT 问题。
我们的一些客户选择将 /security-review 与 PreToolUse 钩子集成，这会让这一步成为更严格的关卡。这种做法同样有效，但我们团队选择在测试/CI 阶段纳入严格的代码审查关卡。
除了塑造和审查代码之外，控制爆炸半径也是我们这一阶段的主要关注点之一。我们通过围绕身份设置硬性边界（监控部分会详述）以及让开发人员在虚拟机上编写代码来实现这一点。
将编码工作迁移到远程虚拟机是一个相对无痛的转变，与仅使用笔记本电脑相比，这给了我们更强的控制力和可见性。这些虚拟机上的智能体流量已列入出口白名单。
这些严格的出口控制尤为重要，因为智能体可能会读取不可信输入，其中可能携带提示注入载荷。注入的指令无法到达互联网上的任意目的地：数据外泄路径被限制在一小部分受监控的服务中。
这里你再次看到为 AI 原生 SDLC 所做的明确调整。远程编码以前主要用于保护知识产权，而今天我们看到越来越多成熟的 AI 编码团队采用这些环境来约束智能体。
持久原则：在 AI 原生的工程组织中，左移意味着在漏洞发现与更新指令以定制 Claude 生成代码的方式之间形成闭环。通过适当的硬性边界，限制爆炸半径（最小权限原则）以及智能体可访问的范围。
测试（CI）
根据我的经验，在 AI 原生转型过程中，测试或 CI 阶段很快就会成为工程团队最痛苦的瓶颈。在 Anthropic，一旦大多数开发者开始使用智能体编码工具并同时运行多个智能体，很快就变得显而易见：团队的推进速度只能跟得上人类审查代码的速度。
需要明确的是：人的责任在我们的流程中仍然处于核心位置。我们所做的是通过结合自动化智能体审查和确定性审查来加速审查流程，同时将人工审查保留给受监管或真正关键的代码。
从历史上看，人工代码审查一直被视为标准，但经验证据表明它并不完美。安全漏洞经常随全球各地的软件一起发布。我们的审查流程能够审查更多代码并捕获特别复杂的问题，有助于降低这些风险。
随着我们要求智能体为其发现编写有效性证明，从而对这些发现建立起信心，获得实质性审查意见的 PR 占比已从 16% 增长到 54%。我们还确定，过去 claude.ai 事故中约三分之一的漏洞本可以被我们现在已实施的自动化流程捕获。
我们并不是唯一发现这一点的组织。Intercom 公开表示其 19% 的 PR 获得自动批准。部署量翻倍，同时因破坏性代码变更导致的停机时间下降了 35%。CircleCI 在构建 Chunk（一个基于 Claude 的自主智能体，用于解决 CI/CD 维护问题并在人工介入之前自行验证修复方案）时得出了类似结论。这种方法使智能体任务转化为已完成拉取请求的比率翻了一番。
在 Anthropic，每当有 PR 被创建时，多个智能体会自动对其进行审查。每个审查智能体都被设计并限定在特定、狭窄的职责范围内，并利用 RAG 来获取与过往事件相关的额外上下文和记忆。
相比使用一个巨型提示词或一个超级安全智能体，这种方式有效得多，原因如下：
- 它们不会共享偏见和盲区
- 如果其中一个被攻破或犯错，可以被其他审查者发现
- 精力不会过于分散在多个关注领域上
需要说明的是，智能体并不会在无人检查的情况下将代码合并到生产环境。我们按风险对代码库进行分级，并对哪些部分实现自动化做出审慎决策。整个代码库都设有严格的人工审批流程。
对于由 Claude 审查和合并的代码，人工问责仍然至关重要。每次审批都会记录其背后的信号和推理依据，并由人工对按风险加权的样本进行复核。另一轮测试则聚焦于“用户 A 永远无法读取用户 B 的数据”这类不变量，并触发额外的人工审查。我们还将智能体扫描与 SAST 工具相结合，这些工具会直接在 PR 上发布结果。
大多数扫描方法，无论是智能体式的还是确定性的，都是基于消耗量的。随着代码吞吐量的增加，成本也会上升，团队需要决定适合自身的覆盖水平。
在 Anthropic，我们接受随着代码速度的提升，这方面的成本会增长，但预计单位成本会下降。如今的模型在编程方面的能力远胜于几年前的所有模型，我们预计这一趋势将持续下去。
持久原则：自动化审查是一种不同类型的风险，需要通过不同方式加以控制（通过多重关卡和拥有独立上下文窗口的智能体）。人工始终参与其中，但根据代码库的性质，人工介入点可能处于生命周期的不同环节。
部署（CD）
Anthropic 维护着一个健壮的预发布环境，我们在其中执行常见的安全最佳实践，例如针对重大发布进行外部渗透测试，以及定期进行 DAST 扫描，以捕获静态扫描遗漏或无法发现的逻辑缺陷。
与其他 SDLC 阶段一样，AI 既为安全团队带来了新的挑战，也提供了新的解决方案。一方面，到达这一阶段的漏洞更少了。另一方面，那些确实存活下来的漏洞恰恰是最隐蔽、最难发现的。
再加上代码交付量更大、交付频率更高，定期的动态测试看起来也就不那么“动态”了。
好消息是，AI 模型在跨组件、多步骤推理方面表现更佳，能够捕获更高比例的此类复杂漏洞。例如，今年 2 月，我们披露 Claude 发现并帮助修复了 500 多个高严重性的 OSS 漏洞。
在 Anthropic，我们正在预发布环境中实施持续性的 AI 驱动 DAST 扫描。这些扫描在系统层面寻找漏洞，即两个或多个服务之间的假设不正确的情况。目前已有不少厂商提供此类能力。
持久原则：动态测试应与部署节奏相匹配。
监控
任何优秀的安全团队都知道，代码推送到生产环境后工作并未结束。我们可以假设，任何漏洞都会被日益老练的攻击者迅速发现。
我们的安全团队在此实施了多项标准实践项目，例如公开的漏洞赏金计划、红队模拟攻击，以及对我们的依赖项、密钥、供应链、云安全态势和容器进行定期漏洞扫描。
Claude 在这些工作中扮演着重要角色，但我们将重点关注因我们 AI 原生的 SDLC 而带来的监控工作的更大变化：告警分诊和代码迁移。
当 Anthropic 内部触发告警时，Claude 会开始：
- 审查生产日志
- 定位问题的根本原因；
- 撰写事后分析报告；在某些情况下
- 编写修复该问题的代码变更。
这个智能体不能做的是自动部署修复。它是一个单用途的系统账户智能体，拥有三项权限：可以编写新文档、在公司频道发帖，以及访问生产日志。
修复方案要么来自一个独立的智能体-人工审查系统。原因还是要回到身份管理、权限和硬性边界上：在将代码推送到生产环境时，控制爆炸半径至关重要。将智能体彼此分离是关键，因为一个（或多个）智能体要对另一个智能体形成制衡。
这也是给CISO们的一个重要教训，而且是我付出了惨痛代价才学到的。在考虑智能体的硬性边界时，你需要把它对其他智能体的访问权限也纳入考量。
在一次模型升级之后，事件响应智能体主动通过Slack联系了另一个Claude实例。它请求那个能够编写代码的智能体推送修复方案。这一行为按设计在人工审查关卡被拦截了，但这次经历让我们明白，边界应该划定在访问权限和操作行为上，而不是划定在模型的指令或我们自认为模型能做什么上。如今在Anthropic，智能体之间通过Slack通信已是常态，我们对智能体身份模型也投入了大量思考。
第二个重大变化是我们团队处理迁移的方式。每个安全工程团队都经历过这样的时刻：他们意识到必须进行代码迁移，才能修复公司运营方式中的某个系统性缺陷。过去，CISO需要开始游说，并连续多个季度向各部门申请一小部分工程资源才能完成修复。
迁移的经济成本已经下降，跨公司协调的成本也随之降低。Claude将迁移过程自动化，数万行代码在几天内就能完成迁移。
持久原则：赋予每个智能体单一用途的身份，并只授予其完成工作所需的最低权限。如果你确实允许智能体之间进行协调，就让它们通过与人类相同的渠道进行。
治理
我们已经自动化了许多安全流程，但人类仍然是确保安全软件开发生命周期不可或缺的一部分。不过，我们的关注点已不再是审查代码和错误报告，而是集中在Claude Tag、循环和仪表盘上。
这凸显了强有力治理的重要性。如果某个技能过时了，发现的一类漏洞从未被回写到 CLAUDE.md 中，或者智能体的决策未被抽样检查，整个体系就会退化。我们通过以下方式来避免这种情况：
- 按风险对代码库进行分层，然后基于该层级自动化审查。
- 所有新的 AI 审查者都采用影子模式。新智能体先发布评论供人工审批，直到赢得信任。我们的团队还会对它们进行“红队测试”，尝试注入恶意更改。
- 对所有自动化审批按一定比例进行抽样。
- 监控关键指标。我们维护并密切监控一个仪表盘，汇总所有安全流程和工作流的关键指标。
- 将每个智能体操作路由到 SIEM。每次自动化审批、工具调用和智能体间消息都会连同其使用的信号一起记录，并进入我们的 SIEM，因此任何决策事后都可追溯、可审计。我们利用这些数据，将这些智能体视为一种新型内部威胁，并在它们行为偏离对齐时发出警报。
持久原则：安全工程师的工作从监控漏洞演变为监控循环。
唯一不变的是变化
软件开发周期及其加固手段的演进速度之快，怎么强调都不为过。模型能力每个月都在进步，既带来新的挑战，也带来新的解决方案。
今天还不太奏效或经济上不太可行的方案，很可能很快就会实现。你的团队该问的正确问题不是“我们扫描得起所有内容吗？”，而是“如果扫描几乎免费，我们会运行什么？”为此做好规划。
本文由 Anthropic 副首席信息安全官 Jason Clinton 撰写。他感谢 Michael Segner 对本文的贡献。
Anthropic Deputy CISO, Jason Clinton, details how the Security Engineering team secures a SDLC that has AI authoring 80% of merged code.
- Category
- ProductClaude CodeClaude TagClaude Enterprise
- DateJuly 21, 2026
- Reading time5min
- https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
At Anthropic, the amount of code and velocity of deployment have scaled exponentially. Our software engineers on average ship 8x as much code per quarter as they did from 2021 to 2025.
Our reviews, monitoring, and other security processes needed to scale alongside this increased pace. Otherwise it becomes a formula for bottlenecks (Amdahl’s Law).
Our software development processes have changed drastically as well. Claude has evolved from coding assistant to primary creator and reviewer. Claude authors about 80% of the code merged into our codebase today.
More than half of all code is being merged by our internal version of Claude Tag while human engineers focus on directing, setting intent, and owning final approval.
This means our security team must defend a rapidly expanding surface area and harden a lifecycle with non-deterministic, constantly evolving agents at its heart. In this article, I cover strategies to secure the software development lifecycle (SDLC).
(This is intended to be combined with the Zero Trust for Agents framework we recently published; everything in this article uses security design ideas from that framework in the implementation).
The threats we're designing against are specific: a compromised or prompt-injected agent introducing a malicious change; supply-chain and dependency poisoning that an agent ingests as trusted input; and the more familiar classes of application vulnerability now arriving at higher volume. Every control that follows maps to at least one of those.
There are several overarching strategies we’ve deployed to accomplish this without significantly throttling dev velocity including:
- Shifting security left and fully integrating with the code development stage;
- Using hard access and identity boundaries to contain the blast radius;
- Combining automated deterministic and agentic reviews before and after production; and
- Inserting humans in the loop at the highest leveraged points.
In this article, we’ll cover the security processes we have implemented at specific stages of the software development lifecycle as well as the core principles behind them. These principles are more enduring as security teams must reexamine, and often reinvent, their processes as model capabilities evolve.
The evolving software development lifecycle
Our development team has covered the changes to their software development lifecycle at length, so this will be a brief primer before we dive into each stage.
At a high level, our software development lifecycle is compressed. It is driven by prototypes and internal adoption (dogfooding) more than lengthy planning cycles. Ideation comes from all corners of the organization and traditional roles (frontend, backend, design) are blurred. Reviews and approvals still have humans in the loop, but are also driven by agentic loops.
While each stage has been fundamentally transformed and accelerated by Claude Code and Claude Tag, the names and purposes of each stage wouldn’t look alien to a developer coming from a more traditional organization. These are natural gates that we also use as part of our security processes for an AI-native SDLC.
Plan
One of our first security automations ever was a simple Claude Opus powered PSR (project security review) web application. It ingested a project design document and analyzed it against the MITRE ATT&CK framework to identify potential vulnerabilities and suggested mitigations.
We’ve significantly enhanced the system by connecting it to an internal knowledge index that provides much deeper context across our organization-wide policies, past decisions, and related systems.
This gives us a better understanding of potential risk, and it also captures information missing from the PSR. This one implementation saved the majority of the AppSec team’s time. Once we gained confidence that Claude was accurate in assessing risk, we allowed teams to approve their own project, if Claude deemed the launch low enough risk.
Here we can see one of the first key adaptations to an AI-native SDLC. A PSR was originally designed to catch security issues before the lengthy and expensive coding process. Catching an issue at this stage saved months of re-development.
Today, multiple prototypes of major features can be created in hours, making detailed architectural review a less critical gate. Connecting our PSR application to our knowledge index captures context that could otherwise be missed without creating an unnecessary speed bump. Creating a Claude Code skill allowed Claude to further fan out and capture additional context wherever it lived.
Enduring Principle: Connect security agents to organizational context. As the planning cycle compresses, it is much more effective to bring these agents to where the context already lives – chat threads, prior reviews, the codebase – rather than forcing detailed documentation at stages that may no longer require them. Either way, agents need context outside of the code itself.
Code
Security professionals within an AI-native engineering organization have a new lever: they can directly shape how code is created, helping to prevent vulnerabilities at the source.
Previously, teams observed recurring vulnerabilities and created secure coding guidelines to address them, but those guidelines were difficult to enforce and rarely standardized.
At Anthropic, those guidelines are encoded in CLAUDE.md files and references to org-wide skills so the code follows these best practices the minute it's generated. This is done as part of a closed loop. Once an agent discovers a bug class, the relevant file is updated to prevent it recurring in future code.
Of course, that doesn’t mean all code comes out perfect. Our team started with a CLAUDE.md file that instructs the agent to run /security-review as a final step before opening a PR. This generally available command, the productized version of our team's internal review workflow, looks for places where potential attacker-controllable input enters, scans for suspicious links, and then verifies its findings.
Today, these reviews take place while Claude generates the code. Once a security guidance plugin is installed, Claude reviews the conversation and code as it goes. It suggests security improvements and addresses common vulnerabilities in the same session as it generates the code.
Other nudges at PR-time push internal, non-technical teams towards hosting their app on our low-code app-hosting platform, avoiding shadow IT that had traditionally plagued security teams.
Some of our customers choose to integrate /security-review with a PreToolUse hook, which makes this step a harder gate. That is also effective, but our team has chosen to incorporate our hard code review gate at the test/CI stage of the cycle.
In addition to shaping and reviewing code, containing the blast radius is one of our primary concerns at this stage. We do this by setting hard boundaries around identity (more on that in the monitor section) and setting our devs up to code on virtual machines.
Moving our coding to remote VMs was a relatively painless shift and gave us increased control and visibility compared to laptops alone. Agent traffic on these VMs is egress-allowlisted.
These tight egress controls matter especially when the agent is reading untrusted input which can carry a prompt-injection payload. An injected instruction can’t reach arbitrary destinations on the internet: exfiltration paths are limited to a small set of monitored services.
Here again you can see a clear adaptation for an AI-native SDLC. Remote coding was previously used mainly to contain IP, and today we’re seeing more mature AI coding teams adopt these environments as a means to contain agents.
Enduring Principle: Shifting left in an AI-native engineering organization means closing the loop between vulnerability discovery and updating instructions to customize how Claude generates code. Limit the blast radius (Principle of Least Agency) and what an agent can access with hard boundaries as appropriate.
Test (CI)
In my experience, the test or CI stage quickly becomes the most painful bottleneck for engineering teams in the midst of an AI-native transformation. At Anthropic, once most developers were using agentic coding tools and running multiple agents at one time, it quickly became obvious the team could only move as quickly as humans could review code.
Let’s be clear: human accountability is still central to our process. What we did was accelerate the review process by combining automated agentic and deterministic reviews, while reserving human review for regulated or truly critical code.
Historically, human code review has been held as the standard, yet the empirical evidence has shown it is not perfect. Security bugs regularly ship in software across the world. Our review process is able to review more code and catch particularly complex issues, helping to reduce these risks.
The share of PRs that get substantive review comments has grown from 16 to 54% as we’ve gained confidence in the findings by requiring the agents to write a proof that their finding is valid. We’ve also determined that approximately a third of the bugs behind past claude.ai incidents would have been caught by the automated processes we have now implemented.
We’re not the only organization that has found this to be true. Intercom has shared it auto-approves 19% of its PRs. Deployment doubled while downtime from breaking code changes dropped 35%. CircleCI reached a similar conclusion building Chunk, an autonomous agent on Claude that resolves CI/CD maintenance issues and validates its own fixes before a human ever sees them. The approach doubled the rate at which agent tasks convert into completed pull requests.
When a PR is opened at Anthropic, multiple agents automatically review it. Each review agent is designed and scoped to a specific, narrow focus and leverages RAG for additional context and memory surrounding past incidents.
This is much more effective than one mega-prompt or super security agent for a few reasons:
- They do not share biases and blindspots
- If one is compromised or makes a mistake, it can be caught by other reviewers
- Effort isn’t spread too thinly across multiple focus areas
To be clear, agents aren't merging code to production unchecked. We tier our codebase by risk, and make deliberate decisions on what parts to automate. Entire codebases have strict human approval processes.
Human accountability is still central for code that is reviewed and merged by Claude. Every approval is logged with the signals and reasoning behind it, and a risk-weighted sample is reviewed by humans. Another round of testing focuses on invariants like “user A can never read user B’s data,” and triggers additional manual reviews.We combine our agentic scans with SAST tools as well, which post directly on PRs.
Most scanning approaches, whether agentic or deterministic, are consumption based. Costs will increase as code throughput increases, and teams will need to decide what level of coverage is appropriate for them.
At Anthropic, we accept costs here will grow as our code velocity increases, but anticipate unit cost will fall. Models today are much better at coding than all models from a few years ago, and we anticipate that this pattern will continue.
Enduring Principle: Automated reviews are a different type of risk that is controlled differently (through multiple gates and agents with separate context windows). Humans stay in the loop, but may be in different places in the lifecycle depending on the nature of the codebase.
Deploy (CD)
Anthropic maintains a robust staging environment where we execute common security best practices such as external pentesting for major launches and periodic DAST scans to catch logic bugs that static scans have missed or can’t see.
Like the other SDLC stages, AI presents both new challenges and solutions for security teams. On one hand, fewer vulnerabilities reach this stage. On the other, the vulnerabilities that do survive are among the most subtle and difficult to catch.
Combine that with larger volumes of code being shipped more frequently, and periodic dynamic testing doesn’t seem so dynamic anymore.
The good news is that AI models are better on the multi-step, cross-component reasoning that can catch a greater percentage of these complex vulnerabilities. For example, in February, we disclosed that Claude discovered and helped to fix more than 500 high-severity OSS vulnerabilities.
At Anthropic, we are implementing continuous AI-powered DAST scans in our staging environment. These look for vulnerabilities at the system level where the assumptions between two or more services are incorrect. There are a number of vendors that offer these capabilities today.
Enduring Principle: Dynamic testing should match deployment cadence.
Monitor
As any good security team knows, the job isn’t done once code is pushed to prod. We can assume any vulnerability will be quickly identified by increasingly sophisticated attackers.
Our security team has implemented programs here that are standard practice such as a public bug bounty program, red team simulated attacks, and regular scans for vulnerabilities across our dependencies, secrets, supply chain, cloud posture, and containers.
Claude plays a large role in these, but we’ll focus on larger changes to our monitoring efforts as a result of our AI-native SDLC: alert triage and code migrations.
When an alert fires at Anthropic, Claude starts:
- Reviewing the production logs
- Root-causing the bug;
- Writing the post-mortem; and in some cases
- Writing the code change to fix the bug.
What this agent can’t do is deploy the fix automatically. It’s a single-purpose system account agent with three permissions: it can write new docs, post in company channels, and access production logs.
The fix either needs to come from a separate agent-human reviewer system. The reason for this comes back to managing identity, permissions, and hard boundaries: it’s important to contain the blast radius when pushing code into production. Separating agents is critical as one (or multiple) agents act as checks on the other.
This is also an important lesson for CISOs, and one that I had to learn the hard way. When considering an agent’s hard boundaries you need to include its access to other agents.
Following a model upgrade, the incident response agent reached out over Slack to another Claude instance on its own initiative. It asked the agent, which could write code, to push the fix. This was caught at a human review gate as designed, but this experience taught us to draw the boundary around access and actions, not around a model’s instructions or what we believe a model can do. Today at Anthropic, agent-to-agent communication on Slack is the norm and we give considerable thought to agent identity models.
The second major change is how our team approaches migrations. Every security engineering team has experienced the moment where they realize a code migration will be necessary to fix some systemic flaw in the way the company operates. In the past, the CISO would need to start campaigning and request a small percentage of each department’s engineering resources for multiple quarters to get it fixed.
The economic cost of migration has fallen and so too has the cost of cross company coordination. Claude automates the migration process, tens of thousands of lines of code, in days.
Enduring Principle: Give every agent a single-purpose identity with the minimum permissions for its job. If you do let agents coordinate, have them do so over the same channels as humans.
Governance
We have automated many of our security processes, but humans are still very much an integral part of ensuring a secure software development lifecycle. But instead of focusing on reviewing code and bug reports, our attention is now focused on Claude Tag, loops, and dashboards.
This underscores the importance of strong governance. If a skill goes stale, a discovered bug class never makes it back into CLAUDE.md, or an agent's decisions go unsampled, the whole structure degrades. We avoid this by:
- Tiering our codebase by risk and then automating reviews based on that level.
- Shadow mode for all new AI reviewers. New agents post comments for human approval until trust is earned. Our team also “red teams” them and tries to insert malicious changes.
- Sampling a percentage of all automated approvals.
- Watching our vitals. We maintain and closely monitor a dashboard that rolls up key metrics across every security process and workstream.
- Routing every agent action to the SIEM. Every automated approval, tool call, and agent-to-agent message is logged with the signals it used and lands in our SIEM, so any decision is attributable and auditable after the fact. We use this data and treat these agents as a new type of insider threat, and raise alerts when they act out of alignment.
Enduring Principle: The security engineer’s job evolves from monitoring bugs to monitoring loops.
The only constant is change
It’s hard to overstate just how fast the software development lifecycle, and the means of hardening it are evolving. Model capabilities advance every month, bringing both new challenges and solutions.
What doesn’t quite work today or isn’t quite economically feasible likely will be soon. The right question for your team isn't "can we afford to scan everything?" but "what would we run if scanning were nearly free?" Plan for that.
This article was written by Jason Clinton, Deputy CISO, Anthropic. He’d like to thank Michael Segner for his contributions to this article.