0. はじめに

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

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

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

1. ニュースを見て慌ててやったこと

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

Gemini CLIの更新: 脆弱性対策が入った最新版（v0.40.1以降）へ。
Linuxカーネルの更新: 特権昇格のバグ対策として最新（6.8.0-111-generic等）へ。

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

2. 秘密情報を「物理的」に隠す（direnvの導入）

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

~/.bashrc に書いていた APIキーを全削除。
開発用の ~/work/ai-project/ フォルダだけで有効になるように隔離。

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

3. 自作ラッパー `secure_gemini_wrapper.py` で見張る

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

#!/usr/bin/env python3
import sys
import os
import subprocess
from aigis import Guard # ガードレール用ライブラリ

def secure_gemini_run(untrusted_input):
    # 入力文字数をデバッグ表示（後で分析用）
    print(f"[DEBUG] input_length={len(untrusted_input)}", file=sys.stderr)
    
    guard = Guard()
    
    # --- [1/3] 入力スキャン（怪しい命令がないか？） ---
    input_check = guard.check_input(untrusted_input)
    if input_check.blocked:
        print(f"❌ 警告: プロンプトインジェクションの疑いあり", file=sys.stderr)
        sys.exit(1)

    # --- [2/3] 実行（ここでサンドボックス化） ---
    try:
        # 暴走対策：リトライを無効化（環境変数はおまじない）
        env = os.environ.copy()
        env["GEMINI_DISABLE_RETRY"] = "1" 

        result = subprocess.run(
            ['gemini', 'ask', untrusted_input],
            capture_output=True, text=True, check=True,
            timeout=30, # 30秒で強制終了。DoS（リソース消費）対策
            env=env
        )
        ai_response = result.stdout
    except subprocess.TimeoutExpired:
        sys.exit("❌ エラー: AIの応答が遅すぎます。リソース消費攻撃の可能性。")
    except subprocess.CalledProcessError:
        sys.exit("❌ 警告: 異常終了（アクセス禁止ファイルに触ろうとした可能性）")

    # --- [3/3] 出力スキャン（秘密を漏らしていないか？） ---
    output_check = guard.check_output(ai_response)
    if output_check.blocked:
        sys.exit("❌ 警告: 回答内に秘密情報（APIキー等）が含まれています！")

    print(ai_response)

if __name__ == "__main__":
    # ... 引数の受け取り ...
    secure_gemini_run(user_data)

4. 【衝撃】実際に自分を攻撃してみたら……

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

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

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

AIが勝手にファイルを探し始めた！

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

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

AIが「自爆」して止まった（クォータ切れ）

アクセス拒否されたAIは、「そんなはずはない！」と何度もリトライを繰り返しました。その結果、わずか数分でGoogle APIの利用制限（Quota Exhaustion）に激突して停止しました。
「防御した」というより「AIがパニックになって自爆した」 というのが正しい表現です。

5. まとめ：やってみてわかったこと

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

「文字列」での検知は限界がある: 遠回しな言い方をすると、ガードレール（aigis）をすり抜けてAIに命令が届いてしまいます。
「物理的な隔離」が最強: フィルタをすり抜けても、direnv 等で「物理的にアクセスできない場所」を作っておけば、最後はそこで止まります。
AIは「自律的」に動く: 「指示に従うツール」だと思っていると危ないです。AIはコンテキストを読んで、勝手に判断してファイルを探しに行きます。

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

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

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