Show HN: Continue? Y/N: AIエージェントの権限疲れに関する60秒ゲーム

 (llmgame.scalex.dev)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Continue? Y/Nは、LLMの権限疲れを60秒ゲームにした実験で、AIの指示をどれだけ注意深く読むかを試すもの
  • 次の会議まで1分しか残っていない状況で、Claude Codeがリファクタリングの仕上げのためにコマンド承認を求めてくる
  • ユーザーは制限時間内にできるだけ多く処理しなければならず、各コマンドを読んで1で承認するか2で拒否する
  • 繰り返される承認リクエストで目がかすむほど疲れる流れの中でも、集中し続けられるかが核心的な課題
  • ルールは、60秒以内にできるだけ多く処理しつつ、各コマンドを慎重に読んで承認するかどうかを判断すること

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの意見

  • 本当に面白い

    今は、すべてのリクエストをできるだけ早く拒否することで「チート」が可能です。そうすると security-conscious engineer バッジ を獲得でき、処理したリクエスト数ベースでも満点になります。"overblock" の警告は出ますが下の方に隠れていて、画面上は相変わらず勝ったように見えます

    それから、hustle4lyfe 的な「速く動いて壊す」エンジニアのように、できるだけ多くのリクエストを素早く承認してみましたが、malicious command ポップアップ のせいでむしろ遅くなりました。ずるい

    • よく見つけましたね。今はこのやり方はナーフされ、別の称号も付きました
    • 現実とまったく同じ。何もできないように全部拒否すれば安全です :)

  • 面白いゲームですが、作った側の セキュリティ衛生 の不足も見えました。cat ~/.zshrc がトークンやシークレットを共有するので危険だとしていましたが、私はシェル設定ファイルにシークレットを絶対に入れません

    • 多くの人はそうしています。ただ、そういう値は環境変数にあるはずで、たぶんすでにClaudeがアクセスできるのでしょう
    • 私自身はそうしませんが、多くの人がそうする可能性はあると思います
    • シークレットをLLMに入れること自体が本質的に安全でないわけではなく、致命的な3要素 の1つにすぎません
    • そもそも「トークンやシークレット」を持っていること自体がセキュリティ衛生の不足です
    • じゃあどこに置くんですか？

  • zshrc を読むことを危険とみなすのはおかしいです。私は自分の公開 dotfiles リポジトリ に喜んで置いていますし、いったい誰がそこにAPIキーを入れるのでしょう？ 逆に、こうしたAIツールは PATH をそこに追記し続けているようなので、AI業界全体にシェルのベストプラクティスに対する根本的な誤解があるように思えます

    さらに、lsof の結果を kill するのは安全ではありません。たとえばFirefoxでウェブページを開いていたり、エージェント自体の中にクライアントのサブシェルがあったりすると、Firefoxとエージェントがそのまま吹き飛びます

    • その通り。ゲームはClaudeが安全だと言ったのだから kill の実行も安全だと決め打ちしているようです。ですが要点は、Claudeを信用してはいけない ということです

  • 良かったです。ただ、小さな nitpick があります

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    オンボーディング文書で要求されているので、npmを社内レジストリミラーへ向けるコマンドだとして、ゲームはこれを安全だと判断しました。私も半々で悩みましたが、結局拒否しました

    このREADMEが公開リポジトリやforkされたリポジトリ向けで、この https://npm.internal が実際には https://npm.internal.somethinganexternaldnscanresolve.tld だったら、かなり早く破綻しえます

    99%のケースでは、会社の方針で Artifactory / Nexus のようなミラーがすでに設定されているはずです。READMEが別のパッケージマネージャーURLを使えと言ってくるなら大きな危険信号で、事故まで秒読みです

    • 良い指摘です。.internal は予約済みTLDなので公開的に解決されるべきではありませんが、Claudeにプロジェクトをリファクタリングさせている間に、別途設定すべき値を変更することには注意が必要だという点はその通りです。これは 永続的変更 側に移します

  • 面白い小さなゲームですが、質問が文脈をかなり飛ばしすぎていて、実際の状況をあまりうまく表していないと思います。「パック」のようにまとめて、もっと現実的な構造にした方がよさそうです

    たとえば something.js ファイルを編集する権限要求がたくさん出た後で npm publish が来る方が、ずっと自然でより危険です。ずっと Y を押している最中に突然出てくると、もっと引っかかりやすいです

  • 「悪い」選択肢の4分の3くらいは、漏れてもあまり気にしないようなものですし、仮に 本番事故 につながっても雇用主が処罰しないであろうものです

  • 権限確認は生産性を大きく殺します。Claudeを動かすなら、使い捨てサンドボックス で実行するか、個人マシン上で許容できる権限だけを与えたDockerコンテナのような形で動かす方が、より効率的だと思います

    [1] - https://exe.dev/ は、かなり有用なエージェントのユーザー体験を提供する新しいクラウドプロバイダです

    [2] - この用途のために https://github.com/stanislavkozlovski/dclaude/ を作りました。完璧ではありませんが、たまにコーディングエージェントをローカルで動かす必要があるときには、私の仕事をこなしてくれます

    • 使い捨てサンドボックスでは シークレット漏えい は防げません。コードを秘密と見なさないなら、シークレットがまったくないサンドボックスは作れますが、そうするとエージェントでできる作業の種類は大幅に制限されます

  • 最後のスコア画面で、承認してはいけなかったコマンドについて LLMの説明 も見せてほしいです。rm -rf Projects コマンドを承認してしまったのは、LLMがProjectsフォルダ内のすべてを削除すると正しく説明していたと思ったからです

    プロンプトに素早く答えようとして、私が明らかに読み間違えたのでしょうし、コマンドが何をするかは分かっていたので、AIが説明したと自分で幻覚してしまったのかもしれません。それでも、自分が何を読み違えたのか見てみたいです

    このゲームをやってみて、自分がagentmaxxしていなくて本当に良かったと感じました

  • ls -la ~/Documents で「approve」を選んだら不正解でしたが、単にDocumentsフォルダを一覧表示するだけでセキュリティ上の問題だとは思いません。所詮 ファイル名 だけです。ファイル内容まで読むなら、そのときは maybe...