dotenvxによる暗号化だけでは不十分

つい最近、X（旧Twitter）でこんな話題が盛り上がっていました。
「LLMと開発する上で、.envファイルをどう管理するか」
「dotenvxで暗号化すればOK」という回答をよく見かけました。しかし、この問い自体が狭い。LLMが同じ実行環境にいる時に危険にさらされるのは.envだけではありません。 SSOセッション、1Passwordのアンロック状態、シェル履歴、実行中のプロセスの環境変数——全部同じ土俵の話です。
さらに言えば、議論の多くが「どこに保存するか（Write）」にばかり目を向けていて、「誰が読み出せるか（Read）」の経路を議論していなかった。
本質的な問いは「LLMが同じ実行環境にいる時、何が危険にさらされるか」です。この記事ではその問いから設計を考え、最終的には社会的な信頼の話にまで行き着きました。

脅威モデルの定義

Claude CodeなどのLLMは「同一ユーザー権限を持つSuper Hacker」と仮定する。実行環境に存在すれば、原理的になんでもできる。

これは極端な仮定ですが、安全側に倒した脅威モデルとしては妥当です。脅威は大きく2つに分けられます。

脅威1：ローカルに保存されたクレデンシャルを読み出す

同じユーザーで動いているプロセスから、以下のようなことが原理的に可能です。

• 環境変数の読み取り（/proc/<pid>/environ）
• シェル履歴の参照
• ps aux によるプロセス引数の盗み見
• 1Password CLIのセッションが解除済みであれば op read での取得

脅威2：クラウドから読み出す

ローカルにクレデンシャルが存在しなくても、クラウドCLIの認証情報がローカルに残っていれば、本番環境のクレデンシャルを取得・操作できます。
人間のエンジニアが本番環境を操作するとき、それは意識的な判断の結果です。しかしエージェントが自律的にタスクをこなす時代になると、同じ操作がタスク完了の過程で副作用として実行される可能性があります。「ローカルに置いていないから安全」だけでは不十分な理由がここにあります。

結論1：ローカルには本番環境のクレデンシャルを保存しない

本番クレデンシャルをローカルに置かない。それだけでClaude Codeは物理的に触れなくなります。インフラのapplyやdeployはCIに完全に委ねて、クレデンシャルはCIのクレデンシャル管理にのみ存在させる。クレデンシャルが存在しなければ、Claude Codeが何をしようと触れるものがない。制限するより、存在を消す方が強い。

結論2：ローカルから本番環境のクレデンシャルをReadできないようにする

「安全な場所に保存した」だけでは不十分で、「ローカルからReadできない」設計になっているかを確認する必要があります。 ここが最も見落とされがちな観点です。
例えばAWS Secrets Managerに本番のクレデンシャルを保存していても、クラウドCLIの認証情報がローカルに残っていれば、ローカルから普通に取得できます。Claude Codeも同様です。

# 認証情報があれば実行できてしまう
aws secretsmanager get-secret-value --secret-id prod/api-key

これを根本的に解決するには、Claude Codeを隔離された環境で動かし、そこに渡す認証情報を開発用のみに絞ることが筋です。開発者のフル権限の認証情報はホスト側に置いたまま、Claude Codeの環境には渡さない。

ホスト（開発者）
├── 本番クレデンシャル → CIのみ（結論1）
├── フル権限のクラウド認証情報 → ホストのみ、Claude Code環境に渡さない
└── Claude Code環境（Docker等）
    └── 開発用クレデンシャルのみ（結論3）

この構造が完成したとき、Claude Code環境の中で--dangerously-skip-permissionsを打っても、触れられる本番クレデンシャルがそもそも存在しない状態になります。

結論3：開発用のクレデンシャルは流出しても被害が少ないようにする

結論1・2を徹底すると、ローカルに残るのは開発用のクレデンシャルだけになります。これをゼロにするにはClaude Codeを開発環境から完全に排除するしかなく、現実的ではありません。セキュリティと利便性のバランスを見極めることが重要です。
開発用クレデンシャルが漏れても本番データへのアクセス権はないため、情報漏洩の観点でのダメージはありません。残るリスクはAPIを悪用されてコストが跳ね上がることで、以下の対策でカバーします。

• 開発環境キーの権限を最小にする（サンドボックス・読み取り専用等）
• 請求のリミットを設定してアラートを出す
• サービスごとにキーを分けて影響範囲を限定する

最後に：これは過渡期の設計である

この設計を考えながら、ふと気づいたことがあります。
人間のエンジニアが本番のクレデンシャルにアクセスできるのは、雇用契約・法的責任・社会的評判という信頼のインフラがあるからです。悪用すれば訴えられ、クビになり、業界で生きていけなくなる。そのブレーキが機能しています。LLMに今それがないのは、技術的な問題というより、信頼のインフラがまだ整備されていないという話です。
Claude自身のpermission設定を細かく調整するアプローチもありますが、突き詰めると「Anthropicをどこまで信じるか」という話になります。それは技術的に検証できる問題ではなく、信頼の問題です。この記事で提案した設計は、その信頼に依存しない構造を作ることを目指しています。
Anthropicが「このモデルはこういう行動をしない」という保証が法的・社会的に意味を持つようになったとき、LLMにより多くの権限が委譲されていくでしょう。今やっていることは、その信頼のインフラが整備されるまでの、普通の運用判断に過ぎないのかもしれません。