開発者は、カスタマーサポートからインフラストラクチャ管理まで、あらゆるものを自動化するAIエージェントを驚異的なペースで構築しています。これらのAIエージェントは非常に堅牢で、E メールの読み取り、本番データベースへのクエリ、さらにはサーバーのデプロイまで実行できます。AIマシンの性能は進化している一方で、それを保護する方法は進化していません。
現在、ほとんどのAIエージェントは、広範かつ長期的な許可を持つ静的なAPIキーを使用して運用されています。つまり、攻撃者がプロンプトインジェクションを介してエージェントを操作すると、管理者のキーを奪われる可能性があります。このセキュリティモデルは時代遅れであり、ゼロトラストのまさに中核となる原則に反しています。
まず、AIエージェントが個別のアイデンティティを必要とする理由を説明し、次にモデルコンテキストプロトコル（MCP）を実装してAIエージェントに最小権限アクセスを付与し、承認された場合にのみAIエージェントが動作するようにする方法を解説します。
「スーパーユーザー」問題
この10年間、人間がパスワードを共有する慣行からの脱却に取り組んできたにもかかわらず、AIエージェントに対しては、ハードコードされたシークレットを付与してスーパーユーザーのように扱うことがよくあります。静的APIトークンをエージェントの環境変数に直接挿入すると、大きな攻撃対象領域が生まれます。このトークンにはコンテキストがありません。システムはAPIトークンが使用されたことは認識しますが、エージェントがトリガーされた理由や実行者は認識しません。
エージェントはハルシネーション（幻覚）を起こしたり、操作されたりする可能性があります。そうなると、追跡が困難なアクションを実行する可能性があり、Application （アプリケーション）全体を破損させることなくアクセス権の取り消しはさらに難しくなる場合があります。この問題を解決するには、人間の従業員に適用するのと同じアイデンティティファーストの考え方でAIエージェントを扱う必要があります。
「ローテーション」という悪夢
正直なところ、静的キーのローテーションは管理が非常に煩雑なため、本来あるべき頻度では誰も実行していません。
単一のOKTA_API_TOKENが3つの異なるマイクロサービス、CI/CDパイプライン、およびローカルの.envにハードコーディングされている場合テスト用のファイルの場合、そのキーをローテーションしてもセキュリティタスクにはならず、停止を待つだけです。これを正しく行うには、新しいキーを生成し、古いキーを使用しているすべてのリポジトリを検索し、すべてのサービスを再デプロイしたうえで、どこかのレガシーサーバーで実行されている小さなcronジョブを1つも見逃していないことを祈るしかありません。
このプロセスは多大な労力を要するため、チームは先延ばしにしがちです。本番環境のキーが何年もローテーションされていないのを見たことがあります。キーを作成した元の開発者が退職してしまい、誰もキーを変更してビルドを壊したくないからです。これにより、脆弱性が存在する期間が非常に長くなります。キーが漏洩した場合、攻撃者は、お客様が慌ててキーをローテーションするまで永続的なアクセス権を保持します。
ソリューション：「on-behalf-of」フロー
この新しい自動化の波を保護するには、静的なキーから動的なトークン交換（RFC 8693で定義）に移行する必要があります。アイデンティティアーキテクチャでは、これをOn-Behalf-Of（OBO）フローと呼びます。この場合、エージェントは「神モード」の管理者としてではなく、代理人として機能します。ユーザーがエージェントに何らかの操作を依頼すると、エージェントは自身を認証しますが、その特定のユーザーに代わって操作するための許可を要求します。
これには、2つの主要なコンポーネントが必要です。
- 標準プロトコル：AIがリクエストを標準化する方法が必要です。そこで登場するのがモデルコンテキストプロトコル（MCP）です。
- アイデンティティのアサーション：ユーザーのセッションを、エージェント用の一時的な、スコープが限定されたアクセストークンと交換する方法が必要です。
Model Context Protocol（MCP）の実装
では、このパターンを実際に実装する方法を見ていきましょう。このため、オープンソースのOkta MCP Serverを使用して、LLM（Github CopilotやClaudeなど）とお客様のアイデンティティプロバイダー（IdP）間の接続を処理します。
ステップ1：静的シークレットを削除する
まず、エージェントのコードを監査します。このためには、OKTA_API_TOKENなど、有効期間の長いシークレットを格納している環境変数をすべて特定し、削除します。動的エージェントに静的キーを使用することは、セキュリティの観点から見ると、銀行口座のパスワードを臨時の契約社員と共有するのと同じことです。エージェントがアイドル状態のときに権限を一切持たないようにすることが目標です。
ステップ2：スコープ付き権限を構成する
各IdPで、このエージェントを個別のApplication （アプリケーション）として登録します。これにより、何ができて何ができないかを正確に定義できます。読み取り/書き込みアクセス権を付与する代わりに、きめ細かいスコープを使用してみてください。例えば、users.deleteのような明示的な権限を付与するべきではありません。Oktaでは、これはクロスアプリアクセス（XAA）を介して処理されます。これにより、これらの特定の許可をエージェント固有のclient IDにバインドできます。
ステップ3：トークン交換
次に、ユーザーがエージェントにプロンプト（例：「パスワードをリセットして」）を送信した際の技術的なフローを見ていきましょう。
- トリガー：ユーザーがIDEまたはチャットインターフェイスを介してエージェントにプロンプトを送信します。
- ハンドシェイク：その後、エージェントは標準プロトコルを使用してMCPサーバーに接続します。
- エクスチェンジ：サーバーがリクエストをインターセプトし、アイデンティティのアサーションを実行します。IdPに対して「私はパスワードリセットのエージェントです」と伝えます。User-Xが私を認証しました。5分間有効なトークンをください。
- アクション：IdPは、パスワードリセットという特定のタスクにのみ有効な、有効期間の短いトークンを発行します。
結果：監査対応エージェント
このアーキテクチャーを実装すると、曖昧なログが明確なスタックトレースに変わります。
汎用的なシステムアクションを表示する代わりに、Oktaのログには以下が表示されます。
「パスワードリセットエージェントがユーザーXに代わってパスワードAPIにアクセスしました。」
このようにきめ細かく可視化することで、セキュリティチームは、通常の従業員と同様にAIエージェントのアクセスレビューを実行できます。何らかの理由でAIエージェントが不審な動作を開始した場合でも、エンジニアリングチーム全体のキーをローテーションすることなく、その特定のアクセスポリシーを即座に取り消すことができます。
静的なキーから、セキュアな自律性へ
AIエージェントが進化し、より自律的になるにつれて、2015年にcronジョブで使用していたような旧式の静的キーでセキュリティを確保するわけにはいきません。
Model Context Protocolとアイデンティティ アサーション（XAA）を導入することで、有用かつ有能で、そして最も重要なこととして、セキュアなAIエージェントを実現できます。
構築を始める準備はできましたか？オープンソースのOkta MCP Serverをご確認ください。このリファレンス実装は、AIエージェントとIdPの間の橋渡しとなり、安全な代理（on-behalf-of）でのトークン交換を可能にします。
