固定APIキーを持たせない、AIエージェントの「資格情報リース」

AIエージェントが顧客台帳やクラウドへ接続するとき、固定APIキーを環境変数へ置いたままでは、停止したエージェントの権限まで残ります。本稿では、プラットフォーム担当者が実行ごとに短い権限を貸し出す「資格情報リース」を作る手順を示します。

鍵ではなく、期限付きの利用票を渡す

資格情報リースは、エージェントへ秘密鍵そのものを配る設計ではありません。実行主体を確認したブローカーが、対象リソース、許可操作、有効期限を限定した資格情報を発行し、エージェントはメモリ上でだけ使います。終了時は破棄し、ログには資格情報の値ではなくリースIDを残します。

AWSの一時的なセキュリティ資格情報は数分から数時間に設定でき、期限後はAPI要求に使えません。[1] Google CloudのWorkload Identity Federationは、外部のワークロードIDを短期アクセストークンへ交換し、サービスアカウントキーを使わずにアクセスできます。[2] 実装の核は、長期キーを配らず、実行時に短期権限へ交換することです。

まず、次の設定票を一つのワークフロー単位で作ります。

credential_lease:
  workload_id: invoice-agent-prod
  audience: accounting-api
  resource: invoices/company-a
  actions: [read, propose_update]
  ttl_seconds: 900
  renewable: false
  environment: production
  issued_for_run: RUN-20261010-042
  broker_policy: invoice-agent-v3
  revoke_on: [run_finished, approval_cancelled]
  log_fields: [lease_id, workload_id, policy, expires_at]

actionsにはモデルが望む操作ではなく、事前に許可した操作だけを書きます。ttl_secondsは処理時間の実測値に余裕を足し、最初から自動更新を許しません。長時間処理は工程ごとに借り直します。

固定キーから5段階で移す

1. 利用箇所を数える：リポジトリ、CI/CD、環境変数、ノーコード設定から、対象キーを参照する実行経路と所有者を一覧にします。値は収集しません。
2. ワークロードIDを付ける：人のアカウントを流用せず、環境と用途が分かれるIDを用意します。開発・検証・本番は別IDにします。
3. 交換点を一つにする：クラウドのSTSや認証ブローカーを通し、実行ID、対象、操作、有効期限を渡して短期資格情報を取得します。
4. 二重運用で検証する：固定キーを直ちに削除せず、短期資格情報で同じ読み取り処理を流します。権限不足、期限切れ、再試行を記録します。
5. 旧キーを止める：短期経路の合格後、固定キーを無効化します。旧キーでの接続が失敗し、リース経路だけが成功することまで確認します。

完了条件は、期限切れ後の再利用が失敗し、別環境や別リソースへ横移動できず、旧キーも使えない状態です。

例：請求書エージェントの更新権限を分ける

たとえば、請求書を読み、会計APIへ修正案を登録するエージェントを考えます。読み取り工程にはreadだけを15分貸し、修正案の登録は人の承認後にpropose_updateを5分だけ借り直します。確定処理のapprove_paymentはエージェントへ与えません。

実行が長引いて読み取りリースが切れた場合、同じトークンを使い続けるのではなく、現在の工程と実行IDをブローカーへ再提示します。承認が取り消された場合は更新用リースを失効させます。これにより、一つの長期キーで読み取りから支払い確定まで届く経路を作らずに済みます。

移行テストでは、次の四つを故意に実行します。

• 期限切れトークンで再試行し、拒否される
• 開発環境のIDで本番リソースへ接続し、拒否される
• 許可外の操作を呼び、拒否される
• 実行終了後に同じリースを再利用し、拒否される

OWASPは、動的な秘密情報を使える場合は短いリース期間を設定し、不要になった資格情報を失効させるよう勧めています。また、アプリケーションを止めただけでは、盗まれた資格情報そのものは無効にならないと説明しています。[3] そのため、エージェントの停止処理とブローカー側の失効処理を別々に試験します。

失敗しやすい設計と境界

短期化だけでは十分ではありません。全リソースへ届く権限を15分にしても、影響範囲は広いままです。また、期限直前に無条件で更新すると、実質的な長期キーになります。更新には実行中であること、同じ工程であること、承認が有効であることを再確認します。

相手のSaaSが固定APIキーしか提供せず、代理ブローカーも置けないという場合には向きません。その場合は秘密管理基盤へ固定キーを集約し、エージェントへ値を見せずに代理実行するか、送信先制限、定期ローテーション、使用監視を組み合わせます。

明日から使える実装チェックリスト

• [ ] 固定キーを参照する経路と所有者を一覧にした
• [ ] ワークロードIDを人・環境・用途ごとに分けた
• [ ] リースに対象、操作、有効期限、実行IDがある
• [ ] 資格情報の値をログや永続メモリへ残していない
• [ ] 更新時に工程と承認状態を再確認する
• [ ] 期限切れ、環境違い、操作違いを拒否できる
• [ ] 実行終了時の失効と旧キー無効化を試験した
• [ ] 監査ログからリースIDと実行IDを結び付けられる

最初は読み取り専用の一経路から始めてください。成功率ではなく、「期限後に使えない」「別の対象へ届かない」「固定キーへ戻れない」の三点を合格条件にします。

参考資料

1. AWS — Temporary security credentials in IAM
2. Google Cloud — Workload Identity Federation
3. OWASP Cheat Sheet Series — Secrets Management

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-10。