「鍵の中身、見えてます」 AWS Secrets Managerでも安心できなかった理由
セッションの核心である「鍵の渡し方」で佐々木氏が語ったのは、自身の失敗談だった。Claude Codeを使い始めた当初、鍵の置き場所さえ安全にすればよいと考え、AWS Secrets Managerに認証情報を保管し、API経由でキーを取得する構成を組んだ。これで安全だと思っていたが、実際にはClaude自身にシークレットを取得する権限まで与えていた。
X（旧Twitter）の自動投稿の仕組みを作っていたところ、うまく動かない原因をAIに相談すると、「Secrets Managerに置いてある値の形式がTwitterのAPIキーと違うようです」と返ってきた。鍵の中身が見えているのかと問い詰めると、AIは「見えています。ただし最初の何桁だけ見ているので安全です」と回答。それは漏洩だと指摘すると、AIは「ただちに鍵のローテーションをおすすめします」と正直に告げたという。
この一件から佐々木氏が導いた教訓は、保管場所の安全性とAIから見た安全性は別物であり、保管場所の設計だけでなく取得権限の設計が必要だということだ。プログラム同士で鍵を受け渡すことは通常問題にならないが、AIは自律的に動作しメモリーを持つため、鍵の内容を記憶し、後からプロンプトインジェクションなどで「鍵をばらして」と指示されれば、悪意なく漏らしてしまう可能性がある。この違いこそが、AIエージェント特有のクレデンシャルリスクの本質だと佐々木氏は指摘する。
鍵の渡し方は4段階、代理実行に近づくほど安全になる
佐々木氏は鍵の渡し方を安全性の低い順に4段階で整理した。分かれ目は置き場所ではなく「誰が取り出すか」だ。最も危険なのは、AIがファイルを直接読む「直読み」。.envへの直置きは最も事故りやすく、デフォルトでは保護されないうえ、Gitでの公開事故にもつながりやすいと佐々木氏は警告する。
次が環境変数で渡す「平文の外部注入」で、コマンド1つで値が露出し、子プロセスにも継承されてしまう。
3段階目が1PasswordやVaultなどを使い、取り出しをAIの外に委ねる「ストア経由の注入」。AI自身には取得権限を与えないものの、注入後の値はAIのプロセスから参照できてしまう点に本質的な危険性が残る。
最も安全なのが、AIに鍵そのものを持たせず、MCPなど外部の実行サービスに操作だけを許可する「代理実行」だ。鍵を持つのはAIの外にある実行サービスであり、AIに公開するのは許可された操作のみとなる。ここまで実現できれば安全性は高いが、実装のハードルも相応に高いと佐々木氏は認めた。
鍵の寿命についても言及があった。短期クレデンシャルは漏れても被害が限定されるが、処理の途中で切れてしまうという弱点がある。そこで佐々木氏が勧めるのは、鍵の更新を自動化し、人間が行うのはログインだけにする設計だ。
AIが使う鍵は自動更新の仕組みで短期のものを渡し続け、ログインが切れれば自動更新も止まる。ログインの有効期間は端末の使われ方次第で、例えば1日1回に設定すればよいという。ローカルPCではなくCI/CDやクラウドで動かす場合も、AIが使う鍵の寿命は同様に5分から1時間程度の短さに保つべきだと付け加えた。
設計とは、何もないところから作ることではなく、何が要るかを選ぶこと
最後に佐々木氏は、設定による事前防御、実行境界による多層防御、そして鍵の値そのものを渡さない代理実行という4つの構えを組み合わせて使うことを改めて呼びかけた。人が確認する操作を決めることはsettings.jsonで設定できるため、その範囲もあらかじめ決めておくべきだという。
「設計とは、何もないところから作ることではなく、何が要るかを選ぶこと」だと佐々木氏は語る。具体的な設定作業そのものはAIに任せてしまってよく、「こういう観点で設計してほしい」と依頼すればAIがきちんと設定してくれる時代になった。Claudeだけで不安であればCodexなど別のエージェントにクロスレビューさせることで、不備をより厳しく洗い出せるとも述べた。
明日からできることとして佐々木氏が挙げたのは、AIに鍵を読ませない設定を入れること、機密の置き場所を決めること、そして鍵の値そのものを渡さない形へ移行することの3点だ。まだAIエージェントを使っていない組織にも、これらを導入時のチェックリストに加えてほしいと呼びかけた。
任せる前に「できること」「届く範囲」「鍵の渡し方」の3つを決める、その勘所を持ち帰ってほしいと述べ、佐々木氏はセッションを締めくくった。
