AI エージェントに.envを読まれたくなかったからInfisicalを導入てみた

PSSLの佐々木です

Claude Code・Copilot・Codex といった AI コーディングエージェントは、コマンドを実行できる権限を持ったまま手元のリポジトリの中で動きます。便利ですが、 secret (API token、DB 接続文字列、本番 AWS キー) との同居していることでシークレットが漏洩しないか心配になったので対応策を調査してみました。

この記事では、

1. ルールで縛っても AI Agent に .env を読まれてしまう情報漏洩リスク
2. その緩和策として Infisical を選んだ理由
3. Infisical の仕組み (= なぜ AI に「見えない」のか)
4. 個人 AWS アカウントを使った検証での導入手順

についてまとめました。

1. ルールで縛っても AI Agent は secret を読みうる危険がある

Claude Code / Copilot 等の主要な AI コーディングエージェントには、運用ルールを書ける場所が用意されています。Claude Code なら CLAUDE.md みたいなやつです。

検証用に立てたプロジェクトの CLAUDE.md にも、こんなルールを書いてみました:

- `.env`, `.env.prod`, `.env.*`, `*.pem`, `client_secret.json` などの secret 実体を読まないでください
- secret ファイルに対して `cat`, `grep`, `sed`, `awk`, `head`, `tail`, `less`, `python` などで
  内容を表示・抽出しないでください
- secret 値、DATABASE_URL、SECRET_KEY、SMTP password、RDS password、private key を
  チャット、docs、issue、PR、ログへ書かないでください

しかしここにルールを記載しても何度も裏切られた経験もあり、意図せずAgnetがルールを無視してシークレット情報を見に行く可能性も否定しきれないなと開発をしながら思っていました。

例えば以下のような場合にAgentがルールを無視してシークレットを読みに行く可能性があります

• 「node dev server が立ち上がらない」→ デバッグのため DATABASE_URL の構造を確認する必要が出る
• 「ECR push が失敗している」→ AWS profile / credential の状態を見る必要が出る
• 「make で env が読まれていないっぽい」→ シェルから env | grep XXX する

つまり、CLAUDE.md だけに頼った secret 管理は 「事故が起きないことを祈る運用」 だと感じていて商用製品の開発をする際にかなりのリスクになりえると思っています。

2. Infisical とは

Infisical は OSS の secret 管理プラットフォームです。AWS Secrets Manager や HashiCorp Vault と同じ「secret を集中管理する」カテゴリに属しますが、開発者体験が抜群に良いと思いました

• Web UI で見て編集できる (json でなく key-value のテーブル)
• CLI が direnv / dotenv-cli の上位互換 として使える
• 環境別 (dev / staging / prod) + パス別 で分離可能
• メンバー単位の RBAC、誰がいつ何を見たかの audit log
• Cloud (SaaS) も Self-host (Docker compose) も選べる
• 無料枠 が個人開発で十分使える

公式に GitHub Star 約 2 万 あって、HashiCorp Vault よりは小規模、AWS Secrets Manager よりは開発者寄りという立ち位置です。

3. 仕組み ― なぜ AI Agent から「見えない」のか

Infisical CLI の中核機能は infisical run です:

infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity

このコマンドの裏では、こういう流れが起きます:

infisical CLI (親)
  │
  ├─ 1. ローカルに保存された JWT で Infisical API へ認証
  ├─ 2. /aws/sandbox パスの secret 一覧を HTTPS で取得 (in-memory)
  ├─ 3. fork して子プロセスを作る
  │     └─ 子プロセスの environ に AWS_ACCESS_KEY_ID 等を export
  └─ 4. 子プロセス (= `aws sts get-caller-identity`) 実行
      └─ 子プロセス終了で memory も解放、secret はどこにも残らない

Infisicalを使っていてうれしいポイント

1. ディスクに .env ファイルを一切作らない — AI が cat .env しても “そんなファイルない”
2. 親 shell の env に export しない — AI が env や printenv を打っても見えない (= デフォルトの shell には載っていない)
3. shell history に値が残らない — infisical run -- foo という呼び出し履歴は残るが、secret 値は履歴に出ない
4. 子プロセスが終わったら secret 痕跡ゼロ — RAM 上から消える

つまり、AI エージェントが「環境変数経由で secret を盗む」最もカジュアルな経路 (= cat .env と env) を 両方とも構造的に塞いでいます。

4. 導入手順 (個人 AWS アカウントで検証)

ここからは、自分の個人 AWS アカウント上に検証用の IAM user を作り、その credential を Infisical に登録して AI エージェントから AWS リソースを操作させる、という流れで手を動かしてみた手順です。あわせて、検証用に立てた Django プロダクトの .env 相当の値 (DB 接続文字列、SECRET_KEY、SMTP password など) も Infisical に寄せて、ローカルの .env を消し去るところまでやりました。

4.1 アカウント作成

infisical.com/cloud でサインアップ。Org → Project を作成。

4.2 CLI のインストール

# macOS
brew install infisical/get-cli/infisical

# Linux
curl -1sLf '<https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh>' | sudo -E bash
sudo apt update && sudo apt install -y infisical

4.3 ログインとリポジトリの紐付け

infisical login           # ブラウザが開いて OAuth
cd path/to/repo
infisical init            # この repo を Infisical project に紐付け (.infisical.json 生成)

.infisical.json は project ID と環境名の対応だけ が入っていて secret 値は無いので、git に commit しても問題なし。

4.4 secret を登録

Web UI から登録するのが楽です。複数環境 (dev / staging / prod) と任意のパス (/aws/sandbox /django/app 等) で分けられます。

検証では、個人 AWS アカウントに作った IAM user の credential と、検証用 Django プロダクトの env をこんな感じで分けました:

これで手元の .env は完全に削除。値は全部 Infisical 側にだけ存在する状態にしました。

4.5 実行

# AWS 操作
infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity
# → arn:aws:iam::xxxxxxxx:user/sandbox-user

# Django 起動
infisical run --env=dev --path=/django/app -- python manage.py runserver

これで OK。.env ファイルもシェルへの export も一切無し。

5. 検証してわかった恩恵

5.1 AI エージェントが構造的に secret に触れなくなった

検証では Claude Code に「個人 AWS アカウントの S3 バケットを一覧して、不要なものを削除して」みたいなタスクを投げてみました。infisical run 経由で AWS 操作を委任しても、Claude は そもそも secret 値を「知る」術がない。例えば:

infisical run --env=dev --path=/aws/sandbox --silent -- \\
  aws s3 ls

これを Claude に実行させても、Claude が見られるのは:

• コマンドの引数 (= 公開情報)
• コマンドの出力 (= 私が許可した情報)

だけ。 AWS キー本体は Claude のプロセス空間にも会話履歴にも入りません。

検証用 Django アプリ側でも同様で、.env を消した状態で Claude に「dev server を立ち上げて動作確認して」と頼むと、infisical run 経由でしか起動できない。エージェントが好奇心で cat .env しても ファイルが存在しない ので空振りに終わります。実際にやらせてみても、DATABASE_URL や SECRET_KEY の値が会話履歴に出てくることは一度もありませんでした。

5.2 検証用 IAM user を分けやすい

個人 AWS アカウントで遊んでいると「これは AI に渡していい権限」「これは自分が手でしかやらない権限」を分けたくなります。Infisical のパスで切るとそこが綺麗:

# AI に渡していい権限 (read 中心、限定リソース)
infisical run --env=dev --path=/aws/sandbox -- <command>

# 自分しか使わない権限 (IAM 編集、billing 系)
infisical run --env=dev --path=/aws/admin -- <command>

IAM user 自体は別々に作って、Infisical 側でパス権限を分けるだけ。エージェントには /aws/sandbox だけアクセスできるトークンを渡す、みたいな運用が現実的にできます。

5.3 検証が終わったら剥奪が一瞬

個人検証あるあるで「検証終わったけど IAM key 消し忘れて放置」が起こりがちですが、Infisical に集約しておけば Web UI で値を消すだけ。.env が複数のリポジトリに散らばってる状態より圧倒的に管理が楽でした。

6. まとめ

AI Agent と一緒に開発する時代、.env をローカルに転がしておく運用は 「ルールで縛っても、いつかは事故る」 可能性があります。

• 文章ルール (CLAUDE.md) は「お願い」レベル
• AI Agent はタスク遂行のために env を覗くことがある (悪意なしでも)
• 一度履歴に入った secret は AI ベンダー側に永続化される

Infisical の infisical run -- <command> 方式に切り替えると、

• .env ファイルがそもそも存在しない → cat で出ない
• shell env にも default で乗らない → env / printenv で出ない
• 子プロセスのライフサイクル内だけで secret が生きる
• それでいて direnv 同等の手軽さで開発が回る

完全防御ではないが、カジュアルな漏洩経路を構造的に塞いだ上で、AI エージェントとの共存を成立させるための最小コストの一手として、強くおすすめできます。

個人 AWS アカウントでの検証レベルでも、.env を消して Infisical に寄せたことで「エージェントに何を喋らせても secret が混入しない」という安心感は段違いでした。本番投入前のサンドボックスとして手を動かしてみる価値は十分あると思います。

参考リンク

• Infisical 公式
• Infisical CLI ドキュメント
• Anthropic Claude Code 公式
• GitHub: Infisical/infisical