AIエージェントを社内の基盤として動かし始めると、便利さと同じ速さでリスクも積み上がります。ファイルへのアクセス、外部プラグインの読み込み、APIキーやトークンといった認証情報の取り扱いは、いずれも一歩間違えれば情報漏えいや意図しない操作につながります。2026年8月31日に公開されたOpenClaw 2.0（バージョン番号としてはv2026.8.1）は、まさにこの課題に正面から向き合ったリリースです。本記事では、AIエージェント基盤を自社で運用・構築する開発リーダーやセキュリティ担当者の視点から、今回のセキュリティ基盤刷新の設計思想を読み解きます。

なぜOpenClaw 2.0は7週間も開発を止めたのか

OpenClaw 2.0は、通称こそ2.0ですが、バージョン番号はカレンダー方式のv2026.8.1です。特筆すべきはその規模で、933人のコントリビューター（うち569人が初参加）と16,000件を超えるマージ済みプルリクエストで構成される、同プロジェクト史上最大のリリースとなりました。

これまでのOpenClawは、230日間で106回という非常に高い頻度でリリースを重ねてきました。しかし今回はそのサイクルをあえて約7週間止め、より強固な技術基盤と安全なアップグレード経路づくりに集中しています。機能を足し続けるのではなく、いったん手を止めて土台を組み直すという判断は、エージェント基盤が実運用フェーズへ移ったことを象徴しています。速さを競う段階から、安心して任せられる段階への転換点だと捉えると理解しやすいでしょう。

今回のセキュリティ刷新は、大きく分けて3つの防御層で語れます。エージェントの行動範囲を縛るセッション権限モード、外部コードの供給元を可視化するプラグイン信頼レビュー、そして秘密情報を値ごと隔離する認証情報レイヤーです。順番に見ていきます。

セッション権限モードがエージェントの行動範囲を閉じる

第一の防御層が、セッション権限モードです。OpenClaw 2.0では、すべてのセッションが明示的な権限モードのもとで動作するようになりました。従来のように、エージェントが暗黙のうちに広い権限で走り出すのではなく、どのモードで動いているのかが常にはっきりしている状態です。

とりわけ重要なのがファイルシステムへのアクセス制御です。エージェントが読み書きできる範囲は、あらかじめ記録されたワークスペースやworktreeに固定されます。これにより、エージェントがディスク全体を無制限に探索し、想定外のディレクトリから機密ファイルを読み取ってしまう事故を構造的に防げます。アクセスできる場所を最初から限定しておくという、境界を先に引く発想です。

さらにチーム運用者向けのロールも整理され、エージェントやセッション、管理操作それぞれのアクセス範囲を分けて制限できるようになりました。誰が何をどこまで実行できるのかを設計として表現できるため、複数人でエージェント基盤を運用する組織ほど恩恵が大きい変更だと言えます。

プラグイン信頼レビューで供給元リスクを可視化する

第二の防御層は、プラグイン信頼レビューです。エージェントの機能を拡張する外部プラグインは便利な反面、供給元が不透明なコードをそのまま実行する危険と隣り合わせでした。OpenClaw 2.0では、外部プラグインをインストールしたり有効化したりする前に、そのプラグインの機能、提供元、バージョン、成果物といった情報が提示されます。何を取り込もうとしているのかを、実行前に人間が確認できる仕組みです。

加えて、ClawHubのセキュリティ監査情報もインストールの流れに組み込まれました。任意の実行可能ファイルを供給元とするインストールには明示的なforceフラグが必要となり、うっかり素性の知れないバイナリを取り込む事態を避けやすくなっています。

設計として興味深いのは、更新を拒否したときの挙動です。プラグインの更新を承認しなければ、旧バージョンがそのまま動き続けます。新しい版を強制的に押し付けるのではなく、運用者が納得して承認するまで既存の状態を保つという姿勢は、供給元の変化を運用者側がコントロールできるようにする配慮だと読み取れます。

認証情報レイヤーがシークレットを値ごと隔離する

第三の防御層が、認証情報レイヤーです。AIエージェントにとって最もセンシティブなのは、APIキーやアクセストークンといったシークレットの扱いです。OpenClaw 2.0では、シークレットを書き込み専用の値として、チーム単位のスコープを持つ共有クレデンシャルストアに保存する方式へ変わりました。

この設計の要点は、値そのものをモデルや会話から遠ざけることにあります。エージェントはマスクされたプロンプト経由でクレデンシャルを要求でき、シークレットの実際の値はチャットの履歴にもモデルのコンテキストにも入りません。透けて見えない状態のまま処理が進むため、トランスクリプトを経由した漏えい経路を根本から断てます。

ネットワーク面でも制御が入りました。保護されたシークレットの送信先は、宣言済みのホストに限定されます。承認していない宛先へ秘密情報が渡ることを防ぐ、いわば出口の管理です。さらに1Passwordのブローカー連携を使えば、シークレット単位での承認と、値を含まない監査証跡を追加できます。誰がいつどのシークレットを使ったのかを、値を露出させずに記録できる点は、監査を求められる組織にとって実務的な価値があります。

モデル許可リストと設定変更履歴が運用統制を底上げする

3つの防御層に加えて、運用の統制を支える機能も強化されました。ひとつがモデル許可リストです。運用者はエージェントごとに、呼び出せるモデルをプロバイダーのワイルドカード付きで制限できます。エイリアスの定義と許可ポリシーを分けて扱えるため、意図しないモデルへ処理が流れることを防ぎつつ、承認済みのモデルだけを使わせる運用が組み立てられます。

もうひとつが設定変更履歴です。設定への変更は、変更者を示すラベル付きで記録され、機密値はマスクされたうえで残ります。何がいつ誰の手で変わったのかを後から追えることは、インシデント対応や監査の場面で大きな助けになります。あわせて追加された新コマンドを使えば、外部からの到達性やツールの影響範囲、ネットワークやブラウザ操作の露出、プラグインの許可状況といった攻撃面をまとめて点検できます。守りの設定を、感覚ではなく確認可能な形で扱えるようになった点が重要です。

移行で押さえる破壊的変更3件と自社運用への示唆

これだけ大規模なリリースでありながら、破壊的変更は異例に少ない3件にとどまりました。ひとつめはOpenProseプラグインとproseコマンドの廃止、ふたつめはcodex系およびopenai-codex系のモデル参照をopenai系へ統合したこと、みっつめはプラグインSDKの旧サブパスインポートを2026年9月1日付で非推奨化したことです。3つめはプラグイン開発者にのみ影響します。

いずれの変更も、openclaw doctor --fixコマンドが自動で対応します。廃止に伴う古い設定は掃除しつつ既存のソースは保持し、モデル参照は新しい形式へ変換したうえで競合があれば知らせてくれます。移行の手間を最小化しながら安全に基盤を引き上げる導線が用意されているわけです。

自社でAIエージェント基盤を運用・構築する立場からみると、OpenClaw 2.0が示したのは、機能追加と同じ熱量でセキュリティ基盤へ投資するという方針そのものです。行動範囲を先に閉じ、外部コードの素性を可視化し、秘密情報を値ごと隔離するという3層の考え方は、どのエージェント基盤にも応用できる普遍的な設計原則です。自分たちの環境でも、エージェントがどこまで触れられるのか、どのプラグインを信頼するのか、シークレットをどこで隔離するのかを、あらためて設計として言語化する好機になるはずです。