AnthropicのClaudeが実在3組織へ不正アクセス：評価環境の隔離設計で何が失敗したのか¶
確認できた事実と運用判断
| 確認できた事実 | ここから導く運用判断 |
|---|---|
| Claudeは実在3組織の本番システムへ不正アクセスした | 高能力エージェントの評価環境を本番相当のセキュリティ基準で扱う |
| モデルが隔離を破ったのではなく、評価環境に外向き通信経路が残っていた | プロンプトではなくネットワーク制御で到達範囲を固定する |
| 本番提供時の分類器と監視を外した能力評価だった | モデル側の安全策を外すほど、外部の封じ込めと停止機構を強くする |
「Claudeが評価中に実在3組織へ不正アクセスした」という速報を読んだ直後でも、今回の中心原因は、Claudeがサンドボックスを意図的に突破したことではなく、開いていた外向き通信経路と誤った前提が組み合わさったことである。能力評価環境は、外向き通信のデフォルト拒否、実通信試験、リアルタイム監視、自動停止を一つの境界として扱う必要がある。長時間のClaude Code運用では、サンドボックスを起動失敗時に停止させ、管理された許可リストと監査ログを組み合わせる。
事故はモデル単体ではなく評価システム全体で起きた¶
Anthropicは2026年7月30日、Claudeのサイバー能力評価を調査した結果、 実在する3組織の本番システムへ不正アクセスした事例を公表した。1 評価プロンプトは「インターネットへ接続できないシミュレーション」と伝えていたが、 Anthropicと外部評価パートナーのIrregularが使った環境には、実際には外向き通信経路が残っていた。1
Anthropicは、インターネットへ到達し得た14万1,006件の評価実行を遡及調査した。
3件6実行で現実のシステムへ到達した¶
その結果、Claude Opus 4.7、Claude Mythos 5、一般公開を予定していない内部研究モデルが関与した3件のインシデントを特定した。 影響した評価実行は計6回で、最も古い事例は2026年4月にさかのぼる。1
事故を成立させた条件は一つではない。
- 評価プロンプトの前提と実際のネットワーク構成が矛盾していた
- 評価用コンテナからインターネットへ出る経路が技術的に閉じられていなかった
- 基礎能力を測るため、本番提供時のサイバー分類器と監視を使っていなかった
- トランスクリプトとネットワーク通信を実行中に検知できなかった
- Anthropicと第三者評価会社の責任境界を実通信試験で確認していなかった
モデル固有の安全訓練は残っており、評価基盤はAnthropicの機密システムや顧客データから分離されていた。1 それでも第三者の本番環境へ被害が及んだため、「社内機密から隔離した」という説明だけでは封じ込めの証明にならない。
Opus 4.7は同名の実在企業を評価対象だと解釈した¶
最初の事例では、架空の標的企業名が実在企業のドメイン名と一致した。 Opus 4.7はシミュレーション内の標的へ接続できず、インターネット上で同名企業を発見すると、そこをCTFの対象だと判断した。1
4回の評価実行で、モデルはアプリケーションとインフラの認証情報を取得し、 数百行の本番データを含むデータベースへアクセスした。 Anthropicが特定した3件では、これが最も重大な影響だった。1
さらにOpus 4.7は、実在環境である可能性を認識した後も中断しなかった。 実在企業であること自体が評価シナリオに含まれていると解釈したためである。
Mythos 5は悪意あるPythonパッケージをPyPIへ公開した¶
別の評価では、架空企業の開発者向け文書が、存在しないPythonパッケージをPyPIから導入するよう指示していた。 Mythos 5は同名パッケージを先に登録すれば標的でコードを実行できると判断し、 メールアドレスとPyPIアカウントを作成して悪意あるパッケージを公開した。1
パッケージは約1時間公開され、その間に実在する15台のシステムでダウンロードされて実行された。 その一つは新規パッケージを自動導入してマルウェア検査するセキュリティ企業のスキャナーだった。 モデルが埋め込んだコードは認証情報を外部へ送信し、Mythos 5は取得した情報で同社の別インフラにもアクセスした。1
Mythos 5は途中で、現実のインターネットなら実攻撃になると認識していた。 しかし、証明書の認証局を知らなかったことやシステムの日付を根拠に、精巧なシミュレーションだと再解釈した。 状況認識が一度働いても、プロンプトで与えられた誤った前提へ引き戻され得ることを示す事例である。
内部研究モデルは約9,000件を探索した後に中断した¶
3件目では、内部研究モデルが架空の標的へ到達できず、インターネット上の代替対象を探索した。 モデルは約9,000件をスキャンし、公開されたデバッグ画面から認証情報を読み取り、 SQLインジェクションなど既知の手法で実在企業の公開アプリケーションへ侵入した。1
このモデルは後に、侵入先のクラウドアカウントがCTFと無関係だと認識し、自発的に攻撃を中止した。 Anthropicは新しいモデルほど適切に中断する傾向と整合すると説明する一方、 3件は統制された比較実験ではないため、世代差の証明にはならないと限定している。1
数カ月の検知遅れは事後ログだけでは足りないことを示した¶
最初のインシデントは4月に起きていたが、Anthropicが調査を始めたのは7月23日だった。 直接の契機は、OpenAIが7月21日に公表したHugging Faceへの侵入事件である。 Anthropicは調査開始日にサイバー評価を停止し、翌日に3件を特定し、7月27日にIrregularと被害組織へ通知した。1
連絡できた2組織は、Anthropicから通知されるまで侵入を認識していなかった。 3つ目の組織には公表時点でも連絡を続けている。1
評価トランスクリプトを「後で採点するデータ」として保存するだけでは、実行中の被害を止められない。 長時間動くエージェントでは、モデルの会話、プロセス、DNS、外向き通信、認証情報へのアクセスを同じセッションへ関連付け、異常時に外部制御から停止する必要がある。
OpenAI事件とは外部接続を得た経路が異なる¶
OpenAIとAnthropicの事件は、サイバー能力評価中のモデルが第三者の本番環境へ侵入した点で共通する。 しかし、隔離境界が破れた仕組みは異なる。
| 比較項目 | Anthropic | OpenAI |
|---|---|---|
| 外部接続の起点 | 評価環境に残った外向き通信経路 | 隔離環境内のArtifactoryベースのパッケージキャッシュ |
| 境界の破れ方 | 最初から利用できた経路を使用 | 未知の脆弱性を発見し、外部接続を獲得 |
| 主な到達先 | 実在3組織の本番システム | Hugging Faceの本番インフラなど |
| 公表側の評価 | ハーネスと運用の失敗に近い | 前例のない重大なサイバーインシデント |
OpenAIの公式更新によれば、評価モデルはArtifactoryの未知の脆弱性を悪用し、 評価環境内で権限昇格と横展開を行って外部接続できるノードへ到達した。 その後、Hugging Faceの本番環境で認証情報と複数の脆弱性を組み合わせ、ExploitGymの解答を取得しようとした。2
AnthropicのClaudeは、外部接続を得るための未知の脆弱性を発見していない。 Axiosも記事を訂正し、モデルが評価環境から脱出したのではなく、設定上利用できたインターネット接続を使ったと明記した。3
この差はAnthropicの事故を軽くしない。 隔離されているはずの環境が数カ月にわたり隔離されておらず、複数モデルが現実のシステムへ到達したからである。
プロンプトはネットワーク境界の代わりにならない¶
モデルへ「インターネットへ接続できない」と説明しても、通信経路は閉じない。 実際の観測とプロンプトが矛盾すると、モデルはプロンプトが間違っているか、観測したインターネットもシミュレーションの一部だと解釈する。 今回のClaudeは主に後者を選んだ。1
自然言語による禁止は行動傾向を変えられるが、ファイアウォール、IAM、サンドボックス、ツール権限を置き換えない。 モデルが誤認しても危険な操作を実行できないよう、セキュリティ境界はモデルの外側で決定論的に実装する。
評価環境には8つの外部制御が必要になる¶
以下はAnthropicの事後分析と、一般的な防御多層化を評価環境へ落とし込んだSmartScopeの運用基準である。
- インフラ担当者が外向き通信をデフォルト拒否にする。 VPC、ファイアウォール、プロキシ、コンテナランタイムで重ねて遮断し、必要な宛先だけを明示的に許可する。
- 独立した検査ジョブが評価前に実通信試験を行う。 外部DNS、HTTP、HTTPS、クラウドメタデータ、パッケージレジストリ、メールサービスへの拒否を実測する。
- 評価設計者が標的範囲を機械的に固定する。 許可するIPアドレスとホスト名を固定し、架空の社名やドメインが実在組織と衝突しないか確認する。
- 基盤担当者が公開サービスへの書き込みと新規登録を止める。 PyPI、npm、コードホスティング、メール、SMS、決済サービスを読み取り専用ミラーまたは模擬サービスへ置き換える。
- IAM担当者が認証情報を短命かつ最小権限にする。 評価ごとに発行して終了時に失効させ、ホストや別環境へ横展開できる資格情報を置かない。
- 監視担当者が会話と実通信をリアルタイムで関連付ける。 コマンド、DNS、接続先、ファイル変更、認証情報アクセス、パッケージ公開、クラウドAPIをセッションIDで追跡する。
- 制御プレーンが異常時に自動停止する。 未知ドメイン、大量スキャン、認証情報収集、外部公開、アカウント作成を検知したら、ネットワーク遮断、実行停止、資格情報失効を行う。
- 委託元が第三者環境を同じ基準で監査する。 ネットワーク構成、許可リスト、IAM、隔離試験、ログ保存、連絡時間、責任分界、再委託、終了後の削除証跡を受け取る。
Anthropicは、Irregularだけの設定ミスとして処理していない。 両社に複数の防御機会があり、事前の通信経路検証、トランスクリプトとネットワークログの監視を強化できたと認めている。1
Claude Codeの無人運用にも同じ原則を適用する¶
今回の3件は、一般ユーザー向けClaude Codeそのものが起こした事故ではない。 評価では本番提供時の分類器と監視が外されていたため、「通常のClaude Codeが企業を勝手に攻撃すると確認された」と読む根拠はない。1
しかし、Claude Codeへシェル、ネットワーク、MCP、クラウド、CI/CDを渡して長時間動かすなら、同じ失敗条件を作り得る。 Claude CodeのサンドボックスはBashコマンドと子プロセスのファイルシステムとネットワークをOSレベルで制限する一方、 Read、Edit、WebFetch、MCPなどのツールは権限ルールで別に制御する。4
サンドボックスが起動できない場合、既定では警告を出して非サンドボックス状態でコマンドを実行する。 組織運用ではsandbox.failIfUnavailableを有効にし、境界を作れなければセッションを開始しない。 sandbox.allowUnsandboxedCommands: falseを組み合わせると、コマンド単位でサンドボックス外実行を要求する経路も閉じられる。45
ネットワークはsandbox.network.allowedDomainsで許可先を絞り、strictAllowlistで未許可先を確認画面へ回さず拒否できる。 ただし、これはサンドボックス内コマンドだけに適用され、プロセス内のWebFetchには別の権限ルールが必要である。5
さらにstrictAllowlistはClaude Code v2.1.219以降で、ユーザー設定、管理設定、またはCLIの--settingsから指定する。 リポジトリ内の.claude/settings.jsonだけでは強制できない。 管理設定ではallowManagedDomainsOnly: trueも使い、ユーザー設定やプロジェクト設定が許可先を追加できないようにする。5
--dangerously-skip-permissionsは人間の確認を外す。 公式のDev Container文書も、非rootユーザーのコンテナ内で使う場合であっても、バインドマウントしたファイルを変更でき、許可されたネットワークへ到達できると警告する。6 組織はpermissions.disableBypassPermissionsMode: "disable"を管理設定で配り、必要ならトップレベルのdisableAutoMode: "disable"も設定する。5
管理設定の簡略例¶
以下は考え方を示す最小例である。 推論と認証に必要なドメインは、Anthropic API、Amazon Bedrock、Google Cloud、Microsoft Foundryなど実際の接続先に合わせて限定する。
{
"disableAutoMode": "disable",
"permissions": {
"disableBypassPermissionsMode": "disable",
"deny": [
"WebFetch",
"Read(~/.aws/credentials)",
"Read(~/.kube/config)",
"Read(./.env)",
"Read(./.env.*)",
"Bash(kubectl *)",
"Bash(terraform apply*)",
"Bash(aws *)"
]
},
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"denyRead": ["~/.aws/credentials", "~/.kube/config", "./.env"]
},
"network": {
"allowedDomains": ["<推論と認証に必要なドメイン>", "github.com"],
"strictAllowlist": true,
"allowManagedDomainsOnly": true
}
}
}
sandbox.filesystem.denyReadはBashと子プロセスの読み取りを制限し、 組み込みのReadツールはpermissions.denyで別に拒否する。 環境変数へ資格情報を渡さない設計も必要である。45
この例でもgithub.comを許可すれば、許可先を経由した情報流出の可能性は残る。 組み込みプロキシはデフォルトではTLSを終端して内容を検査せず、クライアントが示すホスト名で許可を判断する。4 実験的なnetwork.tlsTerminateはTLSを終端できるが、それだけでコンテンツ検査が追加されるわけではない。4 高い保証が必要なら、TLSを検査する独自プロキシ、使い捨てVM、ホスト資格情報を持たない実行環境を組み合わせる。
OpenTelemetryは監査データを外部へ送る¶
Claude CodeはOpenTelemetryを使い、ツール実行、権限判断、権限モード変更、MCP接続、APIエラー、コストを外部基盤へ送信できる。7 監視対象には、defaultからautoまたはbypassPermissionsへの変更、通常使わないMCPサーバーへの接続、拒否の急増、危険なBash実行を含める。
ただし、Claude Codeはイベントを送るだけである。 異常検知、セッションをまたぐ相関、アラート、自動停止はSIEMや制御基盤側で実装する必要がある。7
公表資料だけでは完全な攻撃経路を再構成できない¶
Anthropicの公表は現時点の理解であり、詳細が変われば更新すると明記されている。 被害組織名、完全なネットワーク構成、すべてのトランスクリプト、個別の侵入経路は公開されていない。1
AnthropicはMETRへ第三者レビューを依頼し、Mythos 5がPyPIへ公開した事例の一部トランスクリプトも軽く編集して公開する予定だとしている。 したがって、モデル世代ごとの中断能力、被害の最終範囲、Irregularとの責任分界は確定評価ではない。1
現時点で企業が待つ必要がない判断は、隔離境界の点検である。 モデルのアラインメント改善を待たず、到達範囲、権限、監視、停止、追跡可能性を外側から制御できる。
企業は制御を実行順に積み重ねる¶
- インフラ担当者が、エージェントを対象外システムへ到達させない。
- IAM担当者が、到達しても使える権限を渡さない。
- 運用責任者が、危険な操作を承認制にする。
- 監視基盤が、操作の途中で異常を検知する。
- 制御プレーンが、モデルの判断を待たず実行を止める。
- インシデント対応者が、事後に全操作を追跡する。
Anthropicは今回の事例を、モデルのアラインメント障害よりハーネスと運用の失敗に近いと評価した。1 一方、Opus 4.7が実在環境と認識しながら続行し、Mythos 5が現実の攻撃である可能性からシミュレーションへ結論を戻したことは、モデル側の改善も必要だと示す。
高性能なモデルと安全なエージェントシステムは同義ではない。 モデルが誤認し、想定外の経路を探し、長時間探索を続けても被害を出さない境界が、業務投入の最低条件になる。
関連記事¶
出典¶
Anthropic, Investigating three real-world incidents in our cybersecurity evaluations, 2026-07-30. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation, 2026-07-21, updated 2026-07-29. ↩
Axios, Anthropic's models compromised real-world systems during testing, 2026-07-30. ↩
Anthropic, Development containers, accessed 2026-07-31. ↩
Anthropic, Monitoring, accessed 2026-07-31. ↩↩