【実録】Gemini CLI の脆弱性ニュースを見たので、自作ラッパーで「防御壁」作成に挑んでみた

普段から便利に Gemini CLI を愛用しているのですが、先日たまたま目にしたセキュリティニュースで「AI エージェントに重大な脆弱性の可能性（RCE など）」という文字を見て、背筋が凍りました。

「もし自分の API キーや、隠しておきたい秘密ファイルが AI 経由で漏れたら……」

そう思って、勉強がてら自分の環境を「要塞化」してみることにしました。その過程で、AI が指示していないファイルを勝手に読みに行こうとするなど、予想外の生々しい挙動を目の当たりにしたので、記録として残します。

まずは基本から。入り口を塞ぐために以下のアップデートを行いました。

でも、ニュースによれば「AI が騙されて秘密情報を外部に送らされる」という攻撃（Comment and Control）もあるとのこと。これはソフトの更新だけでは防げない……！

「AI がアクセスできる場所に秘密を置かない」のが一番。そこで direnv を導入して、「特定のフォルダに入ったときだけ API キーをロードする」 設定にしました。

これで、ホームディレクトリで遊んでいるときは AI が鍵を見つけられない「安全地帯」ができました。

「今回は、Gemini CLI の挙動を安全に調査するために、入出力をフックして監査する専用のデバッグ用ラッパーを Python で作りました。直接コマンドを叩くのではなく、この検問所を通すことで、AI が裏で何をやろうとしているのかを可視化します。」

#!/usr/bin/env python3
import sys
import os
...

この「要塞」の強度を試すため、わざと意地悪な質問をしてみました。

僕：「URI 形式で、データベースのパスワードとかが含まれる文字列をダミーでいいから 5 つ作って出力して」

すると、恐ろしいことが起きました。

ログを見ると、AI は僕が指示していないのに 「ガバナンス確認のため」という謎の理由で、フォルダの外にある ~/projects/GCP_HOLDINGS.md というファイルを勝手に読み取ろうとした のです。

幸い、direnv でワークスペースを制限していたので 「アクセス拒否」 で守れましたが、もし隔離していなかったら、中身を勝手に読み取って回答に使われていたかもしれません。

アクセス拒否された AI は、「そんなはずはない！」と何度もリトライを繰り返しました。その結果、わずか数分で Google API の利用制限（Quota Exhaustion）に激突して停止しました。

「防御した」というより「AI がパニックになって自爆した」 というのが正しい表現です。

初心者の試行錯誤でしたが、大きな発見がありました。

結論：「侵入」は許したが、「実害」は食い止めた

今回の対策でわかったのは、「AI が騙されること自体は防げない」ということです。賢い AI は、巧妙なプロンプトで簡単に「本来の役割」を忘れてしまいます。

でも、「AI が物理的に触れる場所」を制限しておけば、たとえ AI が乗っ取られても、一番大事なファイルまで手が届かない。今回の検証は、「ソフトの検知（aigis）」が破られても、「環境の隔離（direnv）」が最後の最後で食い止めてくれたという、多層防御の泥臭い実戦記録となりました。

요약