権限境界と認証情報分離

エージェントにマスターキーを渡すのをやめる

🔄 Quick Recall: 前回のレッスンで、5つのDockerハードニングフラグでエージェントをコンテナ化した。コンテナはエージェントがシステムにできることを制限する。しかしそのコンテナ内部では、エージェントはあなたが与えたすべてにアクセスできる——そしてほとんどの人は与えすぎている。

Argusセキュリティ監査でOpenClawがOAuthトークンを暗号化なしの平文JSONファイルに保存していることが判明。ファイル権限は0o600（オーナーのみ読み書き）に設定されていたが、OpenClawがファイルオーナーとして実行されるため、エージェントがロードするすべてのスキルがそのトークンを読める。

512の脆弱性。8つがクリティカル。そして最も根本的なものは：エージェントがあなたと同じアクセス権を持つこと。

このレッスンの終了時にできるようになること：

• AIエージェント設定に最小権限を適用できる
• エージェントが生のシークレットを扱わないよう認証情報分離を設定できる

問題：エージェントはあなた自身

AIエージェントにAPIキーを渡すとき、「一部のアクセス」を渡しているのではない。あなたのアクセスを渡している。同じ権限、同じスコープ、同じ影響範囲。

そのキーが本番データベースの読み書きができるなら、エージェントもできる。悪意あるスキルがそのキーを外部流出させたら、攻撃者はあなたの完全なデータベースアクセスを得る。エージェントのアクセスではない——あなたのアクセス。

NISTの2026年AIエージェントセキュリティに関するRFIは明確に述べた：エージェントは「最小権限とゼロトラストアーキテクチャ」に従うべき。エージェントは特定のタスクに必要な最小限のアクセスを得、すべてのステップで検証される。

原則1：スコープ付きトークン

エージェントにマスターキーを渡す代わりに、エージェントが必要とするものに正確にスコープされたトークンを作成する。

例：メール統合

最も制限的なスコープから始める。エージェントがもっと必要なら明示的に追加——最初から広くして後で狭めようとしない。

例：ファイルシステムアクセス

# ホームディレクトリ全体をマウントする代わりに：
volumes:
  - ~/:/app/home:rw  # これはやめる

# エージェントが必要なディレクトリだけをマウント：
volumes:
  - ~/projects/current:/app/workspace:rw
  - ~/documents/reference:/app/reference:ro  # 読み取り専用

マウントされたすべてのボリュームは潜在的な攻撃サーフェス。それぞれに正当な理由が必要。

✅ Quick Check: エージェントがDocumentsフォルダのファイルを要約する必要がある。正しいボリュームマウントは？（答え：~/Documents:/app/docs:ro——Documentsフォルダのみへの読み取り専用アクセス。エージェントはファイルを読んで要約できるが、変更、削除、そのディレクトリ外へのアクセスはできない。）

原則2：認証情報分離

認証情報はエージェントのコンテキスト内に存在すべきではない。ComposioのManaged Authアプローチがパターンを示す：

1. 認証情報は別サービスに保管（シークレットマネージャー、Vault、認証プロキシ）
2. エージェントはアクションを要求（「このメールを送って」）しトークンを見ない
3. 認証サービスがアクションを実行しエージェントがアクセスできない認証情報を使用
4. 監査ログが記録し何が要求され何が実行されたか追跡

これがゴールドスタンダード。エージェントが完全に侵害されても、攻撃者は認証情報を取得できない——認証サービスを通じてリクエストを出すことしかできず、認証サービスは独自のポリシーを適用する。

個人使用向けのシンプルなバージョン：

# APIキーを環境変数として渡す代わりに：
OPENAI_API_KEY=sk-abc123  # エージェントがこれを読める

# 認証を注入するプロキシを使用：
# エージェントが http://localhost:8080/api を呼び出す
# プロキシが転送前にAPIキーヘッダーを追加
# エージェントはキーを見ない

プロキシが認証情報の境界として機能する。エージェントはプロキシと通信する。プロキシが認証を処理する。悪意あるスキルは受け取らないキーを抽出できない。

原則3：ジャストインタイムアクセス

CyberArkのフレームワークはAIエージェントをアイデンティティとして扱う——ビルへのアクセスが必要な従業員のように。核心的な洞察：永続的な認証情報を渡さない。一時的なものを渡す。

ジャストインタイム（JIT）アクセスの仕組み：

1. エージェントがリソースへのアクセスを必要とする
2. エージェントがガバナンスサービスに権限を要求
3. 承認されると、エージェントが一時トークンを取得（数分で有効期限切れ）
4. タスク完了後にトークンが自動的に無効化

個人使用では以下に変換される：

• すべてのAPIキーを常時有効にしない。 エージェントを積極的に使用していない時はキーを無効化する。
• トークンローテーションを使用。 エージェントのトークンが侵害された場合、短寿命トークンが露出ウィンドウを限定する。
• アクティブセッションを確認。 定期的にどのトークンがアクティブか確認し、認識できないものは無効化する。

✅ Quick Check: 1週間の休暇に行くのでAIエージェントを使わない。認証情報はどうすべきか？（答え：すべてのアクティブトークンを無効化または取り消す。戻ったら新しく作成。1週間のアイドル認証情報は、いずれかが侵害されていた場合1週間の露出。JITアクセスは認証情報が必要な時だけ存在することを意味する。）

原則4：アクション許可リスト

エージェントがツールを責任を持って使うと信じる代わりに、使えるツールを正確に定義する：

# デフォルト拒否：明示的に許可されたツールのみ使用可能
allowed_actions:
  - read_file
  - write_file
  - web_search

# 明示的にブロック（allowed_actionsがより広い場合でも）
blocked_actions:
  - shell_execute
  - delete_file
  - send_email
  - browser_control

Auth0のセキュリティガイドは「高リスクアクションにデフォルト拒否：シェル実行、ブラウザ制御、再帰的削除」を推奨。エージェントは明示的にその必要性を決定しない限り、シェルコマンドを実行できるべきではない。

これはレッスン2の脅威モデルのOWASP A1（ツール悪用）とA2（過剰なエージェンシー）に直接接続する。許可リストがそれらの制御の実装。

粒度のスペクトラム：

許可リストレベルから始める。機密なデプロイメントにはアクションレベル制御に移行。

すべてをまとめる

4つの原則を組み合わせた権限境界設定：

1. スコープ付きトークン： 1つのプロジェクトへの読み取り専用アクセスを持つエージェント固有APIキー

2. 認証情報分離： APIキーはプロキシに保管、エージェントはそれを見ない

3. JITアクセス： トークンは4時間で有効期限切れ、エージェントがアクティブな場合のみ自動更新

4. アクション許可リスト： ファイル読み書きとWeb検索のみ許可；シェル、メール、ブラウザは不可

この設定で影響範囲が劇的に縮小する。悪意あるスキルがエージェントを侵害した場合：

• 認証情報を取得できない（分離）
• シェルコマンドを実行できない（許可リスト）
• 1つのプロジェクトディレクトリにしかアクセスできない（スコープ付きトークン）
• トークンは数時間で期限切れ（JIT）

デフォルトと比較：攻撃者が個人APIキー、完全なシェルアクセス、すべてのファイル、永続的な認証情報を取得。

Key Takeaways

• エージェントにはあなたのアクセス権がある——侵害されたエージェントはあなたが侵害されたこと
• スコープ付きトークンが影響範囲を限定：エージェント固有、読み取り専用、プロジェクト固有
• 認証情報分離でエージェントが生のシークレットに触れない——プロキシまたはシークレットマネージャーを使用
• ジャストインタイムアクセスで認証情報は必要な時だけ存在——アイドル時は無効化
• アクション許可リストでエージェントが使えるツールを正確に定義——シェル、メール、ブラウザはデフォルト拒否
• 4つを組み合わせて多層防御：1つの層が破られても他が被害を封じ込める

Up Next

レッスン5：スキルの審査——あなたが審査される前に——エージェントはコンテナ化（Docker）され、制約（権限）されている。しかしインストールするスキルはどうか？1つの悪意あるスキルがすべての慎重な設定をバイパスできる。安全なスキルとトロイの木馬を見分ける5ポイント審査フレームワークを学ぶ。