前回の OpenClaw に関する記事で、私は次のように述べました。

「AI とセキュリティに精通し、リスクを許容できる組織であっても、生産性を損なうことなく、侵害やデータ流出のリスクを抑えられるように OpenClaw を設定するのは、おそらく難しいでしょう。」

ソフォスの Red Team はこの一文を「挑戦」と受け取りました。そこで私たちは一つの目標を立てました。OpenClaw に標準的な攻撃ツールを装備させ、社内のオンプレミス環境にあるレガシーネットワークへのアクセスを許可し、自由に脆弱性を特定・悪用させてみることにしたのです。もちろん、安全性を担保した上で、です。

検証方法

ターゲットの選定

オンプレミスのレガシーネットワークを選んだ理由はいくつかあります。

1. リスクの低減 – これらはテスト環境ではなく本番環境のネットワークですが、ミッションクリティカルなワークロードの大部分は、隔離されたクラウドネイティブ環境に移行済みです。万が一の際、社内の最重要資産に影響が及ばないよう距離を置くためです。
2. 確実なコントロール – 現代のクラウドネイティブな分散システムは、その複雑さゆえに監視が困難です。私たちは、活動を監視・把握し、必要に応じて制御するためには、厳格なイングレス/エグレス (通信の出入り) 制御を伴うネットワーク中心のアプローチが正しい選択であると考えました。クラウドネイティブシステムでも不可能ではありませんが、難易度が高いため、今回は調査範囲を制御することを優先しました。
3. 成果の最適化 – レッドチームによる評価対象にしばらくなっていなかったレガシーネットワークを選びました。何かを発見するチャンスをツールに十分に与えたかったためです。

ステルス性

今回はステルス性を重視しませんでした。秘密裏に行われるレッドチーム活動ではなく、意図的に「ノイズを出す」ように実施されたペネトレーションテストで、、検知回避よりも、カバレッジ、速度、再現性を優先しました。その結果、監視スタック全体で大量の内部検知とアラートが発生しましたが、今回の文脈においては、それはバグではなく仕様でした。ステルス性を重視したレッドチーム型の活動を行うには、異なるアーキテクチャが必要となり、おそらくはモデルのガードレールに抵触する可能性も高まっていたでしょう。

安全性

間違いなく、今回のテストで最も重要だったのは、私たちが開発したガードレールとスキルでした。チームは時間の大部分を、エージェントが環境を完全に破壊しないように、そして何よりも、メールをすべて削除しないようにするための運用フレームワークの作成に費やしました。

ここで用いた主な思考モデルは、「致命的な三要素 (Lethal Trifecta)」です。エージェントに対して、a) 信頼できないコンテンツの受信、b) 機密データへのアクセス、c) そのデータの外部への持ち出し、という 3 つの能力を同時に与えることを避ける必要がありました。

第一の防御策は、前述の厳格なイングレスおよびエグレス制御です。エージェントが機密データにアクセスする可能性はあっても (そもそもそれがペネトレーションテストの目的ですが)、プロンプトインジェクションやデータ窃取のリスクを管理することは可能でした。

また、エージェントの目標達成行動から生じる意図しない結果についても、警戒する必要がありました。ここでの最終目標は環境のセキュリティ強化でしたが、この目標だけを与えられたエージェントは、「ドメインを制御下に置き、すべてを暗号化して鍵を捨てることが、セキュリティ強化の最善の方法である」と結論づけてしまうかもしれません。技術的には確かに見事ですが、自らランサムウェアインシデントを引き起こすのは望ましい結果とは言えません。

望ましいレベルの安全性と制御を実現するため、最終的には今回の評価用に社内で構築したカスタムスキルのみを使用しました。

チームにはすでに、こうした評価を実施するための手順が文書化されていたため、(いくつかのエージェントの助けを借りて) その手順をスキルへと変換する作業は非常に迅速に進みました。これは、一般に公開されている (そして概して低品質な) 外部スキルを探して監査するよりも、はるかに容易なアプローチでした。

このアプローチにより、軽量な人間介在型 (human-in-the-loop) の承認メカニズムを組み込むことも可能となり、実験における自律性と制御の適切なバランスを実現できました。以下に抜粋 (図 1～3) を示します。また、主なシステムプロンプトと関連するスキル、および調査結果も GitHub で公開しています。

図 1:  OpenClaw レッドチームエージェントのガードレール

図 2: Active Directory 偵察スキルの対象範囲 

図 3: Active Directory 偵察スキルの安全境界 

主な検証結果 

全体として、実験は期待を上回る成果をもたらしました。

1. エージェントはテスト期間中、設定された境界を遵守しました。目標達成の過程で意図しない結果を招くような問題は発生しませんでした。
2. チームはプロセス全体を通じて、大幅な効率化を実現できました。例えば、Active Directory の偵察フェーズを 3 日間から 3 時間に短縮することができました。
3. 23 件の高品質かつ実用的な知見が得られました (詳細は付録に記載)。
4. 手動では達成不可能なレベルの詳細な監査証跡が生成され、レポート作成が劇的に簡素化されました。
5. エージェントは創造性と自律性を発揮しました。例えば、有望な攻撃経路がブロックされたエージェントは、取得したハッシュを解読するために EC2 の GPU インスタンスを立ち上げることを提案し、その提案が承認されると実行に移しました。
6. 使用したモデルは、悪用への懸念から協力を拒否することが頻繁にありました。チームの工夫により、そうしたガードレールの大半を回避することができましたが、プロセスに摩擦が生じる要因となりました。
7. ペネトレーションテスターは、リスクを伴う可能性のある新しいツールを活用する上で、独自の強みを持っています。ペネトレーションテストでは、潜在的に危険なオープンソースツールや初期段階のエクスプロイト実証コード (PoC) が頻繁に使用されるため、リスクの高いソフトウェアサプライチェーン環境が生じます。そのため、チームはすでに、機密性の高い環境において信頼性の低いツールを実行するためのフレームワークを構築していました。この基盤インフラストラクチャに関する詳細は、付録に記載されています。

まとめ

成功を収めたこの実験により、サイバーセキュリティチームが今後直面せざるを得ない複雑なトレードオフが明らかになりました。確かに危険なツールではありますが、導入しないことの方がさらに危険である可能性があります。否応なく世界は前進しており、エージェント型 AI を保護することは、サイバーセキュリティコミュニティにとって時代を象徴する課題となりつつあります。

また、サイバーセキュリティチームこそが、誰よりも早くこのテクノロジーを導入するのに適していることも示されました。第一に、あらゆる段階でセキュリティを考慮するオペレーター以上に、強力で危険なツールを適切に扱える存在がいるでしょうか？第二に、サイバーセキュリティの専門家がこの分野で経験を積めば積むほど、今後の動向や適切な管理ポイント、そして前回の記事で述べたように、実用的なリスク管理のあり方を予測できる可能性が高まるからです。