AIエージェントを導入している多くのチームは、意識的に選択したわけではないセキュリティのトレードオフを行っています。エージェントにはサービスアカウント、あるいは共有APIキーが与えられました。これらは、ジョブの実行に十分なアクセス権を持ち、構成ファイルまたは環境変数に保存されていました。なぜなら、すべてが順調にいっているからです。エージェントが適切なAPIを呼び出し、デモはクリーンに実行され、プロジェクトは出荷されます。
実際には、サービスアカウントの問題を再現しているにすぎません。ただし、今回はプリンシパルが自律的に、かつ高速で動作し、その「判断」はプロンプトで読み取るあらゆるテキストに影響される可能性があります。
AIエージェントのアクセスを管理することは、新しいツールを必要とする新しい問題ではない、という具体的な主張をしたいと思います。既存の特権アクセス管理（PAM）ツール、すなわちジャストインタイム（JIT）アクセス、セッションレコーディング、最小権限の適用、監査証跡はすべて、その重要性が低下するどころか、むしろ高まっています。その代わりに進化させるべきなのはアイデンティティモデルであり、その進化は、どのPAMアーキテクチャが実際にその役割を果たせるかに影響を及ぼします。
エージェントをサービスアカウントのように扱うことの問題点
サービスアカウントは静的なアイデンティティです。認証情報と権限を持っており、何か問題が発生した際には、どのアカウントが何を行ったかを監査ログが示します。修復方法は明確です。認証情報をローテーションし、権限のスコープを縮小して、次に進みます。
AIエージェントは、異なる種類のプリンシパルです。サービスアカウントのモデルにうまく適合しない理由がいくつかあります。
人間の代理として動作します。
貴社のセキュリティオペレーションセンター（SOC）のアナリストがエージェントに本番サーバーの調査を依頼した場合、エージェントは自己判断で行動しているのではなく、特定の人物からの指示を実行しています。その人のアイデンティティはアクセスレコードに含まれているはずです。サービスアカウントには、そのようなコンテキストは含まれません。「エージェントがサーバーにアクセスした」という記述は、「JasonがMFAを完了した後、午後6時51分に開始したセッションに続いて、Jasonのエージェントがサーバーにアクセスした」という記述よりも具体性に欠けます。
その命令は操作される可能性があります。
サービスアカウントは、そのコードに指示されたとおりに動作します。AIエージェントは自然言語を処理するため、十分に練られたプロンプトがあれば、ほとんどすべてのことを妥当な次のステップであるかのように見せかけることが可能です。サービスアカウントを保護するセキュリティ境界（コード自体）は、同じ方法では適用されません。このソリューションでは、意図を評価せず、操作された入力によって無効化されることのないエンフォースメントレイヤーをエージェントの周囲に追加します。
大規模な環境では、静的な認証情報が単一障害点となります。
エージェントが増殖するにつれて、共有認証情報を使用するエージェントが増えるごとに、その影響範囲は拡大します。設定ファイルが1つ侵害されると、1つのサービスが危険にさらされるだけではありません。その認証情報がアクセスするすべてのシステム、およびその認証情報を使用するすべてのエージェントが危険にさらされます。
その答えは、巧妙なエージェントフレームワークや新しい種類のAPIキーではありません。これは、PAMが人間のPrivileged Accessに対して提示したのと同じ答えです。つまり、永続的な認証情報を一切発行しないということです。アクセス権をジャストインタイムで発行し、セッションにスコープを限定して、実行内容を記録します。セッションが終了すると、盗むべきものは何も残りません。
AIエージェントの実践的なガバナンス：SOCワークフローのユースケース
今年の初めに、AIを活用したSOCワークフローの実用的なデモを構築しました。このデモでは、セキュリティアナリストがチャットインターフェイスを使用してエージェントに指示を出し、当社のラボインフラストラクチャで実行されている本番サーバーを調査することができました。エージェントは本番環境に対する永続的な認証情報を持っていませんでした。
セッションをエンドツーエンドで記録しました。アナリストがセッションを開始したときに発生した一連のイベントは、次のとおりです。
- アナリストはOktaとMFAで認証を行いました。これはサービス トークンではなく、実際のアイデンティティ アサーションです。
- エージェントはOAuth 2.0トークン交換（RFC 8693）を実行しました。これは、人間のアイデンティティ（sub = firstname.lastname@com.com）とエージェントのアイデンティティ（cid = ag_ir_forensic_7f3a2）の両方を含むトークンを生成する委任ステップです。両方が存在し、どちらも省略されていません。このトークンが存在するためには、人間の介在が不可欠でした。
- Okta Privileged Access（OPA）は、設定済みのワークロードコネクターとポリシーに対してトークンを検証し、エージェントがこれらの条件下でこのクラスのサーバーにアクセスする権限を持っていることを確認しました。
- OPAはPAMクライアントを介して短期間有効なSSH証明書を発行しました。このクライアントは暗号化されたペイロードを受信し、OPAゲートウェイを介して接続を仲介し、そこで復号を処理しました。エージェントは、読み取り可能な認証情報を保持しませんでした。
- エージェントはOkta Privileged Accessゲートウェイ経由で接続しました。これが本番環境への唯一のネットワークパスです。本番ホストはエージェントのコンピューティングから直接アクセスできませんでした。ゲートウェイが唯一のブリッジであり、ポリシーに準拠したセッションのみがアクセスできました。
アナリストのブラウザから本番サーバー上のセキュアシェルに接続するまでの合計経過時間：37秒。
エージェントは最初のコマンドでリバースシェルを検出し、rootとしてncを実行し、外部IPにコールバックしました。これがユースケースです。高速で、管理され、完全に監査されます。
AIエージェントのスタンディング特権をJITアクセスで排除する方法
そのフローには、詳しく見ていく価値のある点がいくつかあります。まず、ここでのJITアクセスは2つのレベルで機能します。
- OPAは、このセッションをスコープとするエフェメラルSSH証明書を発行しました。
- OPAはまた、このセッションのために本番ホスト上にローカルOSアカウントをプロビジョニングし、セッション終了時にそのアカウントを削除しました。ホスト上に、侵害されるのを待っている永続的なアカウントはありませんでした。
ランタイムsudoポリシーによる最小権限の適用
ランタイムのsudo強制は、本番環境のエージェントに関してほとんどの人が実際に恐れている問題に対処するコントロールとして、特筆に値します。その問題とは、エージェントが暴走してデータベースを削除したり、ファイルを上書きしたりするといった、まことしやかに語られる話のことです。これらのシナリオには書き込みアクセスが必要です。当社のフォレンジックエージェントは本番環境へのアクセスを必要としましたが、読み取り専用モードで動作していました。OPAの一元管理されたsudoポリシーによって、OSレベルでそれが強制されました。これは、システムプロンプトやアプリケーションロジック、あるいは何が適切かというエージェント自身の判断によるものではありません。
しかし、このポリシーは破壊的な行動をブロックするだけではありませんでした。これにより、このエージェントが実行すべきであった特定の境界が強制されました。これは、読み取り操作においても重要です。テストでは、LLM自身の推論によって、エージェントが/etc/shadowを読み取るように求めるリクエストが確実に検出されました。ソフトバウンダリーが維持されたことは十分に明らかでした。
ただし、エージェントにプロセスのメモリーマップを分析させるのは別の話でした。そのリクエストはフォレンジック的に妥当で破壊的ではなかったため、エージェントの推論レイヤーは数回試行した後、その実行に同意しました。OPAのsudoポリシーによって、いずれにせよブロックされました。重要なのは、LLMが失敗したことではなく、ポリシーがLLMの正誤に依存しないことです。sudoバンドルを構築した担当者は、SOCアナリストがアクセスすべき対象とすべきでない対象を慎重に検討しました。その判断は、エージェントが合理的であると判断したものに関係なく、ランタイムに適用されます。
PAM監査ログ全体にわたるヒューマンアイデンティティの関連付け
ここでも監査証跡が重要になります。Okta System Logには、アナリストのSSOログインから本番サーバーへのSSHログインまで、そのセッションに関する7つのイベントが記録されています。すべてのイベントがリンクされています。人間のユーザーIDは、チェーン全体にわたって存在します。
PAMイベントのWorkloadPrincipalは、単なる「エージェント」ではなく、opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com（このエージェントを所有するチーム、実行されたポリシーコンテキスト、およびそれを承認した担当者）です。3つすべてを1つのPAMログフィールドに。その担当者のEメールがPAMレコードに記録されているのは、そのEメールがトークンに含まれており、そもそもそのアナリストを認証したのと同じアイデンティティシステムから取得されたものであるためです。
それがアカウンタビリティの重要性です。「エージェントがサーバーにアクセスしました」ではなく、「Firstnamesのエージェントがサーバーにアクセスしました。使用された証明書、セッションレコーディング、それを認可したチェーン内のすべてのトークンは次のとおりです」となります。
IdP基盤がオプションではない理由
PAMベンダーを評価するセキュリティアーキテクトの皆様に、ここでさらに踏み込んだ議論をしたいと思います。
多くのエンタープライズPAMベンダーは、JSON Web Token（JWT）認証をサポートしています。多くの製品がJWT/OIDC認証をサポートしており、クレームをポリシーにマッピングできます。これは機能しますが、「JWTの受け入れ」と「アイデンティティのネイティブな理解」は同じではありません。
When the アイデンティティプロバイダー (IdP) and PAM are the same Platform, a few things are structurally different:
- エージェントの登録はIdP内に存在します：OPAのワークロードコネクターは、エージェントの
cidにバインドされます。これは、ポリシー構成ファイル内の文字列ではなく、登録済みプリンシパルへのライブ参照です。Oktaでエージェントのプロビジョニング解除すると、アクセス権の取り消しが行われます。 - 監査証跡は単一のストリームです：アナリストのSSOイベント、トークン付与、PAM資格情報の発行、SSHログインのすべてがOkta System Logに記録され、まとめてクエリを実行できます。別のPAMベンダーを利用する場合、2つの監査システムを結合して何が起こったかを再構築する必要があります。
- PAMレコード内の人間のアイデンティティは、ハンドオフ後も維持されるマッピングされたクレームではありません。これは、チェーンの開始時に認証されたものと同じアイデンティティであり、Platformの信頼境界から出ることはありません。
人間による特権アクセスの場合、IdPとPAMの統合は、PAMコンソールでのSSOやSCIMプロビジョニングを可能にするため便利でした。ただし、AIエージェントのアクセスに関しては、アーキテクチャ上の問題となります。アカウンタビリティの確保は、認証から委任、アクセスに至るまで、人間のアイデンティティが損なわれずに伝達されるかどうかにかかっています。アイデンティティが信頼境界を越えるたびに、失われたり、誤ってマッピングされたり、単にログに記録されなかったりする可能性があります。
そのアーキテクチャ上の懸念は、特権付きインフラストラクチャアクセスだけに当てはまるものではありません。
上記のSOCワークフローは、より広範なアーキテクチャの一つの表現であるため、一度限りの統合ではありません。Okta for AI Agentsは、エージェントを導入するすべてのセキュリティチームが直面する3つの問いに答えます。「エージェントはどこにあるのか」、「何に接続できるのか」、「何ができるのか」という問いです。
Okta Privileged Accessは、本番環境のインフラストラクチャ、機密システム、そして侵害または不正操作されたエージェントが深刻な損害をもたらす可能性のあるあらゆる場所など、最もリスクの高いターゲットに関する3つ目の問いにOktaがどう答えるかを示すものです。OPAフローにおける（人間、エージェント）のペアを管理する原則（すべてのアクションに対するユーザーコンテキストへのバインド、最小権限スコープ、エフェメラル資格情報、不変の監査証跡）は、MCPサーバー、SaaS API、エージェント間の呼び出し、認証情報を使用するサービス接続にも同様に適用されます。本番サーバーへのエージェントによるアクセスは、まさに失敗の代償が最も高くつくケースです。そのため、エージェント数が手に負えなくなる前に、IdPとPAMの基盤を確立しておくことが重要になります。
まとめ
AIエージェントは、エンタープライズインフラストラクチャにおける新しい特権付きプリンシパルです。脅威モデルは、永続的な認証情報、過剰な権限を持つアカウント、監査証跡の欠如といった、よく知られたものです。エージェントとの違いは、これらの問題がより迅速に発生し、検知がより困難であるという点です。
PAMを構成する基本要素（JITアクセス、セッションレコーディング、認証情報ボールト、ポリシー適用、特権昇格制御など）は、プリンシパルがAIであってもその重要性が薄れることはありません。そもそも、エージェントアクセスを安全に導入できるようにするものがこれです。
進化する必要があるのは、アイデンティティモデルです。プリンシパルは（人間、エージェント）のペアになりました。両方のアイデンティティがレコードに含まれている必要があります。「このエージェントは誰のもので、誰が承認したのか」といった事後のアカウンタビリティの再構築。プラットフォームは、2つのシステムにまたがるログからペアを再構成するのではなく、最初からそのペアを理解する必要があります。
現在のPAMアーキテクチャがエージェントアクセスをサービスアカウントの問題として扱っている場合、そのアーキテクチャが、プリンシパルが2つのアイデンティティを持ち、自律的に動作し、実行を依頼された内容についてプリンシパルの言葉を鵜呑みにしない管理システムを必要とする世界を想定して設計されたものかどうかを問う価値があります。
本資料は一般的な情報提供のみを目的としたものであり、法務、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言を目的としたものではありません。© Okta, Inc. and/or its affiliates.
