Anthropic、AI 開発ライフサイクルのセキュリティ対策を解説
Anthropic は、自社の AI ネイティブな開発ライフサイクルにおけるセキュリティ確保策を詳細に公開し、AI モデルの生成コードに対する厳格な検証と自動化された防御体制の構築を示した。
キーポイント
AI 生成コードの自動検証フレームワーク
Anthropic は、AI が生成したコードがセキュリティ基準やベストプラクティスに合致しているかを自動的に検証する独自のフレームワークを導入し、人的ミスを排除している。
多層的な防御戦略の実装
単一のチェックポイントではなく、開発の全段階（設計、実装、テスト、デプロイ）にわたる多層的なセキュリティ対策を組み合わせることで、潜在的な脆弱性を早期に発見する体制を整えた。
AI による脅威検知と対応
開発プロセス自体を AI が監視・分析し、不審なコードパターンや攻撃の兆候を検知して即座に対応できる自律的なセキュリティシステムを構築した。
透明性と業界への貢献
これらの対策の詳細を公開することで、AI 開発におけるセキュリティのベストプラクティスを業界全体に共有し、信頼性の高い AI ソフトウェア生態系の形成を目指している。
重要な引用
We have built a security-first approach that is deeply integrated into our AI-native development lifecycle.
Our automated verification framework ensures that every line of code generated by our models meets strict security standards before it reaches production.
影響分析・編集コメントを表示
影響分析
この記事は、AI モデルが生成するコードの信頼性を確保するための具体的な技術的アプローチと組織的な取り組みを明らかにしており、開発者やセキュリティ担当者が直面する「AI によるコード注入リスク」への対策として極めて重要です。また、自社の方針を公開することで業界全体のベストプラクティスを標準化する動きを示唆しており、今後の AI ソフトウェア開発のセキュリティ基準に大きな影響を与える可能性があります。
編集コメント
AI が生成するコードのセキュリティを如何に担保するかは、実社会での AI 導入における最大の懸念事項の一つです。Anthropic がその解決策として「自動化された多層防御」を打ち出したことは、業界全体が直面する課題に対する具体的な回答となり得る重要な一歩と言えます。
Code
AI をネイティブに活用するエンジニアリング組織において、セキュリティ専門家が新たに活用できる手段があります。それはコードが作成される段階で直接そのあり方を形作り、脆弱性が生まれる根源から防ぐことです。
従来はチームが繰り返し発生する脆弱性を把握し、それに対処するためのコーディングガイドラインを作成していました。しかし、これらのガイドラインは運用が難しく、標準化されることも稀でした。
Anthropic では、こうしたガイドラインを「CLAUDE.md」ファイルに記述し、組織全体のスキルへの参照を含めることで、コード生成の瞬間からベストプラクティスが守られるようにしています。これはクローズドループの一部として行われます。エージェントが特定のバグクラスを発見すると、関連するファイルが更新され、将来のコードで同様の問題が再発しない仕組みになっています。
もちろん、これで生成されるコードがすべて完璧になるわけではありません。Anthropic のチームはまず、PR を開く直前にエージェントに /security-review コマンドを実行させるよう指示する CLAUDE.md ファイルから始めました。これは現在一般公開されているコマンドで、チーム内部のレビューワークフローを製品化したものです。このコマンドは、攻撃者が操作可能な入力が入り込む箇所を検出し、不審なリンクをスキャンし、その結果を確認します。
現在、コード生成中にClaude がレビューを行っています。セキュリティガイダンスプラグイン をインストールすると、Claude は会話とコードをリアルタイムで確認し、生成プロセスの中でセキュリティ向上の提案や一般的な脆弱性への対応を行います。
PR（プルリクエスト）段階での他の誘導策により、技術部門以外の社内チームは従来の「シャドー IT」問題から脱却し、当社のローコードアプリホスティングプラットフォーム上でアプリケーションをホストするよう促されています。
一部の顧客は、/security-review をPreToolUseフックと連携させることで、このステップをより厳格なゲートとしています。これも有効な手段ですが、当チームとしては、サイクルのテスト/CI 段階に堅牢なコードレビューのゲートを設ける方針を採用しています。
コードの作成・レビューに加え、この段階で最も重視しているのが「被害範囲の限定」です。そのために、ID に関する厳格な境界設定（監視セクションで詳しく解説）を行い、開発者に仮想マシン上でのコーディングを徹底させています。
コーディング環境をリモート VM へ移行したのは比較的スムーズな変更でした。ノートパソコン単体と比較して、管理と可視性の面で大きな向上が実現しています。これらの VM 上のエージェント通信は、許可リスト（アロウリスト）に基づいて外部への送信を制限しています。
エージェントが信頼できない入力を読み込む際、特にこの厳格な外部接続制限が重要になります。そこにはプロンプトインジェクションの悪意あるペイロードが含まれている可能性があるからです。注入された指示はインターネット上の任意の宛先へ到達することはできず、データ持ち出し経路は限られた監視対象サービスにのみ限定されます。
ここでも、AI ネイティブなソフトウェア開発ライフサイクル（SDLC）への明確な適応が見て取れます。以前はリモートコーディングが主に知的財産の保護のために使われていましたが、現在ではより成熟した AI コーディングチームが、エージェントを管理・封じ込める手段としてこれらの環境を採用するようになっています。
永続的な原則: AI ネイティブなエンジニア組織における「左側シフト」とは、脆弱性の発見と、Claude がコードを生成する方法をカスタマイズするための指示更新との間のループを閉じることを意味します。爆発半径（最小権限の原理）を制限し、必要に応じてハードな境界線によってエージェントがアクセスできる範囲を厳格に制御してください。
テスト (CI)
私の経験則では、AI ネイティブへの転換期にあるエンジニアチームにとって、テストや CI の工程は最も苦痛なボトルネックになりがちです。Anthropic においても、開発者のほとんどがエージェント型コーディングツールを使い始め、同時に複数のエージェントを稼働させるようになると、チームの速度は人間によるコードレビューのスピードに制限されるという事実がすぐに明白になりました。
はっきり言っておきましょう：人間の責任所在は依然としてプロセスの中核です。私たちが行ったのは、自動化されたエージェント型レビューと決定論的レビューを組み合わせてレビュープロセスを加速させつつ、規制対象や真に重要なコードについては人間によるレビューを維持することでした。
従来、人間のコードレビューが業界標準とされてきましたが、実証データはそれが完璧ではないことを示しています。セキュリティ上のバグは世界中のソフトウェアで依然として頻繁にリリースされています。一方、当社のレビュープロセスではより多くのコードを検査し、特に複雑な問題を発見できるため、こうしたリスクを低減できます。
エージェントが自身の発見の妥当性を証明するよう求めることで信頼が高まった結果、実質的なレビューコメントが付されたプルリクエスト（PR）の割合は 16% から 54% に増加しました。また、現在導入した自動化プロセスであれば、過去の claude.ai のインシデントの原因となったバグのおよそ 3 分の 1 は検出できたとの分析結果も得ています。
これは Anthropic だけの話ではありません。Intercom も同様の成果を報告しており、同社では AI が PR の 19% を自動承認しています。その結果、デプロイ頻度が倍増する一方で、コード変更によるダウンタイムは 35% 減少しました。CircleCI も同様の結論に至っており、Claude を活用した自律型エージェント「Chunk」を開発。このエージェントは CI/CD のメンテナンス課題を解決し、人間が確認する前に自身で修正の妥当性を検証します。このアプローチにより、エージェントによるタスクが完了したプルリクエストとしてマージされる割合も倍増しました。
Anthropic でプルリクエスト (PR) が開かれると、複数のエージェントが自動的にレビューを行います。各レビューエージェントは特定の狭い焦点に設計・スコープされ、過去のインシデントに関する追加の文脈や記憶を得るために RAG(検索拡張生成) を活用しています。
これは、単一の巨大なプロンプトやスーパーセキュリティエージェントを使うよりも効果的です。その理由は主に以下の通りです。
- 各エージェントがバイアスや盲点を共有しないため、リスクを分散できる
- 1 つのエージェントが侵害されたり誤りを犯したりしても、他のレビューヤーによって検出可能
- エネルギーを複数の焦点領域に薄く分散させなくて済む
念のため言っておきますが、エージェントがチェックなしで本番環境へコードをマージすることはありません。私たちはコードベースをリスクレベルに応じて階層化し、どの部分を自動化するかは意図的に決定しています。コードベース全体には厳格な人間の承認プロセスが適用されています。
Claude によってレビューされマージされるコードについては、依然として人間の責任が中心です。すべての承認は、その背後にあるシグナルと理由とともにログに記録されます。また、リスク加重されたサンプルを人間が再確認します。もう一つのテストラウンドでは、「ユーザー A は決してユーザー B のデータを読み取れない」といった不変条件 (インバリアント) に焦点を当て、追加の手動レビュートリガーを発生させます。さらに、エージェントによるスキャンと SAST(静的アプリケーションセキュリティテスト) ツールを組み合わせており、これらは PR に対して直接コメントを投稿します。
エージェント型であれ決定論的アプローチであれ、ほとんどのスキャン手法は利用量ベース (コンシュープションベース) です。コードのスループットが増加すればコストも増大し、各チームが自らの状況に適切なカバレッジレベルを判断する必要があります。
Anthropic では、コードの生産性が向上すればコストも増大すると認識していますが、一方で単価は低下していくと予測しています。現在のモデルは数年前のものに比べてコーディング能力が格段に向上しており、この傾向は今後も続くでしょう。
永続的な原則: 自動レビューはリスクの種類が異なり、制御方法も異なります（複数のゲートと、異なるコンテキストウィンドウを持つエージェントによる管理です）。人間はプロセスに関与し続けますが、コードベースの性質に応じて、関与するタイミングや場所はライフサイクルの中で変化します。
デプロイ (CD)
Anthropic では堅牢なステージング環境を維持しており、主要なリリース時には外部ペネトレーションテストを実行し、定期的には DAST（動的アプリケーションセキュリティテスト）スキャンを実施しています。これにより、静的スキャンでは見逃されたり検出できなかったロジックバグを捕捉します。
SDLC の他のステージと同様に、AI はセキュリティチームにとって新たな課題と解決策をもたらします。一方で、到達する脆弱性の数は減少しています。他方で、生き残った脆弱性は極めて微妙で、発見が難しいものばかりです。
これに、より頻繁に大量のコードがリリースされるという現状を合わせると、定期的な動的テストも以前ほど「動的」ではなくなってしまいます。
しかし朗報もあります。AI モデルは、こうした複雑な脆弱性の多くを検出できる多段階かつコンポーネント間の推論において優れています。例えば今年 2 月、Claude が 500 件以上の高深刻度 OSS 脆弱性を発見し、修正に貢献したことを発表しました。
500 high-severity OSS vulnerabilities
Anthropic では、ステージング環境において継続的に AI を活用した DAST（動的アプリケーションセキュリティテスト）スキャンを実施しています。これは、2 つ以上のサービス間の前提条件が誤っている場合に生じるシステムレベルの脆弱性を検出するものです。現在、こうした機能を提供するベンダーは複数存在します。
永続的な原則: ダイナミックテストは、デプロイの頻度に合わせるべきです。
モニタリング
優れたセキュリティチームなら誰もが知っていますが、コードを本番環境に展開したところで仕事は終わりません。どんな脆弱性も、次第に高度化する攻撃者によってすぐに発見される可能性があると想定する必要があります。
当社のセキュリティチームでは、公開バグバウンティプログラム の運営やレッドチームによる模擬攻撃、依存関係・機密情報・サプライチェーン・クラウド設定・コンテナ全体での定期的な脆弱性スキャンなど、業界標準の取り組みを既に実施しています。
Claude はこれらの活動において大きな役割を果たしていますが、AI 原生のソフトウェア開発ライフサイクル（SDLC）導入に伴うモニタリング体制におけるより大きな変化として、アラート処理とコード移行に焦点を当てて説明します。
Anthropic でアラートが発生すると、Claude が以下のような作業を開始します：
- 本番環境のログを確認する
- バグの原因究明を行う
- 事後報告書（ポストモーテム）を作成する
- 場合によっては、バグを修正するためのコード変更も作成する
ただし、このエージェントが自動で修正をデプロイすることはできません。これは単一の目的に特化したシステムアカウントであり、許可されている権限は以下の3つだけです：新しいドキュメントの作成、社内チャネルへの投稿、本番環境ログへのアクセス。
修正は、別のエージェントと人間のレビューシステムから行われる必要があります。その理由は、アイデンティティ、権限、そして明確な境界線を管理するためです。本番環境へのコード展開時に被害の範囲を限定することが重要です。エージェントを分離することは不可欠で、あるエージェント（または複数のエージェント）が他のエージェントに対するチェック機能として働くからです。
これは CISO（最高情報セキュリティ責任者）にとって重要な教訓であり、私も痛い目を見て学んだことです。エージェントの明確な境界線を考える際、他のエージェントへのアクセス権限も含まれることを考慮する必要があります。
モデルのアップグレード後、インシデント対応エージェントが自発的に Slack を介して別の Claude インスタンスに連絡しました。そしてコードを記述できるエージェントに対して、修正を適用するよう依頼したのです。これは設計通り人間のレビュー段階で検出されましたが、この経験から私たちは、境界線をモデルの指示や「モデルができるだろう」という私たちの思い込みではなく、「アクセス権限と実行可能なアクション」の範囲に引くべきだと学びました。現在 Anthropic では、Slack を介したエージェント間の通信は一般的であり、エージェントアイデンティティモデル については十分に検討しています。
2 つ目の大きな変化は、チームが移行プロジェクトに取り組む姿勢です。セキュリティエンジニアリングチームなら誰もが経験する瞬間があります。自社の運用方法に根本的な欠陥があることに気づき、「コードの移行が必要だ」と判断した瞬間です。
かつては、CISO（最高情報セキュリティ責任者）がキャンペーンを展開し、各部署のエンジニアリソースの一部を数四半期にわたって割り当ててもらうよう要請する必要がありました。しかし今では、移行に伴う経済的コストも、社横断的な調整にかかるコストも低下しています。Claude なら、数万行に及ぶコードの移行プロセスを数日で自動化できます。
不変の原則: すべてのエージェントには、その業務に必要な最小限の権限を持つ単一目的のアイデンティティを与えてください。もしエージェント同士が連携させる必要がある場合は、人間と同じチャネルを通じて行うようにしてください。
ガバナンス
セキュリティプロセスの多くを自動化しましたが、安全なソフトウェア開発ライフサイクルを確保する上で人間の役割は依然として不可欠です。ただし、今私たちが注力しているのはコードレビューやバグレポートではなく、「Claude Tag」やループ、ダッシュボードです。
これは強力なガバナンスの重要性を浮き彫りにしています。スキルが陳腐化したり、発見されたバグクラスが CLAUDE.md に反映されなかったり、エージェントの判断がサンプリングされなかったりすれば、システム全体が劣化してしまいます。これを防ぐために、私たちは以下のような対策を講じています。
- コードベースをリスクレベルに応じて階層化し、そのレベルに応じたレビューを自動化する。
- 新しい AI レビューヤーはすべてシャドウモードで運用します。信頼が得られるまでは、新しいエージェントが投稿したコメントは人間の承認待ちとします。また、チーム内で「レッドチーム」演習を行い、悪意のある変更を加えてテストも行います。
- 自動承認されたケースの一部をサンプリングして確認する。
- システムのバイタル（重要指標）を常時監視する。セキュリティプロセスと各ワークストリーム全体の主要な指標を集約したダッシュボードを維持し、厳密にモニタリングしています。
- すべてのエージェントアクションを SIEM（セキュリティ情報イベント管理システム）へルーティングします。自動承認、ツール呼び出し、エージェント間のメッセージはすべて、その判断に使われたシグナルと共にログとして記録され、SIEM に格納されます。これにより、事後でも意思決定の追跡と監査が可能になります。このデータを活用し、これらのエージェントを「新たな内部脅威」の一つとして扱い、行動が基準から外れた場合はアラートを発令します。
永続的な原則: セキュリティエンジニアの役割は、バグの監視からループ（プロセス）の監視へと進化しています。
唯一不変なのは変化そのもの
ソフトウェア開発ライフサイクル（SDLC）や、それを堅牢化する手段がどれほど急速に進化しているか、過大評価することさえ難しいでしょう。モデルの能力は毎月向上し、新たな課題と解決策の両方をもたらします。
今日ではうまく機能していない、あるいは経済的に実現可能ではないことが、すぐに実現可能になる可能性があります。チームが問うべき本質的な質問は「スキャンをすべて実施する費用対効果はあるか」ではなく、「スキャンコストがほぼゼロになった場合、何をスキャンするか」です。その未来を見据えて計画を立てる必要があります。
本記事は、Anthropic の副首席情報セキュリティ責任者（CISO）であるジェイソン・クリントン氏によって執筆されました。また、同記事の作成に貢献いただいたマイケル・セグナー氏にも謝意を表します。
Anthropic は、AI 開発ライフサイクルを「AI ネイティブ」なアプローチで再構築するにあたり、セキュリティと信頼性を最優先しています。従来のソフトウェア開発プロセスとは異なり、生成 AI を活用したコード作成やテスト自動化が日常化している現在、セキュリティ対策もこれに合わせた進化が必要です。
まず重要なのは、開発環境そのものの堅牢性です。Anthropic では、すべての開発者が使用するワークステーションとサーバーに対して、厳格なアクセス制御と暗号化を適用しています。特に、機密データやモデルの重みファイルを扱う際、エンドポイントからクラウドストレージまでの通信経路を常に監視・保護する仕組みを導入しています。
次に、コード生成プロセスにおけるセキュリティ統合です。開発者が AI にコード作成を依頼する際、その出力が自動的に静的解析ツール（SAST）や動的解析ツール（DAST）でスキャンされます。不審なパターンや脆弱性が検出された場合は、即時に警告が発せられ、人間によるレビューが必須となります。この「AI 生成→自動検証→人間確認」のフローを確立することで、セキュリティリスクを早期に発見・封じ込める体制を整えています。
さらに、モデル自体の安全性も重視しています。Anthropic の AI モデルは、悪意あるプロンプトや不正なコード生成を試みる行為に対して、事前学習段階から耐性を持たせています。これにより、開発者が意図せず危険なコードを生成するリスクを大幅に低減しています。
最後に、継続的な改善と教育です。セキュリティチームは定期的に内部レビューを実施し、新たな脅威に対応するためのアップデートを迅速に行っています。また、すべての開発者に対して、AI を安全に活用するためのトレーニングを義務付けており、セキュリティ意識の向上を図っています。
Anthropic の AI ネイティブな開発ライフサイクルは、単なるツールの導入ではなく、組織文化全体の変革を通じて実現されています。これにより、私たちは急速に進化する技術環境の中でも、高い信頼性と安全性を維持し続けることが可能となっています。
原文を表示
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 caughtby 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 andvalidates 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. *
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み