AIエージェントにクレデンシャルを渡す4つの方式と使い分け
①直読み型 ②env注入型 ③Secret Store型 ④Role統合型の4つがあり、個人なら②〜③、組織なら③〜④が現実的（@dkfj の整理）。
4つの方式
| 方式 | やり方 | 向き・注意 |
|---|---|---|
| ① 直読み型 | .env などをエージェントが直接読む | 手軽だが、エージェントが値を見て会話ログや出力に残しうる。.gitignore に入っていてもエージェントは読む |
| ② env注入型 | 隔離したファイルから起動時に環境変数として注入 | 個人向け。エージェントの作業ディレクトリに値のファイルを置かない |
| ③ Secret Store型 | 1Password や aws-vault などから都度取得 | 個人〜組織。参照だけを書き、値はその場で取りに行く（例: Codex: 1Password の MCP で .env を「平文で書かない」形でマウントする） |
| ④ Role統合型 | IAM Role／STS／OIDC で SDK が裏で認証 | 組織向け。長期のキー自体を持たせない |
手順
- 今エージェントが触れる場所に平文のキーがないか棚卸しする（作業ディレクトリの
.env、シェルの設定ファイルなど） - 個人開発なら、まず②か③に移す。③は取得のたびに承認や生体認証を挟めるので、勝手に使われにくい
- クラウドの権限は可能なら④にし、短期の認証情報だけが流れるようにする
- あわせて、エージェントが
.envを読む操作をフックで止める（ptuf: 1コマンドで PreToolUse フックを入れ、.env や危険コマンドを止める など）
注意点
- どの方式でも、エージェントの子プロセスに渡った値は使われうる。必要なキーだけ、必要な権限だけ渡す
- ツールに保存したキーが漏れたときの対応は ツールに保存した API キーが漏れたら: プロバイダー側で失効し、ハード上限を設定しておく を参照
出典
- @dkfj · 2026-05-06
- @dkfj 2026-05-05（ブログ「AIエージェントに認証情報を安全に渡したい：1Passwordで試して、用途で使い分けに着地した話」）: @dkfj · 2026-05-05