2026年2月初旬、GitGuardianは個人用AIアシスタントを運用するすべての開発者を警戒させるべきレポートを公開した。彼らのシークレットスキャンインフラが、OpenClawのデプロイメントに直接紐づく200件以上の漏洩認証情報を検出したのだ——APIキー、データベースパスワード、OAuthトークン、クラウドプロバイダーの認証情報が、公開リポジトリ、ログファイル、エラーレポートに散在していた。一部はヘルスケア企業のものだった。フィンテックスタートアップのものもあった。すべてが有効な状態だった。
数日後、Northeastern Universityがどんなcve番号よりも鋭い見出しの記事を公開した：「なぜOpenClaw AIアシスタントは『プライバシーの悪夢』なのか」。研究者たちは単一の脆弱性に焦点を当てたのではない。アーキテクチャそのもの——OpenClawがデータを扱い、認証情報を保存し、偶然ではなく設計によってユーザー情報を露出させる方法に焦点を当てたのだ。
これらは不注意なユーザーによる孤立したインシデントではなかった。シークレット、ユーザーデータ、エージェントコードがすべて同じアドレス空間を共有し、それらの間に隔離がない環境でAIエージェントを実行した場合の、予測可能な結果だった。
シークレットが間違った場所に行き着く仕組み
典型的なOpenClawのセットアップはこうだ：マシンにインストールし、環境変数にAPIキーを設定し、チャットを開始する。エージェントプロセスはあなたのユーザーとして、あなたの権限で実行され、あなたの環境変数を読み取る。インストールしたすべてのスキルが同じプロセス内で、同じアクセス権で実行される。
つまり、AIアシスタントにデプロイスクリプトのデバッグを依頼すると、エージェントはあなたのAWS認証情報を見ることができる。スキルがメールを処理する際、データベースパスワードを読み取れる。エラーが発生してスタックトレースがログに記録されると、それらの環境変数がログファイルに含まれる可能性がある。そしてそのログファイルがリポジトリにコミットされたり、バグレポートにアップロードされたり、クラウドサービスに同期されたりすると——あなたのシークレットは公開される。
GitGuardianの200件以上の漏洩シークレットは、200の別々のミスの結果ではなかった。一つのアーキテクチャ上のミスが200回繰り返された結果だ：プロセス内のすべてのコードが読み取れるprocess.envにシークレットを置くということ。
問題はスキルやプラグインで増幅される。OpenClawのスキルシステムは、コアエージェントと同じプロセス内でサードパーティコードを実行する。悪意のあるスキルが認証情報を盗むのにエクスプロイトは不要だ——process.envを読むだけでいい。出来の悪いスキルが意図的にデータを漏洩させる必要もない——エラーレポートに環境コンテキストを含めるだけでいい。攻撃対象はパッチすべき脆弱性ではない。アーキテクチャそのものだ。
Northeasternが正しく指摘したこと
Northeastern の研究者たちは、セキュリティコミュニティが遠回しに言っていたことを特定した：AIアシスタントのプライバシー問題は暗号化や認証の問題ではない。エージェントが何にアクセスでき、エージェントの世界とあなたの世界の間にどんな境界が存在するかという根本的な問題だ。
AIエージェントがあなたのユーザーとして、あなたの権限で、あなたのマシン上で実行される場合、境界は存在しない。エージェントはあなたのファイル、認証情報、ブラウジング履歴、SSHキーを読み取れる。あなたがアクセスできるものすべてにアクセスできる。有害な行動を防ぐ唯一のものはプロンプトだ——そしてプロンプトインジェクション攻撃は、プロンプトがセキュリティ境界ではないことを繰り返し実証してきた。
これがNortheasternの言う「プライバシーの悪夢」の意味だ。OpenClawが意図的にデータを盗んでいるのではなく、アーキテクチャがデータ漏洩を防ぐことを不可能にしているということだ。エージェントのアクセスはOSのユーザー権限によってのみ制限されていた。つまり、実質的にはまったく制限されていなかった。
NanoClawのコンテナ隔離がゲームを変える
NanoClawは根本的に異なるアプローチを取る。すべてのエージェントは独自のLinuxコンテナ内で実行される——macOSではApple Container、macOSとLinuxではDocker。コンテナは便利機能やデプロイオプションではない。セキュリティモデルそのものだ。
NanoClawにメッセージを送ると、ホストプロセスはClaudeを直接実行しない。コンテナを起動し、そのエージェントがアクセスする必要のある特定のディレクトリのみをマウントし、会話コンテキストを渡す。エージェントはコンテナ内で独自のファイルシステム、独自のプロセス空間、独自のネットワークスタックを持って実行される。完了するとコンテナは破棄される。
シークレットの扱いが興味深い。NanoClawはANTHROPIC_API_KEYをprocess.envにロードしない。代わりに、実行時に.envからキーを読み取り、JSONペイロードとしてstdin経由でコンテナプロセスに渡す。コンテナ内では、agent-runnerがキーを受け取り、API呼び出しに使用し、ディスクに書き込んだり環境変数にエクスポートしたりすることはない。
つまり、悪意のあるプロンプトがエージェントを騙して`printenv`や`cat /proc/self/environ`を実行させたとしても、APIキーはそこにない。キーはagent-runnerプロセスのメモリ内にのみ、その単一の会話ターンの間だけ存在する。侵害されたコンテナは、アクセスできないものを漏洩させることはできない。
マウントシステムがさらなる防御層を追加する。NanoClawはコンテナにマウントできるディレクトリの許可リストを、プロジェクトルートの外に保持している。各グループは独自の隔離されたファイルシステム——独自のCLAUDE.mdメモリファイル、独自の書き込み可能なワークスペースを持つ。許可リストにはシンボリックリンクエスケープ検出が含まれており、細工されたシンボリックリンクが許可されたセット外のディレクトリを露出させるようマウントシステムを騙すことはできない。
コンテナは非rootユーザーとして実行され、プロジェクトソースは読み取り専用でマウントされる。エージェントはコンテキストを理解するためにコードベースを読めるが、ホストのファイルを変更することはできない。書き込み可能なパスはグループごとにスコープされ、コンテナ終了時にクリーンアップされる。
グループごとの隔離モデル
NanoClawの隔離は、エージェントとホストの分離にとどまらない。各WhatsAppグループが独自のコンテナ、独自のメモリ、独自のファイルシステムを持つ。グループAはグループBの会話、ファイル、CLAUDE.mdメモリを見ることができない——アプリケーションレベルのアクセス制御によってではなく、別々のマウントポイントを持つ物理的に分離されたコンテナで実行されるからだ。
これは、ほとんどのAIアシスタントが完全に無視しているシナリオ——共有デバイスとマルチユーザーセットアップ——で重要になる。家族でNanoClawを使う場合、仕事グループの会話やファイルは家族グループの会話やファイルからコンテナレベルで隔離される。グループ間でデータを漏洩させるアプリケーションバグは存在しない。隔離はアプリケーションではなくコンテナランタイムによって強制されるからだ。
メインのWhatsAppチャンネル——アシスタントとのダイレクトメッセージ——が管理インターフェースとして機能する。スケジュールタスクの管理、設定の変更、グループ横断的な状態へのアクセスができる唯一のチャンネルだ。グループチャンネルはデフォルトで自身のサンドボックスに制限される。
業界が学ぶべきこと
GitGuardianのレポートとNortheasternの分析は同じ結論を指し示している：AIエージェントはインフラであり、インフラにはインフラグレードのセキュリティが必要だ。認証情報と同じプロセス内で、ユーザーアカウントと同じ権限でAIエージェントを実行することは、ファイアウォールなしでrootとしてWebサーバーを実行するのと同等だ。動くうちは動く。動かなくなったとき、被害範囲はすべてだ。
コンテナ隔離は新しいアイデアではない。Webホスティング業界は20年前にこれを理解した——複数の顧客のコードを同じプロセスで実行しない。データベース業界はさらに早く理解した——すべてのクエリにすべてのテーブルへのアクセスを与えない。しかしAIエージェントのエコシステムはまだ「すべてをrootで実行する」段階にあり、漏洩したシークレットとプライバシーの悪夢はその予測可能な結果だ。
NanoClawのアプローチがこの問題を解決する唯一の方法ではないが、機能を犠牲にすることなく問題が解決可能であることを示している。コンテナ内で実行されるエージェントは、依然としてWeb検索、ページ閲覧、ファイルの読み書き、シェルコマンドの実行が可能だ。ただし、バグ、プロンプトインジェクション、悪意のあるスキルなど、あらゆる障害の被害範囲がその単一コンテナのスコープに限定されるサンドボックス内で行う。
GitGuardianが発見した200件の漏洩シークレットは、起きる必要のないものだった。アーキテクチャがそれを不可避にしたから起きたのだ。修正策はユーザー教育の改善や認証情報管理の慎重化ではない。修正策は、シークレットが漏洩可能な場所に決して置かれないアーキテクチャだ。