AIエージェントに秘密を"渡さずに使わせる" — Secrets Manager二層機構で、モデルに認証情報の平文を触れさせない設計
コーディングエージェントに資格情報を渡すとき、平文をモデルに一度も触れさせずに使わせる。保証の源は「モデルに頼む」Layer1ではなく、エージェントプロセスの外で実値解決するLayer2（プロセス分離）です。Toolkitに任せる範囲と、最小権限・scoping・ローテーションなど自前で握る範囲の線引きを中立に整理します。
- #AIエージェント
- #セキュリティ
- #Secrets Manager
- #OWASP LLM
- #認証情報
- #連載
コーディングエージェント（Claude Code・Codex・Cursor など、開発作業を代行するAIエージェント）にデータベースのパスワードやAPIキーを渡したい場面は、開発の現場で日常的に発生します。エージェントにマイグレーションを実行させたい、外部APIを叩かせたい——そのたびに資格情報が要ります。ところがここで素朴に「秘密の平文をエージェントに教える」と、その値はモデルに送られるコンテキスト（model context）、セッションのログ（session log）、エージェントのメモリ（agent memory）といった、モデルが扱う領域に残ります。OWASP の LLM アプリ向けリスク分類でも、機密情報の漏洩（Sensitive Information Disclosure）は主要な攻撃面として挙げられています。本記事は、この問題に対する Secrets Manager の二層機構を、「秘密を渡す」のではなく「渡さずに使わせる」という設計の観点から解説します。エージェント全般の脅威モデルの総論には深入りせず、必要に応じて別記事へ案内します。客観・中立に、防御設計に絞って整理します。
まず射程を切る — 「エージェント×Secrets Manager」は3つに分かれる
「AIエージェントに Secrets Manager の秘密を使わせる」という話題は、実は性質の異なる3つの仕組みに分かれます。混同すると設計を誤るため、最初に線を引きます。本記事が扱うのは (A) です。
| 区分 | 仕組み | 使う場面 | 本記事での扱い |
|---|---|---|---|
| (A) | safe secrets handling / Agent Toolkit for AWS | 開発時（dev-time）のコーディングエージェント | 主役 |
| (B) | Workload Credentials Provider（旧 Secrets Manager Agent） | 本番ランタイム（compute上のローカルHTTPサイドカー） | 別設計・接続のみ |
| (C) | AgentCore Identity の bring your own secrets | 本番のAgentCoreエージェント（顧客所有ARN） | 別設計・接続のみ |
(A) は、Agent Toolkit for AWS が提供する「安全な秘密の取り回し（safe secrets handling）」で、開発時にコーディングエージェントが資格情報を使う場面を対象とします。後述する二層機構を持ち、2026年6月時点で利用可能（available today）です。(B) の Workload Credentials Provider（旧称 AWS Secrets Manager Agent）は、コンピュート上で動くローカルのHTTPサイドカーが、実行時に秘密を読み取りキャッシュする仕組みで、本番ランタイム向けです。(C) の AgentCore Identity の bring your own secrets は、本番の AgentCore エージェントが Credential Provider を通じて顧客所有の Secrets Manager の ARN を参照する仕組みで、2026年6月1日に一般提供（GA）が公式に案内されています。
構図を一文でいえば、(A) は「開発時に、モデルへ平文を通さない」、(B)(C) は「本番ランタイムで、エージェントに秘密を消費させる」です。向きが違います。本記事は (A) に閉じ、(B)(C) は本番ランタイムの別設計として、後半で接続先だけ示します。
二層機構の実体 — 何がどこで起きるか
(A) の安全な秘密の取り回しは、二つの層（レイヤー）で成り立ちます。重要なのは、どちらが「平文を漏らさない保証」を担っているのか、という点です。
Layer1（モデル操舵） は、モデルに対して秘密の生の値を要求させず、受け取らせもせず、代わりに「秘密を使うコマンド」を組み立てさせる層です。たとえば「この環境変数を参照してコマンドを実行する」といった形に誘導（steer）します。ただしこの層はモデルの振る舞いに依存するため、非決定的（non-deterministic） です。モデルが必ずそう動くという保証は、この層単独では立ちません。
Layer2（プロセス分離） が、保証の源です。実際の値の解決は、子プロセスがエージェントのプロセスの外側で、実行時に行います。エージェント（とそのモデル）が動くプロセスとは別のプロセスで実値が解決されるため、平文はモデルが触れる領域を通りません。公式は、この仕組みによって「平文の秘密が、モデルコンテキスト・セッションログ・エージェントメモリのいずれにも現れない（plaintext secrets never appear in model context, session logs, or agent memory）」と説明しています。
提供形態は、Agent Toolkit for AWS の aws-core プラグイン（オープンソース）で、2026年6月時点で利用可能、Secrets Manager が使える全リージョンで動作します（特定リージョン名はここでは挙げません。利用可否は公式の最新情報をご確認ください）。
設計の芯 — 「渡す」のではなく「渡さずに使わせる」
ここがこの記事の核です。素朴な発想は「秘密を安全に渡す」ですが、二層機構が実現しているのは「秘密を渡さずに使わせる」です。両者は似て非なるものです。
「安全に渡す」は、結局どこかでモデルに平文を渡すことを前提にし、その経路の暗号化やマスキングで守ろうとします。これは Layer1 的な発想、つまりモデルの振る舞いに頼る統制であり、非決定的です。一方「渡さずに使わせる」は、平文の解決をモデルの手の届かない場所（別プロセス）に置きます。モデルがどう振る舞っても、そもそも平文がモデルの領域を通らない——このモデルの外で強制するという構造が、保証を成り立たせます。
この発想は、本連載で繰り返し現れる背骨と同じ型です。認可（誰が何をしてよいか）をモデルの判断ではなくモデルの外側のエンジンで強制する設計、あるいはエージェントの支出上限をモデルの外側・インフラ層で決定的に強制する設計と、まったく同型です。秘密管理もまた、「モデルに頼んで守る」のではなく「モデルの外で強制する」系列に連なります。逆にいえば、設計の説明で「モデルに頼んで守る」と書いてしまうと、Layer1 の非決定的な層を保証の源と取り違えていることになります。
任せる範囲 vs 自前で握る範囲
二層機構は強力ですが、守ってくれる範囲には境界があります。ここを誤解すると、「Toolkit を入れたから秘密管理は万全」という過信につながります。線引きを明確にします。
Toolkit が守るのは、あくまで「モデルバイパス」までです。すなわち、平文をモデルの領域に通さないこと。ここは二層機構が担います。
一方、次の統制は二層機構の対象外で、Secrets Manager 本体の機能として別に設計する領域です。
- 最小権限: そのエージェント（や実行ロール）が参照できる秘密を、必要なものだけに絞る。IAM ポリシーや resource policy の設計が要ります。
- secret scoping: 取得できる秘密の範囲を、用途・環境ごとに限定する。
- ローテーション（rotation）: 秘密を定期的に入れ替える。二層機構はローテーションを代替しません。漏洩時の被害時間を縮める統制は別に要ります。
- 失効（revoke）: 不要になった権限や秘密を確実に無効化する。
つまり、二層機構は「平文がモデルに流れない」を担保しますが、「誰がどの秘密にアクセスできるか」「どれだけの頻度で入れ替えるか」までは面倒を見ません。後者は従来どおり Secrets Manager の機能と運用設計で握る必要があります。
本番ランタイムへの接続
(A) の思想——「実値解決をモデルの外で行う」——は、開発時だけの話ではありません。本番で動くエージェントにも同じ原則を持ち込めます。ここで冒頭の (B)(C) が接続先になります。
(B) Workload Credentials Provider は、コンピュート上のローカルなサイドカーが実行時に秘密を解決・キャッシュする仕組みで、EKS などで動く本番ワークロードに向きます。(C) AgentCore Identity の bring your own secrets は、本番の AgentCore エージェントが顧客所有の Secrets Manager ARN を参照する仕組みで、顧客側で CMK（カスタマー管理鍵）・タグ・ローテーション・resource policy といったガバナンスを握れます。前述のとおり (C) は2026年6月1日に一般提供が公式に案内されています。
射程は (A) と分けますが、貫く原則は同じです——平文の解決をモデルの手の届かない場所で行い、ガバナンス（権限・鍵・ローテーション）は秘密の保有者側で握る。本番エージェントの運用・監査の総論は、別記事の本番運用のための生成AIエージェント運用に整理しています。
まとめ — 「渡さずに使わせる」を一語で
コーディングエージェントに資格情報を使わせる設計の芯は、「秘密を安全に渡す」ではなく「秘密を渡さずに使わせる」ことです。保証の源は、モデルに頼む Layer1（非決定的な操舵）ではなく、エージェントのプロセスの外で実値を解決する Layer2（プロセス分離）にあります。公式の言葉では、平文の秘密はモデルコンテキスト・セッションログ・エージェントメモリのいずれにも現れません。
ただし二層機構が守るのはモデルバイパスまでで、最小権限・secret scoping・ローテーション・失効は Secrets Manager 本体の機能として別に設計する領域です。「Toolkit を入れたから万全」ではなく、任せる範囲と自前で握る範囲を線引きしてください。そして本番ランタイムでは (B) Workload Credentials Provider や (C) AgentCore Identity の bring your own secrets が、同じ「モデルの外で実値解決する」原則の延長に位置します。
エージェント全般の脅威モデル（プロンプトインジェクションを含む攻撃面と多層防御）はLLMエージェントのセキュリティ設計に、本番運用・監査の総論は本番運用のための生成AIエージェント運用に整理しています。なお、認可（モデルの外で権限を強制する設計）や、エージェントに決済を任せる際の支出上限の強制といった同型のテーマも隣接しますが、こちらは公開後にあらためてご案内します。