NanoClawのMCP承認カードが実行パラメータを非表示にし、エージェントが一度の同意を永続的な実行設定に転換可能

NanoClawはコンテナでエージェントを隔離し、エージェントが要求する`add_mcp_server`による自己変更を管理者が承認する仕組みを採用している。しかし、新たに公開されたCVE-2026-17434により、この人的ゲートが実際に実行される設定と結び付いていなかったことが明らかになった。旧バージョンの承認カードにはMCPサーバーの名前とコマンドしか表示されず、エージェントが送信した`args`と`env`は表示されないにもかかわらず、ホストによってデータベースに保存され、その後エージェントの`container.json`に書き込まれていた。

そのため、プロンプトインジェクションを受けた、または制御を奪われたエージェントは、無害に見える`node`サーバーを提案しつつ、非表示の引数で`-e`プログラムを追加したり、`NODE_OPTIONS`を使ってローカルファイルをプリロードしたりできた。この攻撃には依然として管理者が承認ボタンを押す必要があり、ユーザー操作を伴わないリモートコード実行ではない。しかし、承認者が同意した画面と実際に適用される内容が異なるため、人的確認は信頼できるセキュリティ境界として機能せず、さらに一度の同意で永続的な実行設定を残すことが可能だった。

アップストリームの修正では、カードに名前、コマンド、引数、環境変数を項目ごとに表示するようにし、改行、双方向テキスト、ゼロ幅文字を可視のエスケープシーケンスへ変換した。また、機密情報とみられる値については、長さとSHA-256フィンガープリントのみを表示する。さらに、引数は最大32個、環境変数は最大32個、ペイロードは16 KB、カード内容は1,500 bytesに制限し、コミュニケーションプラットフォームによって末尾のフィールドが切り捨てられることを防止した。カードの送信に失敗した場合は、承認待ちレコードを削除する。

エンジニアリングチームはアップグレードに加え、既存のMCP設定に含まれるコマンドラインと環境変数を監査し、「人が確認したペイロードのハッシュが、実際に実行されるペイロードのハッシュと一致する」ことをエージェントの承認フローに組み込むべきだ。CVEデータベースではこの問題を中程度のリスクに分類しているが、プロジェクトのIssueでは、より高い自己評価スコアが採用されている。公開情報からは実際の攻撃がすでに発生したことは確認されておらず、影響を受けるバージョンの対応関係についても、今後のベンダーのセキュリティアドバイザリを基準とすべきである。