Microsoft：通常の業務用マシンでOpenClawを実行しないでください

2026年2月19日、Microsoft Defender Security Research Teamは「Running OpenClaw safely: identity, isolation, and runtime risk」と題する投稿を公開し、その中で、Orca AI Incident Archiveが他のどの項目にも記録していない勧告を行った。OpenClawは「永続的な認証情報を伴う信頼できないコード実行として扱うべき」であり、「標準的な個人用または企業用ワークステーションで実行するのは適切ではない」というものだ。OpenClawはセルフホスト型のエージェントランタイムであり、ユーザーが自分のマシンにインストールし、アカウントとトークンを与え、公開レジストリからスキルをインストールさせ、どこから読んだテキストに対しても動作させる。Microsoftの主張はバグ報告ではなくアーキテクチャ上のものである。ランタイムは実行点を静的アプリケーションコードから実行時に供給されるコンテンツへ移すが、アイデンティティ、入力処理、特権に関する制御はそれに合わせて移っていない。この投稿はCVEもキャンペーンも被害者も挙げておらず、侵害も記録していない。完全な記録はOrca AI Incident Archiveにあり、信頼度グレードAの画期的なポリシー項目として分類され、実際の被害は記録されていない。

その投稿が語ったこと、そして語らなかったこと

この投稿は読了時間が約12分で、開示の仕組みを一切備えていない。CVE識別子も、影響を受けるバージョン範囲も、修正済みビルドも、実際の展開に関連付けられた侵害指標もない。Microsoft Defender Security Research は Idan Hen を寄稿者として挙げている。代わりに備えているのは脅威モデルと展開ルールであり、そのためアーカイブはこれをインシデントではなくポリシー記録として分類している — 重大度情報、信頼度グレードA、実際の被害の記録なし、日精度の単一日付。

推論は冒頭の1段落に圧縮されている。OpenClawは「限定的な組み込みのセキュリティ制御しか備えていない」とチームは書いている。なぜなら、そのランタイムは「信頼できないテキストを取り込み、外部ソースからスキル（すなわちコード）をダウンロードして実行し、割り当てられた認証情報を使って操作を実行できる」からだ。その結果は同じ文で述べられている。これにより「実行境界が静的なアプリケーションコードから、動的に供給されるコンテンツやサードパーティの機能へと実質的に移るが、アイデンティティ、入力処理、特権スコープに関する同等の制御は伴わない」。

続いて3つのリスクを示す。これらはマイクロソフト自身の言葉で読む価値がある。なぜなら、その後に続いた報道の多くが、それらを曖昧な表現に言い換えてしまったからだ：

•「認証情報やアクセス可能なデータが露出または窃取される可能性があります。」

• 「エージェントの永続状態、つまり『メモリ』は改変される可能性があり、その結果、時間の経過とともに攻撃者が提供する指示に従うようになる。」

• 「エージェントが悪意のあるコードを取得・実行するよう誘導されると、ホスト環境が侵害される可能性がある。」

そのリストに欠けているものに注目してほしい。悪用された欠陥も、脆弱な関数も、出荷すべきパッチもない。MicrosoftはOpenClawにセキュリティ上のバグがあると言っているのではない。実行時に、取得したテキストから、与えられた認証情報を使って何をするかを決めるプログラムは、運用者の実際の業務も置かれているマシン上では、設定によって安全にすることはできない、と言っているのだ。それに伴う推奨事項も、それ相応に率直だ。ほとんどの環境では、「適切な判断は、導入しないことかもしれない」のだ。

2つのサプライチェーン、1つの実行ループ

投稿が説明している仕組みは、セルフホスト型エージェントのいわゆる2つのサプライチェーン、すなわちスキルや拡張機能といった信頼できないコードと、外部テキストといった信頼できない指示の収束である。ほとんどのソフトウェアはどちらか一方しか持たない。パッケージマネージャーは信頼できないコードを取得するが、インターネットを読んで次に何を実行するかを決めることはない。チャットモデルは信頼できないテキストを読むが、何かをインストールすることはできない。OpenClawはこの両方を単一のループで行い、そのループはユーザー自身のアイデンティティの下で動作する。

「スキルのインストールは、基本的に特権コードのインストールだ」と投稿は述べている。スキルは「OpenClawの公開スキルレジストリであるClawHubを通じて発見・インストールされることが多く」、寛容なデプロイでは「ランタイムが人間の承認なしにインストールフローを実行できる場合がある」。2つ目のサプライチェーンはMoltbookによって扱われており、投稿はこれを、エージェントがAPIを通じて投稿・読み取り・認証を行うエージェント中心のプラットフォーム兼アイデンティティレイヤーと説明している。したがって、その表現を借りれば「エージェントが定期的に取り込む、攻撃者の影響を受けうる大量のコンテンツの流れ」である。要点は圧縮にある。「したがって、1つの悪意ある投稿が複数のエージェントに到達しうる」。

その後、この文書は信頼境界を3つの構成要素に分割します。これは文書全体の中で最も再利用可能な部分です。すなわちアイデンティティとは、エージェントがSaaS API、リポジトリ、メール、クラウド制御プレーンをまたいで作業するために使うトークンです。実行とは、ファイル、シェル、インフラストラクチャ、メッセージを含め、状態を変更するためにエージェントが実行できるツールです。永続性とは、タスク、設定、スケジュールを通じて、実行間で変更を保持できる方法です。この3つすべてを備えたエージェントは、許可プロンプト付きのアプリケーションではありません。それはプリンシパルです。

毒されたスキル、5つの段階

Microsoftは、事例報告ではなく代表的なシナリオと位置づけた、具体的な侵害チェーンを1つ示している。これを順に追う価値があるのは、最後の2段階が通常のエンドポイント防御を破る部分だからだ。投稿はその前に、外部世界に関する主張を置いている。「公開報告では、悪意あるスキルが公開レジストリに現れていることが記録されており」、場合によっては「レジストリの内容は、巧妙な似せ物ではなく、スキルとしてパッケージされた紛れもないマルウェアだった」という。しかし、レジストリの項目、キャンペーン、行為者、被害者のいずれも名指ししていない。したがってこのチェーンは再構成ではなく、もっともらしさを示す論拠として成立している。

• 配布。攻撃者は悪意のあるスキルをClawHubに公開し、ユーティリティを装うこともあれば、あからさまに悪意のあるものとして公開することもあり、コミュニティチャネルを通じて宣伝する。また、検索で自然に見つかり、インストールの敷居が低いためにインストールされることもある。

• インストール。 スキルがタスクに関連しているように見えるため、開発者またはエージェント自身がインストールを開始します。寛容なデプロイ環境では、人間による承認は行われません。

• 状態へのアクセス。 攻撃者は、トークン、キャッシュされた認証情報、設定データ、トランスクリプトに加え、今後の実行を左右する永続的な指示チャネル——タスクファイル、スケジュールされたアクション、エージェント設定——を狙います。

• 権限の再利用。有効なID情報を入手した攻撃者は、標準的なAPIやツールを通じて活動するため、その活動は「強力な監視およびログ記録の制御が導入されていない限り、正当な自動化処理としばしば見分けがつかない」。

• 設定による永続化。 残るのは持続的な設定変更です。「新たなOAuth同意、スケジュールされた実行、変更されたエージェントタスク、あるいは恒久的に承認されたままのツール」などです。

第5のステップには、この投稿で最も鋭い一文があり、これがマルウェアの問題ではなくポリシーの問題である理由を最もよく説明している。「目的はマルウェアを配備することよりも、自動化の経路を長期的に制御し続けることにある」。ペイロードを探すセキュリティツールは何も見つけられない。捕まえる必要があるのは、同意の付与、cronエントリ、あるいは静かに承認されたまま放置されたツールだ。

マイクロソフトが受け入れる最低限の態勢

Microsoftは読者に「するな」だけを残すことはない。それでもランタイムを評価すると決めた組織のために最低基準を示しており、その基準はサンドボックスより厳しい。環境は「日常業務に使用しない専用の仮想マシンまたは別の物理デバイス」であるべきで、使い捨てとして扱うべきだ。認証情報はエージェントの目的のためだけに作成し、非特権とし、すでに侵害されている前提でローテーションすべきだ。到達可能なのは機密性のないデータのみであるべきだ。エージェントの保存された指示と状態は、予期しない永続的なルール、新たに信頼されたソース、実行間で変化する動作がないか定期的にレビューすべきだ。また、再構築は緊急時の対応ではなく想定された制御であるべきだ。定期的に再インストールし、異常な動作があれば直ちに再構築する。

投稿の中のある詳細は、その長さが示唆する以上に有用です。バックアップする.openclaw/workspace/と、エージェントの作業状態を認証情報を含めずに捕捉できます。一方、.openclaw/ディレクトリ全体をバックアップすると、復元はより簡単ですが、トークンや認証情報も捕捉してしまい、認証情報が侵害された疑いがある場合には不適切かもしれないと投稿は警告しています。ディレクトリ全体をバックアップしてそれを災害復旧と呼ぶチームは、攻撃者が欲しがっていたものをアーカイブしてしまったのです。

ガイダンスは製品マップでもあります

記事の後半では、各推奨制御をMicrosoft製品に対応付けている。エージェントIDに対する最小特権と条件付きアクセスにはMicrosoft Entra ID、OAuthインベントリと同意ドリフトにはMicrosoft Defender for Cloud AppsのApp Governance、エージェントホストにはMicrosoft Defender for Endpoint、相関にはMicrosoft Defender XDR、エンドポイントのデータ損失防止にはMicrosoft Purview、ネットワーク出口にはMicrosoft Defender for Cloud、より長い保持期間や自動化が必要な場合にはMicrosoft Sentinelだ。これはベンダーのセキュリティブログではよくある慣行であり、はっきり指摘する価値もある。サードパーティのエージェントランタイムを封じ込めることを推奨する文書を公開しているのは、その封じ込めを販売する企業なのだ。

ハンティングに関する内容は、その枠組みの中でも生き残る部分です。具体的だからです。この投稿では、Defender XDR のテーブル — DeviceProcessEvents、CloudProcessEvents、DeviceFileEvents、DeviceNetworkEvents、OAuthAppInfo — に対する KQL クエリを提供しており、それらは "openclaw"、"moltbot"、"clawdbot" を含むプロセスのコマンドラインやファイル名、clawhub install の呼び出しで珍しいスキルスラッグを伴うもの、開発者エンドポイントでの拡張機能フォルダーの頻繁な変更、新規の高権限 OAuth アプリケーション、エージェントプロセスが開いた待ち受けサービス、エージェントランタイムが cmd.exe、powershell.exe、pwsh.exe、bash、sh、curl、wget を起動することを探します。製品マッピングをどう考えるにせよ、これらのクエリは公開当日にどの Defender XDR 顧客でも実行でき、どのホストでランタイムが動いているかについて事前知識を前提としていません。

何が確立されており、何が確立されていないのか

確認済みで、裏付けもある。マイクロソフトは2026年2月19日にこの投稿を公開しており、上記の引用はそこからのものです。Cybernewsは2026年2月23日に、TechRadarは2026年2月24日にこの警告を報じましたが、両者とも中心となる2文と分離ガイダンスを検証するのではなく、繰り返し述べただけでした。繰り返し検索しても、The Register、BleepingComputer、Wired、TechCrunchでの報道は見つからなかったため、この投稿をめぐる報道の波は小さく、二次的なものでした。マイクロソフトのアーキテクチャに関する主張を検証した独立主体はなく、入手可能な裏付けはマイクロソフトが述べた内容を確認するものであって、それが正しいかどうかを確認するものではありません。

このリレーはまた、指摘する価値のある誤りも持ち込んだ。なぜなら、サードパーティ製ツールに関するベンダーの警告が、いかに早く自社製品に関するベンダーの警告に変わってしまうかを示しているからだ。Cybernewsの記事は、OpenClawを「MicrosoftのAIアシスタント」と表現して始まっているが、そうではない。OpenClawはMicrosoftのDefender研究者が調査したセルフホスト型ランタイムであり、投稿自体が構造的に区別を示している。セルフホスト型ランタイム——そこでは「影響範囲（ブラスト半径）の責任はあなたにある」とされ、ホスト、プラグイン、ローカル状態がすべて信頼境界の内側に位置する——と、マネージドアシスタントおよびエージェントプラットフォーム——ランタイムと更新が集中管理され、制御はIDスコープ、コネクタガバナンス、データ境界に集中する——を対比している。

立証されていない：投稿に記述されている方法で特定の組織が侵害されたということ。Microsoftは、公開報告が公開レジストリにおける悪意のあるスキルを記録してきたと主張しているが、その投稿にはキャンペーン名、件数、日付、被害者のいずれも添えられておらず、したがってこの記録に実害はない。また、この推奨には拘束力もない。規制当局がそれを発したわけでも、標準団体がそれを採択したわけでもなく、この記録には、顧客、監査人、保険会社がそれを要件として扱ったことを示すものは何もない。これは、自社が管理していないツールを自社顧客がどう扱うべきかについてのベンダーの意見であり、異例なほど断定的で、執行力もない。

この投稿が変えるのは、セキュリティチームが答えなければならない問いの形だ。2026年2月19日より前は、業務用ラップトップでOpenClawを実行するかどうかの判断は、設定とパイロット承認の問題として論じることができた。それ以降は、ランタイムの設定ではなくランタイム自体の設計がマシンを危険にさらすと明言する文書に対して、論を立てなければならない。しかもその文書は、アップグレード先のバージョンも、適用すべきパッチも、ロードマップ上の修正も示していない。その解決策はデプロイパターンだ。ランタイムを隔離し、到達できる範囲を制限し、継続的に監視し、遅滞なく再構築できるよう備える。