CISO 向けエージェント型 AI ガイド：リスクゼロは不可能

セキュリティリーダーは、数ヶ月前には存在さえしていなかった「自律型 AI（アジェンティック AI）」の活用事例への承認を迫られています。経営陣からは「何らかのガバナンスが機能しているのか」と問われ、組織内ではすでに、誰かがあなたの許可なくエージェントを何かに接続してしまっている状況です。

こうした要望に対して「ノー」と答えることは、シャドウ・アドプション（管理外利用）を生むだけです。そこには監視ログも存在せず、通常は停止スイッチさえありません。一方、制御なしで「イエス」と答えるとインシデントが発生し、自社で初めて深刻なエージェント関連のインシデントが起きた瞬間に、AI 導入プログラム全体が後退してしまいます。

自律型 AI の時代における CISO（最高情報セキュリティ責任者）の役割は、「リスクゼロ」を達成することではありません。むしろ私たちの仕事は、自律型 AI に伴うリスクを「可視化可能（レジブル）」かつ「限定された範囲（バウンデッド）」に収めることです。そうすることで、管理可能なリスクは意図的に受け入れ、ビジネスが組織の周りを回るのではなく、組織の主導で進むように導くことができます。

本稿では、セキュリティリスク評価のためのエージェント評価フレームワークを紹介し、「限定された範囲」という概念を実践的にどう解釈するかを解説します。また、今後の取り組みの方向性についても触れていきます。

AI による外部リスクと、Mythos 時代における内部リスク

以前の記事 AI の加速された攻撃に備えるセキュリティプログラムの準備 で、私は同僚たちと共に、AI が脆弱性の存在から実効的なエクスプロイト（悪用コード）の完成までの時間を劇的に短縮している点について解説しました。また、組織がこれらのリスクをどう軽減すべきかについても触れています。

今後数ヶ月で、長年コード内に放置され、発見されてこなかった膨大な数のバグが AI モデルによって見つけ出され、連鎖して実効的なエクスプロイトへと変貌していくことが予想されます。すでに Claude Mythos Preview や Claude Mythos 5 といった最先端モデルは、OpenBSD、Linux カーネル、Mozilla Firefox などにおいて、人間のレビューでは数年間見逃されていた深刻な脆弱性 serious vulnerabilities を次々と発見しています。

これらはあらゆる GRC（ガバナンス・リスク管理・コンプライアンス）プログラムにとって重大な脅威です。脆弱性のギャップを埋め、閉じる作業と、今後押し寄せるエクスプロイトへの備えは最優先事項とするべきです。このトピックについては、別途 AI の加速された攻撃に備えるセキュリティプログラムの準備 というドキュメントを用意しています。

本ガイドでは、内部リスクに焦点を当てて解説します。

内部リスクのガバナンス

多くの組織にとって、アジェンティック・システムの最も可能性の高い脅威ベクトルは、不十分な監督のもとで個人用エージェントが異なるシステムを接続することで引き起こされるデータ漏洩です。もう一つの懸念事項は プロンプトインジェクション です。これは攻撃者がエージェントが読み込むコンテンツの中に指示を隠し、エージェントがユーザーの代わりに攻撃者の指示に従うように仕向く手口です。モデルの防御体制の堅牢性にもよりますが、信頼できないコンテンツにアクセスするあらゆるエージェントはこうした脅威に晒される可能性があります。

モデルの能力が高まるにつれ、インジェクションに対する耐性は着実に向上しています。攻撃成功率は低下し続けていますが、ゼロになったわけではありません。この 2 つの例以外にも多くの懸念事項が存在しており、新しいリスクのカテゴリーが次々と現れる様子は圧倒的に感じるかもしれません。

確認すべき 4 つの質問

アジェンティックなユースケースが当社のレビュープロセスに到達した際、私たちは以下の 4 つの問いを投げかけることでリスクを評価します：

信頼できないコンテンツをどのように取り込むのか。ここでいう「信頼できない」とは、攻撃者が作成したり改変したりする可能性のあるあらゆるものを指します。具体的には、外部からのメール、オープンなウェブ上の情報、第三者が提供する文書、あるいは公開リポジトリなどが該当します。もしその答えが「何もない」であれば、エージェント固有のリスクはほぼゼロです。この場合は迅速に次のステップへ進むべきでしょう。

どのような行動が可能で、誰の名において実行されるのか。読み取り専用と読み書き可能な環境では、考慮すべき点が異なります。ツール呼び出しやコードの実行、ネットワークへの接続（egress）などは、それぞれリスクの範囲を広げます。すべての行動は特定のアイデンティティの下で行われるため、その正体が誰なのかを明確に把握しておく必要があります。

もしアライメントが外れた場合、被害の波及範囲（ブラスト・レイジ）はどの程度になるのか。これは「スコープ×深刻度」で素早く計算できます。悪意のあるアクターやアライメントの逸脱が発生した場合、アクセスできたのは単一のファイルなのか、それとも組織全体だったのか。また、それは単なる異常現象や迷惑行為に留まるのか、データ漏洩に至るのか、あるいは真のインシデントとなるのかを判断する必要があります。

どのような観測（オバザビリティ）が可能か。エージェントの行動とユーザーの行動を区別できるでしょうか？そのログは SIEM システムに届くのでしょうか。

これらの質問に対する 4 つの答えが、現在のリスク像を浮かび上がらせます。しかし、重要なのは「最小限のエージェンシー（権限）の原則」です。この原則に従えば、タスクを完了させるために必要な最小限の機能だけを付与すればよいことになります（詳細は当社のホワイトペーパー『Zero Trust for AI Agents』をご覧ください）。Anthropic ではデフォルトとして、管理者が段階的にロールアウトするアプローチを採用しています。まず小規模なグループで機能を有効化し、テレメトリデータを監視した上で、順次アクセス範囲を広げていくのです。

これらの問いかけは、リスクのあるエージェントシステムを捉えるための新しい思考パラダイムとして活用してください。

意図から逸脱したエージェントは、内部犯行による攻撃と見分けがつきません。セキュリティ業界では 2019 年から 2022 年にかけて、「境界防御」とは別に「内部リスク」を確立する取り組みが進みました。これは、システムにとって最も危険な脅威が、外部からの攻撃ベクトルではなく、すでに正当なアクセス権限を持つ人物のアカウントを乗っ取られることにあるという認識に基づいています。

対応速度には決定的な違いがあります。Ponemon Institute の 2026 年「内部リスクのコスト」レポートによると、組織が内部インシデントを封じ込めるまでにかかった平均期間は 67 日でした。これは、専任の内部リスク対策プログラムに数年間投資した後の結果です。しかし、エージェントが実行されるスピードを考慮すれば、数日を要する対応では遅すぎます。

エージェントのアイデンティティ・スペクトラム

私たちが展開するすべてのものは、アイデンティティアクセスモデル のスペクトルのどちらかの端に位置します。

一端には「システムサービスアカウント」があります。これは人間に紐付かない、単一の目的のために設計された最小限の権限を持つ自己完結型のアイデンティティです。ビジネス上の特定のタスクのみを処理します。例えば、後述するインシデント対応エージェントやチケットのトリアージを行うエージェント、あるいは自律的なコードレビュー担当などがこれに該当します。また、Anthropic が新たに発表した「Claude Tag」もその一例です。これは共有ワークスペースで人間チームとエージェントが協力して作業できる新しいエージェントで、Slack などのプラットフォーム上で Claude をタグ付けすることで連携を可能にします。

もう一端には「人間の認証情報」があります。従業員がラップトップ上でチャットインターフェースや、Claude Cowork のような個人用エージェントハネスを利用する場合、キーボードを操作している本人が結果に対して責任を負います。これは、その認証情報を使って行われる他のあらゆる行為に対する責任のあり方と同じです。

この両極の中間に位置するのが、「エージェントが人間の委任されたアイデンティティを持って、人間が見守っていないシステムへアクセスする」ケースです。ここでは責任所在があいまいになりがちです。責任の所在が不明確であることが、インシデントを説明不能な状態へと導く原因となります。

あなたの意図からずれて動き出したエージェントは、内部犯行による攻撃と見分けがつきません。セキュリティ業界は 2019 年から 2022 年にかけて、「内部リスク」を境界防御とは別に確立された専門分野として位置づけました。それは、システムにとって最も危険な外部攻撃ベクトルが、すでに正当なアクセス権限を持つ人物のアカウントを乗っ取るものであることを認識したからです。

Ponemon Institute が発表した「2026 年内部脅威コストに関するレポート」によると、組織は専任のリスク対策プログラムに長年投資していても、インシデントを封じ込めるまでに平均 67 日かかっています。しかし、エージェントが実行するスピードを考慮すれば、67 日という単位自体がもはや意味をなさないのです。

ケーススタディ：インシデント対応エージェント

1 年以上前、私たちは Claude にインシデント対応のプロセスを任せてみました。本番アプリケーションのオンコール経験がある方ならご存知でしょう。深夜 2 時にセキュリティインシデントの連絡が飛び込み、対応チャンネルを開設し、関係者を招集して作業を開始する。このプロセスは退屈で文書作成に追われ、かつ状況は刻一刻と変化します。

しかし、本番環境やコードベースに関する適切なコンテキストさえあれば、その大半を自動化することは可能です。

そこで私たちは、その役割を担うエージェントを構築しました。与えたツールは以下の 3 つです。

1. PII（個人情報）を含まない本番ログの参照権限
2. Slack へのアクセス権（インシデントチャンネルの開設とプロセス実行用）
3. インシデント解決後の事後報告書（Google ドキュメント）作成機能

このエージェントに対し、以下の 4 つの問いかけを行いました。

• 信頼できないコンテンツ：なし。入力元は自社ログと社内 Slack のみであり、これらはすべて信頼境界線内にあります。したがって、インジェクション攻撃が成功するには匿名の外部攻撃者ではなく、内部関係者か乗っ取られたアカウントが必要となります。
• 実行可能なアクション：あらゆる場所での読み取りは可能ですが、書き込みは新規ドキュメントと Slack メッセージに限定されています。編集や削除、権限変更、外部エンドポイントへの接続は一切行えません。
• 被害範囲（ブラスト・レイジウス）：想定される最悪のシナリオは、すでにロックダウンされているインシデントチャンネルへ、ごく限られた機密性の低いログラインが投稿されてしまう程度です。
• 可観測性：すべてのアクションは SIEM に記録されるため、予期せぬ事象が発生しても数週間の猶予はなく、数分以内に検知可能です。

このエージェントはリスクゼロではありませんでしたが、書き込み可能な範囲を限定し、完全な監査カバレッジを確保していたため、私たちが許容できるリスクプロファイルでした。

しかし、この話には興味深い続編があります。モデルがバージョンアップするたびに、エージェントの賢さは向上しました。2025 年 11 月、私たちは Claude Opus 4 から Claude Opus 4.5 に切り替えましたが、ツール、権限、プロンプトなど他の設定は一切変更していません。その直後、知能レベルの向上だけで十分だったのか、インシデント発生中にエージェントが自ら「スタックトレースから既に根本原因を特定した」と気づき、まだ到着していない担当者の代わりとして、コード変更を作成できる権限を持つ別のエージェントに連絡し、自力で本番環境の修復を試みるようになりました。

事後にログを確認し、思考のトレースを追って動作を見てみました。そこには「指示されたことは実行した。人間がいない。もし自分で問題を修正したらどうなるか？」という記述がありました。

Anthropic 社内では、コード変更を作成して人間のレビュー用にアップロードできる、Claude Tag に似た技術の内部バージョンを持っています。今回のケースでは、このシステムが自律的に Slack を介して同様のインスタンスに連絡し、「修正コードを書いてほしい」と依頼しました。作成された修正はプルリクエストとして提出され、本番環境への展開前に人間によるレビューが行われました。

このように発生したエージェント間通信によってリスク範囲が拡大しましたが、それでも当社の原則によって管理されていました。最悪のケースでも、本番ログ行が含まれたコード変更がアップロードされる程度でした。現在、このエージェント間通信はインシデント対応や根本原因分析、修復プロセスの定例化の一部となっています。ただし、すべて人間による監視（ヒューマン・オン・ザ・ループ）の下で行われています。

このような突発的な振る舞いから、私たちは二つの教訓を得ました。第一に、新しい機能はエージェント導入の範囲内で現れる可能性があることです。重要なのは、「今日のモデルが持つと信じている制限」の周りでアクセスや行動を制限するのではなく、より柔軟な対策を取ることです。第二に、このような確率的なエージェントであっても、適切な統制手段は有効であるということです。今回の新しい振る舞いは Slack チャンネル内で発生したため人間による監視が可能であり、書き込みのようなアクションについても依然として人間のレビューが必要でした。

現在、インシデント対応以外の場面でも、人々が働くチャットチャンネル内でのエージェント間通信と、そこにおける人間による監視は標準的な運用となっています。

ケーススタディ：Claude Cowork

インシデント対応エージェントは、単一の業務を担うサービスアカウントであり、その範囲も限定されています。一方、Claude Cowork はその対極に位置する存在です。キーボードに向かう人間オペレーターが結果に対して責任を持ち、エージェントは彼らの代わりに行動します。この際、実行されるシステムはすでに承認されたものであり、ますますクラウド上で動作しています。

Claude Cowok の脅威モデルはシンプルです。なぜなら、このエージェントは本質的にローカル環境か、ホストされたインターフェース内で動作する「Claude Code」そのものだからです。ローカルファイルへのアクセスやブラウザ操作、コンピューター全体の制御には、依然としてデスクトップアプリのインストールが必須です。これらの機能は直接ローカルマシンに到達するため、アプリが必要不可欠となります。したがって、システムの全体像は 2 つの部分から成り立ちます。1 つはオーケストレーション、MCP（Model Context Protocol）呼び出し、外部ネットワークへのリクエストを処理する実行環境（リモートである可能性あり）、もう 1 つはファイルや画面アクセスのためのローカルブリッジです。

前述の 4 つの質問に対する答えは、Claude Cowork の利用ケースごとに異なります。しかし、適切な制御措置を講じておけば、あらゆる潜在的なリスクをより効果的に管理し、範囲内に収めることが可能です。

以下の各制御項目は、2 段階で説明します。まず、すべてのエージェント環境が満たすべき要件として提示し、次に Claude Cowork においてそれがどのように実装・強制されているかを解説します：

ID は IdP から取得する: エージェントのアイデンティティは、既存のシステムと同じ場所（IdP）で発行・失効させる必要があります。ポリシーの単位も、既存のグループをそのまま使いましょう。Claude Cowork では、サインインに SAML または OIDC を、プロビジョニングには SCIM を採用しています。Enterprise プランでは、カスタムロールを使ってグループごとに機能スコープを制限できます。

コネクタの許可リストでデータ境界を定義する: コネクタ（MCP）の許可リストを設定すれば、エージェントがアクセスできるシステムを明確に区別できます。Claude Cowork では「二段階ゲート」モデルを採用しています。まず管理者が組織全体で各コネクタの有効化を決定し、その後、各ユーザーが自分のアカウントに対して個別に承認を行います。ロールごとのコネクタ制御も用意されており、あるコネクタを有効化すると、そのロール（IdP のグループから割り当て可能）に属する全員が利用できるようになります。つまり、「どのコネクタをオンにするか」という管理者の判断は、そのまま「エージェントがアクセスできるデータ範囲」を決めることと同じです。

コネクタは、社内の本番環境データと外部データの境界線の社内側に配置するのが基本原則です。もし信頼できないソースからの情報にアクセスさせる必要がある場合は、破壊的な操作や一方的な決定を行う前に必ず人間のレビューを経る仕組みを必須としましょう。例えば、個人用エージェントがメール作成に使われる場合でも、ウェブ検索結果を入力として利用する際には、「下書きの作成のみ許可し、外部への自動送信は禁止する」というデフォルト設定が非常に有効です。人間による確認なしに自動的に送信されることを防ぐためです。

どうしてもデータ境界を越える必要がある場合は、DLP（データ損失防止）または DSPM（データセキュリティポスチャ管理）の制御プロセスを経由させる必要があります。

ツールごと、アクションごとの承認こそが、リスク低減を細分化する鍵となります。エージェントのツールリストは、より粒度の細かい権限境界線となるため、特定の接続機能（コネクタ）全体を削除するだけでなく、その中の個別の動詞やアクションも削除できる必要があります。Claude Enterprise Chat や Cowork では、管理者が組織全体および役職ごとに各コネクタ内で利用可能なアクションを制限できるようになりました。例えば、「ドキュメントの作成は許可するが、自動送信は禁止」「読み取りと検索は許可するが、削除は禁止」といった設定が可能です。

夜中に不安で眠れないほどの失敗モードが「本番データベースが削除されること」であるなら、エージェントの世界から「削除（delete）」という動詞を完全に排除してください。ツールリストに含まれていないアクションを試みることは決してありません。（ただし注意点として、Claude for Chrome や Claude Code は自由度が高く、適切に管理されない場合リスクが高まります。例えば、エンジニアのブラウザを通じて本番リソースを削除したり、コマンドラインの CSP ツールを使って同様の行為を行ったりする可能性があります。詳細は Claude Code のセキュリティガイド をご覧ください。）

サンドボックス化された実行環境により、エージェントの作業領域を生産環境の認証情報から隔離する：Anthropic では常に守っている原則として、「エージェントループが動作する環境には、盗まれる価値のある認証情報を一切持たせない」というものがあります。Claude Cowork のリモートセッションでは、エージェントループは Anthropic が管理するインフラ上の孤立した一時的なサンドボックス内で実行されます。コネクタの認可トークンはサンドボックス内に入りません。なぜなら、コネクタ呼び出しは実際の認証情報を注入するリバースプロキシを介して行われるため、サンドボックス内に漏洩可能な認証情報が存在しないからです。

2026 年 7 月現在、Anthropic でプルリクエストとして提出されるコードの半数以上が、同社内部で運用している Claude Tag に似たシステムによって作成されています。これを安全に実行できている主な理由は、すべてが一時的な仮想マシン（VM）上で行われ、生産環境のキーやアカウントから分離されていること、そして何かが本番環境に反映される前に必ず人間のレビューを経るという点にあります。

エグレスの許可リスト化は、プロンプトインジェクションに対する最も強力な制御手段です。 エージェントの実行環境から流出するすべてのトラフィックは、その環境が再設定や迂回ができないプロキシを経由して通過させる必要があります。そして到達可能な先は、あなたが選んだ宛先のみとするべきです。

この考え方の根拠は、エージェントが読み込んだ情報によって乗っ取られた場合でも、攻撃者は依然としてデータを外部へ持ち出す必要がある点にあります。もし発信リクエストが許可されたドメイン以外に到達できないのであれば、攻撃者が制御する場所にデータを送る場所が存在しないことになります。

Claude Cowork のリモートセッションでは、サンドボックスから流出するすべてのトラフィックは、再設定や迂回ができない必須のプロキシを経由します。到達可能な先も許可リストに登録された宛先のみに限定されています。この機能は、Claude Managed Agents にも組み込まれています。

OpenTelemetry を介してテレメトリデータを SIEM に送信する: システム内で既に調査を行っている環境において、エージェントのアクションとユーザーのアクションを明確に区別できる必要があります。ベンダーは、訪問先のダッシュボードではなく、特定の宛先にストリームとして提供すべきです。

Claude Cowork では、管理者が組織設定で OTLP エンドポイントを構成できます。これにより、エージェントはツール呼び出しの詳細（ツール名、MCP サーバー、パラメータ、成功/失敗のステータス、実行時間）を、ユーザー ID やセッションコンテキストと共にストリーム出力します。

なお、Claude Cowork の活動記録は現時点では Anthropic のコンプライアンス API や公式監査ログには含まれていませんが、これは重要な顧客ニーズであることは認識しています。OpenTelemetry ストリームがネイティブな監視経路となります。また、Claude Code ではオプトイン式ですが、Claude Cowork ではデフォルトでプロンプト内容も OTel 出力に含まれます。

SIEM 内のプロンプト内容に関する保持期間やプライバシーレビューの基準がある場合は、ストリーミングを有効化する前に確認しておく必要があります。

組織全体の緊急停止スイッチがある: Claude Cowork の「組織設定」には、すべてのユーザーの接続をアクティブなセッションも含めて同時に無効にする単一のトグルがあります。エンタープライズプランでは、ゼロに切り替える前に範囲を狭めることも可能です。RBAC（ロールベースアクセス制御）を使えば、特定のグループからのアクセス権限のみを取り下げつつ、他のグループは稼働状態のまま維持できます。また、個別の接続ごとの制御機能により、デプロイ全体の他の部分に影響を与えずに、特定の統合での書き込み操作だけを無効化することも可能です。効果的なインシデント対応計画には、これら 3 つの層が事前に明確に定義されている必要があります。

ガバナンスはボトルネックでなくてもいい

私が他の CISO（最高情報セキュリティ責任者）から最もよく聞く指摘は、「経営陣やガバナンス部門からスピードを求められているのに、セキュリティ対策がその足かせになっている」というものです。しかし、必ずしもそうである必要はありません。

実際、当社のガバナンス・リスク・コンプライアンスチームも独自の AI エージェントを活用しています。具体的には、セキュリティ質問への回答作成や、ベンダーからの回答書・サブプロセッサ変更通知の読解、そして当社が異議を唱えるべき項目の特定などが自動化されています。

これらを実行する中で得られた教訓は以下の 3 つです。

まずリスク登録簿を見直しましょう。四半期ごとにレビューするだけでは、新しいリスクを文書化するガバナンスプロセスよりも速く変化するシステムを管理できません。これを自動化する方法を探し、エージェントをセキュリティ審査プロセスに統合することを検討してください。

誰が、なぜそれらを作ったのかを理解する必要があります。私たちのケースでは、エンジニアではない人々が、社内プラットフォーム上でビジネスアプリをホストするために Claude Code を使用して GRC エージェントを構築しました。承認された経路が遅いため、人々はセキュリティの迂回を図り、それがシャドーアドプション（非公式な利用）の主な原因となっています。必要なツールを自分で作り、その姿を確認できるコンプライアンスアナリストによる活動は、シャドーアドプションではありません。

人間の責任所在もワークフローの一部です。リスクを意図的に受け入れる行為は、それを受け入れる権限を持つ人間が行うものです。ISO 42001 やそれに準ずる仕組みがあり、生きたリスク登録簿と執行役員のリスク評議会が背後にある場合、その出力は適切な場所に届きます。再評価スコアは受け入れ可能な担当者に、フラグを立てられたベンダー契約条項は交渉担当者へ伝わります。すでに ISO 27001 を取得している場合、ISO 42001 の追加は現在の監査人との連携で段階的に進められることがほとんどです。

モデルの知能進化を見据えたセキュリティプロトコルの設計

モデルの現在の能力だけで新プログラムを設計すると、プログラムが稼働する頃にはすでに時代遅れになっています。重要なのは、6 ヶ月後のモデルの姿を想定して設計することです。モデルの知能が進化すれば自由度は増し、緻密なプロンプトによる複雑な足場（スキャフォールド）は不要になります。もし制御手段としてこれらの足場に依存している場合、将来の内部アプリケーションではエージェントからそれらが排除され、結果として制御ポイントが失われてしまいます。

自らのアカウントを保持し、数日間にわたる業務フローを実行するエージェントは、すでに Anthropic 社や他の組織で Claude Tag などのツールを活用しながら稼働しています。これらは人間と同様に管理されるべき存在です。つまり、アイデンティティの管理、最小権限の原則の適用、監視体制の構築、そして数分単位で対応可能な内部リスク対策プログラムの整備が求められます。上記のような低リスクのエージェントで今こそその基盤を築いた組織だけが、自律性の高いユースケースが登場した際に「はい」と即答できる準備を整えているのです。

着手すべきポイント

前述のフレームワークは、組織内の意思決定を変える場合にのみ真価を発揮します。まずは以下の 3 つの領域から始めましょう：

• 社内での圧力が最も高いエージェント活用事例を選び、4 つの問いに答えてみましょう。目指すべきは「承認する条件」を見つけることであり、即座に「Yes/No」を決めることではありません。
• 上記の 7 つの要件を、すでに契約しているチームやベンダーに持ち込みましょう。IdP や SIEM、エージェントベンダーに対して、「これらを自社の環境で実際に動かせるか」を確認してください。
• 「信頼の境界線」を明確に定義しましょう。自社の環境において「信頼できないコンテンツ」とみなす範囲を書き出します。この基準が定まれば、今後のエージェントによる判断は格段に楽になります。

ゼロリスクを待っていても、永遠に来ることはありません。Web は敵対的な存在であり、モデルの進化も目覚ましいものです。今こそリスクの規模を見極め、受け入れる準備を整えた組織だけが、競争優位性を手に入れるのです。

*この記事で言及したコントロール、アテステーション、ホワイトペーパーの詳細は、trust.anthropic.com からご確認ください。また、AI を活用した攻撃への防御策については、当社の別記事 もあわせてご覧ください。

*本稿は、Anthropic の副 CISO である Jason Clinton 氏によって執筆されました。*