# エージェントのシークレット管理——動的資格情報とローテーション

> AIエージェントのAPIキー・トークンはVaultや専用シークレットマネージャーで管理し、動的資格情報とランタイム注入を組み合わせることで漏洩時の爆発半径を最小化できる。

- Canonical: https://kuucorp.com/blog/agent-secret-management-rotation/
- Date: 2026-06-12
- Last modified: 2026-06-12
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
GitGuardianの調査（2026年版）によれば、2025年にGitHubのパブリックコミットで発見された新規ハードコード秘密情報は約2,900万件に上り、AI支援コミットは通常の約2倍の速度で認証情報を漏洩させている。AIエージェントが複数の外部APIを自律的に呼び出す環境では、1本のAPIキー漏洩がインフラ全体の制御奪取につながるリスクがある。

従来のCI/CD向けシークレット管理——環境変数への静的APIキー設定——では、エージェントのセキュリティ要件を満たせない。エージェントは複数のツール呼び出しにまたがって動的に認証情報を取得・破棄する必要があり、静的な長命キーはその設計と相容れない。本記事では、[エージェントセキュリティ設計](/blog/ai-agent-permission-management-design/)と連動するシークレット管理の実装パターンを解説する。

## なぜエージェントのシークレット管理は特殊なのか

> エージェントは人間のCI/CDプロセスとは異なるアイデンティティモデルを持ち、複数APIを自律的に呼び出す特性から、動的資格情報とランタイム注入を組み合わせた専用設計が必要です。

従来のIAMツールは人間とデバイスのために設計されており、自律的に動作するエージェントのアイデンティティモデルに対応していない。エージェントには次の特性がある。

- **多APIアクセス**: 1回のタスク実行でCRM・カレンダー・ストレージなど複数の外部APIを呼び出す
- **並行実行**: 複数のエージェントインスタンスが同時実行され、共有サービスアカウントでは帰属追跡ができない
- **プロンプトインジェクションリスク**: エージェントロジックが外部入力で操作された場合、保持している認証情報が即座に悪用される

これらの特性から、エージェントには「タスクが終わったら資格情報も消える」設計が理想的だ。ハードコードされたAPIキーや長命なサービスアカウントは、エージェント特有の攻撃面を直接拡大する。

## シークレット管理の基本アーキテクチャ

> エージェントのシークレット管理は「アイデンティティ層」「シークレットストア層」「ランタイム注入層」の3層で設計し、エージェントプロセスが直接シークレットを保持しないことを原則とします。

HashiCorp VaultのAIエージェント向けバリデーションパターンが採用する3層構造は以下の通りだ。

```
ユーザー
  └── AIエージェント（タスクスコープの委任トークン）
        └── MCPサーバー（スコープ検証・アクセス制御）
              └── Vault / シークレットストア（動的資格情報の発行・管理）
                    └── 外部API・データベース・内部サービス
```

このアーキテクチャの核心は「エージェントが下流サービスの生の認証情報を直接保持しない」点だ。エージェントはVaultから発行された自身専用の委任トークンを持ち、下流サービスへのアクセスはVaultまたはMCPサーバーが代理する。エージェントプロセスが侵害されても、漏洩するのは有効期限付きの委任トークン1本のみで、下流の本番サービス認証情報には到達できない。

**シークレットストアの選択肢**:

| ツール | 特徴 | 適したケース |
|---|---|---|
| HashiCorp Vault | 動的シークレット・ポリシーエンジン・監査ログが統合 | オンプレ/マルチクラウド環境 |
| AWS Secrets Manager | 自動ローテーション・RDS/Redshift連携が標準搭載 | AWSネイティブ環境 |
| Azure Key Vault | Azure AD統合・Managed Identity連携 | Azureネイティブ環境 |
| 1Password Service Accounts | エージェント向けランタイム注入API | SaaS中心のSMB環境 |

## 動的資格情報とローテーション設計

> 動的資格情報はリクエストごとに生成しTTL 1〜2時間で自動失効させる。HashiCorp VaultのDynamic SecretsとAWS Secrets Managerの自動ローテーションがこのパターンの実装基盤になります。

**静的シークレット vs 動的シークレットの比較**:

静的シークレットは一度発行されると失効まで有効で、侵害されても検知が難しい。動的シークレットはリクエスト単位で発行・失効するため、漏洩ウィンドウがTTLの長さに限定される。

```python
# HashiCorp Vault: AWS動的シークレットの取得例
import hvac

client = hvac.Client(url='https://vault.example.com', token=vault_token)

# エージェントタスクに必要なAWSクレデンシャルを動的発行
creds = client.secrets.aws.generate_credentials(
    name='agent-s3-reader-role',
    ttl='1h'
)
# creds.data['access_key'] / creds.data['secret_key']
# → 1時間後に自動失効。手動ローテーション不要。
```

Vaultの動的シークレットエンジンは、エージェントがAWS/GCP/Azureのクレデンシャルを要求するたびに一時的なIAMユーザー/サービスアカウントを発行し、TTL経過後に自動削除する。データベース認証情報も同様に動的発行できる。

**OIDCトークンによる環境変数レス設計**:

VercelなどのサーバーレスプラットフォームはOIDCトークンをTTL 60分で発行する。環境変数に長命なAPIキーを置かず、デプロイ時にOIDCトークンをワークロードアイデンティティとして使う設計が2026年時点で広く採用されている。

```yaml
# GitHub Actions: OIDC統合によるAWSクレデンシャル取得（環境変数レス）
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/agent-deploy
    aws-region: ap-northeast-1
    # access_key/secret_keyは一切設定しない
```

## OAuth 2.1 OBOフローとトークン交換

> エージェントが外部APIを呼び出す際はOAuth 2.1のOn-Behalf-Ofフローでユーザーのトークンをエージェント専用の短命トークンに交換し、スコープと委任帰属を維持します。

エージェントがユーザーの代理で外部APIを呼び出す際、ユーザーの元のトークンをそのまま使うのはスコープ過剰・帰属追跡困難という問題がある。OAuth 2.0 On-Behalf-Of（OBO）フローは、元のユーザーアイデンティティを保持しながら、エージェント専用の適切スコープのトークンに交換する。

HashiCorp Vaultのバリデーションパターンでは、トークン交換時に次のクレームを引き継ぐ。

- **groups**: ユーザーのディレクトリグループ（RBAC マッピング用）
- **preferred_username**: 監査ログのユーザー特定に使う一意の識別子
- **azp (Authorized Party)**: 中間エージェントのアイデンティティ

これにより、どのユーザーがどのエージェントを通じて何のAPIを呼んだかが、Vaultの監査ログに完全な証跡として残る。

**アンチパターン（避けるべき設計）**:

- 環境変数に静的APIキー → 有効期限なし・コンテキスト帰属不能
- 共有サービスアカウント → エージェントごとの行動追跡不可
- エージェントへのフルユーザーセッション継承 → スコープ過剰
- タスク完了後もトークンを保持し続ける → 不必要な攻撃面の拡大

**プログレッシブスコーピング**:

エージェントは起動時に全権限を要求するのではなく、必要最小限のスコープから始め、追加アクセスが必要になった際にOAuthの段階的認可（Step-Up Authorization）フローで拡張する設計が推奨される。

### 規模別の留意点（SMB / エンタープライズ）

**SMB**: 全てを内製する必要はない。まず環境変数からシークレットを排除し、マネージドサービス（AWS Secrets Manager・1Password Service Accounts）を採用することから始める。Vaultの自己ホストは運用負荷が高く、クラウドネイティブな選択肢で十分なケースが多い。エージェントのスコープは起動時に明示的に設定し、使用するAPIごとに専用の認証情報を割り当てる。[Kuuのエージェント運用管理サービス](/services/ai-ops/)ではシークレット管理設計の支援を行っている。

**エンタープライズ**: 複数チーム・複数エージェントが同一VaultクラスタまたはシークレットストアをHSM（Hardware Security Module）や外部KMSと組み合わせて利用する場合、ネームスペース分離とポリシーエンジンが必要になる。監査ログは `X-Correlation-ID` をエージェント→MCPサーバー→Vaultまで一貫して伝搬させ、フォレンジック追跡できる設計にする。大規模なシークレット管理基盤の設計は[KuuのRDEサービス](/services/rde/)で対応している。

## 参考

- [Secure AI agent authentication using HashiCorp Vault dynamic secrets — HashiCorp Developer](https://developer.hashicorp.com/validated-patterns/vault/ai-agent-identity-with-hashicorp-vault)
- [AI Agent Credential Management Best Practices — Descope](https://www.descope.com/blog/post/ai-agent-credential-management)
- [AI Agent Secrets Management: Best Practices for 2026 — Fastio](https://fast.io/resources/ai-agent-secrets-management/)

## まとめ

エージェントのシークレット管理は「エージェントが生の認証情報を直接保持しない」設計原則から出発する。動的資格情報（TTL 1〜2時間）とランタイム注入の組み合わせで、漏洩時の爆発半径をタスク単位に限定できる。OAuth 2.1 OBOフローによるトークン交換を組み合わせると、スコープと帰属の追跡も同時に実現できる。静的APIキーの環境変数依存から脱却することが、エージェントセキュリティ強化の最初の一歩だ。

エージェントのシークレット管理設計・セキュリティガバナンス体制の整備については、[Kuu株式会社のエージェントガバナンスサービス](/services/ai-ops/)にご相談ください。