【ITニュース解説】Build a Homedir Deny Fixture Before an Agent Reads `.netrc`

最近、AIによるコーディング支援エージェントが、開発者の意図しない形で機密情報（API認証情報やデータベースパスワードなど）を読み取り、チャットやログに表示してしまう事例が報告されている。これはエージェントが悪意を持って情報を盗むわけではなく、ファイル操作ツールとして通常の動作をした結果、アクセス可能な範囲が広すぎたために発生する問題だ。例えば、エージェントがプログラムの修正を手伝う際、リポジトリの小さなスクリプトを実行しただけで、そのスクリプトが参照するユーザーのホームディレクトリにある.netrcファイルの内容を読み取り、チャットに表示してしまうことがあった。

この問題の本質は、AIモデルの安全性や性能ではなく、エージェントが「どのファイルパス」までアクセスできるかという点にある。開発者がSlackなどに貼り付けないような機密ファイル、例えばAPIキーやデータベースのパスワードなどが、エージェントの作業ディレクトリの範囲外にあるにもかかわらず、間接的にアクセスされてしまう可能性があるのだ。エージェントがユーザーのホームディレクトリ（~）にある機密ファイルまで参照できる状況は、本来厳しく守るべき「信頼境界」が曖昧になっていることを意味し、これはエンジニアリングの観点から見過ごせない欠陥となる。

特に危険なのは、ホームディレクトリに配置されがちな以下の認証情報ファイルだ。.netrcはネットワーク接続の認証情報（ユーザー名、パスワード）を含み、内部APIへの不正アクセスにつながる可能性がある。.pgpassはPostgreSQLデータベースへの接続パスワードを格納し、漏洩するとデータベースが乗っ取られるリスクがある。また、.docker/config.jsonにはDockerレジストリの認証トークン（base64エンコードされたユーザー名とパスワード）が含まれ、プライベートなコンテナイメージへの不正アクセスを招く恐れがある。これら以外にも、SSHの秘密鍵（id_rsa、id_ed25519）、Gitの認証情報（.git-credentials）、Kubernetesの認証トークン、AWSの認証情報（.aws/credentials）なども同様に機密性が高く、エージェントがこれらにアクセスできると、その情報がチャット履歴やログ、セッションデータに残ってしまい、重大な情報漏洩となる危険性がある。

このような機密情報の漏洩を防ぐためには、AIエージェントに渡す作業ディレクトリが、特定の機密ファイルを含んでいないかを厳しくチェックする「ゲート」を導入することが不可欠だ。これは、エージェントがアクセスする作業ルートが、ユーザーのホームディレクトリやシステムのルートディレクトリそのものではないか、ホームディレクトリの内部に位置していないか、そして指定されたディレクトリ内に.netrc、.pgpass、.docker/config.jsonといった「拒否リスト」に登録されたファイルが存在しないか、といった点を検証する仕組みだ。これらのいずれかの条件に違反した場合、ゲートはエラーを返して処理を停止させる。このゲートは、たとえエージェントが実行するスクリプトが直接機密ファイルを参照していなくても、ディレクトリ内に機密ファイルが存在するだけで失敗するように設計されており、将来的にスクリプトの内容が変わっても安全性が保たれる。このゲートのテストには、実際のパスワードの代わりに「カナリア（canary）」と呼ばれる偽の認証情報文字列（例: canary-netrc-token-NOTREAL）が使われる。もしこのカナリア文字列がエージェントの出力やログに含まれていれば、それはセキュリティ上の問題があることを示す明確な兆候となる。

セキュリティを確保するには、単一の対策だけでなく、複数の層でのアプローチが必要となる。まず予防策として、エージェントの作業ルートを、ホームディレクトリが一切マウントされていない専用の隔離されたディレクトリとするべきだ。また、CI/CD（継続的インテグレーション/継続的デリバリー）という開発プロセスの自動化システムにこのゲートスクリプトを組み込み、エージェントに渡すディレクトリの安全性を自動的に検証することが重要だ。検知策としては、エージェントのセッションログやツールが残すトレース記録を定期的に監視し、カナリア文字列や不審な認証情報が含まれていないかを検出する。同時に、エージェントの実行環境自体が、指定された作業ルート以外のファイルへの読み書きや実行を厳しくブロックするように設定する。万が一、機密情報の漏洩が確認された場合は、カナリアに対応する本物の認証情報を直ちにローテーション（変更）し、関連するチャット履歴やセッション記録を速やかに破棄するといった復旧策が必要となる。

重要なのは、エージェントの「指示」ではなく、CI/CDや実行環境による「物理的なアクセス制御」で信頼境界を強制することだ。.gitignoreファイルのように、単にコミット対象から外すだけでは、エージェントが作業中のファイルツリー全体を見てしまうため、真の信頼境界とはなり得ない。エージェントには、.netrc、SSH秘密鍵、config.jsonの認証情報など、機密性の高いファイルの内容をいかなる形でも直接的、間接的に見せてはならない。もしエージェントが認証情報を必要とする作業を行う場合は、カナリアを含むダミーデータや、意図的に制限されたテスト用の認証情報のみを渡すべきである。開発者は、手軽さや無料のリソースに誘われて、GitのプッシュやDockerのログインに使うのと同じ開発環境でエージェントを動かすべきではない。エージェントの作業環境は常に「隔離」された状態であるべきで、ホームディレクトリのような機密情報が多数存在する場所から完全に分離することが、最も効果的なセキュリティ対策となる。

ただし、このゲートの仕組みには限界もある。これはファイル名やパスに基づいて機密ファイルを拒否するものであり、ファイルの内容を詳細にスキャンする機能は持たないため、local.settings.jsonのように機密情報が含まれていてもファイル名が拒否リストにない場合は検出できない。また、エージェントに無制限のシェルアクセスが許可されている場合や、ホームディレクトリを共有する必要がある場合は、この防御策だけでは不十分だ。真のセキュリティは、「秘密を読まないでください」といったシステムプロンプトの指示ではなく、「CI/CDやツール実行環境で強制される物理的な不変条件」によって担保されるべきものなのである。