業務を任せたAIエージェントが、許可していないシステムに接続しようとしたとき、どの製品が異常を検知し、誰が止めるのでしょうか。企業がAIエージェントを本番環境へ移す際には、導入時の審査に加え、動いている最中の振る舞いを管理する仕組みが必要です。OktaがBlueprint Allianceを通じて示したのは、その役割分担を複数ベンダーで共有するための参照アーキテクチャです。

ID・アクセス管理を手がけるOktaは、既存のエージェント向けセキュリティフレームワークを、複数ベンダーが関わる共通の設計へと発展させました。参照アーキテクチャとは、必要な機能や機能同士の関係を整理した設計のひな型です。完成済みの単一製品というより、企業が自社の環境に合わせて構成を検討する際の土台と理解すると分かりやすいでしょう。



Oktaの社長兼最高執行責任者であるエリック・ケレハー氏は、同社のイベント「Oktane」で、企業がベンダーの説明を比較する難しさに触れました。技術基盤の各領域を担うベンダーが、それぞれ自社で問題を一括解決できると訴えるため、購入側は安全管理の全体像をつかみにくくなるという指摘です。今回の取り組みには、その混乱を整理する狙いがあります。

企業の導入判断で焦点になるのは、採用する製品の数だけではありません。エージェントの存在を把握する機能、権限を管理する機能、挙動を観測する機能、問題に対処する機能が、実際の運用でつながるかどうかです。共通設計の価値は、この一連の流れについて担当範囲や連携の不足を確認しやすくする点にあると考えられます。

Blueprint Allianceの設計は、エージェントの安全管理を四つの問いに整理しています。「どこにいるか」「何ができるか」「何をしているか」「どう対応するか」です。専門製品の機能名から検討を始めるよりも、この四つに沿って自社の管理状況を確かめるほうが、運用上の不足を具体的に捉えやすいでしょう。

「どこにいるか」は、管理すべきエージェントの所在や存在を把握する問いです。対象が分からなければ、権限の確認も監視も始められません。「何ができるか」では、どのシステムへの接続や操作が認められているかを確認します。ここで扱うのは、実行した行動そのものではなく、事前に認めた活動範囲です。



「何をしているか」は、稼働中の行動を観測する問いです。許可された範囲が分かっていても、実際の接続や操作が見えなければ、その範囲を守っているか判断できません。「どう対応するか」では、観測した行動とリスクに応じて、停止や動作の修正などを選ぶことになります。把握と監視だけで完結させず、対処まで設計に含めている点が実務上の要点です。

例えば、ある業務システムへの接続権限をエージェントに与える場面を考えてみます。権限の設定を確認するだけでは、そのエージェントが別の接続先を探していないかまでは分かりません。接続の記録を集めても、許可された接続先の一覧がなければ、記録の意味を評価しにくくなります。これは説明のための例ですが、四つの問いが互いに依存していることを示しています。

日本企業での検討にも、この整理は応用できます。各問いについて、確認に使う情報、管理する部署、判断する責任者を書き出せば、製品名の比較だけでは見えにくい課題を洗い出せるはずです。特に「検知した後に誰が動くか」が空欄になっていないかは、早い段階で確かめたい項目です。

ケレハー氏が説明した連携の中心は、IDに関する情報と、端末やネットワークから得られる観測情報の組み合わせです。Oktaは、エンドポイントやネットワークのテレメトリーに、自社のID関連の情報を重ねるとしています。テレメトリーとは、システムの状態や動作を継続的に収集する情報を指します。ここでは、エージェントの実際の活動を知るための手掛かりと捉えるとよいでしょう。

具体的には、エージェントが接続している先を調べ、接続を許可されたシステムと比較して、食い違いがないかを確認します。そのリアルタイムの情報をシステムへ戻し、不審な兆候の特定に役立てるという説明です。「接続が発生した」という記録に、「その接続は認められているか」という文脈を加える仕組みです。



一般に、接続の記録だけを見ても、業務上必要な通信なのか、許可範囲を外れた通信なのかは判断しきれません。逆に、権限の設定だけを確認しても、稼働中に何が起きているかは把握できないでしょう。両方を対応付けることで、設定と行動の間にあるずれを検討できるようになります。

この考え方を実装する際には、情報を集めることに加え、それぞれの記録が同じエージェントのものだと識別できることも必要です。これは連携設計における一般的な確認事項であり、今回の発表で個別の実装方法まで明らかになったわけではありません。企業側は、利用する製品の間で識別情報をどう対応付けるか、必要な記録が取得できるかを確認する余地があります。

また、許可範囲との食い違いは調査や対処の手掛かりですが、その発見だけで原因まで確定するとは限りません。業務上の意図や設定内容を踏まえた判断が必要になる場合もあります。検知の仕組みを評価するときは、警告を出せるかに加えて、判断に必要な情報が担当者へ届くかを見ることが実務的です。

エージェントを「止める」と説明されても、停止できる範囲は一つではありません。Oktaは、不審と判断されたエージェントを無効化し、新しいセッションを開始できなくすることが可能だとしています。そのうえで、Agent Gatewayにおけるキルスイッチ機能を拡張し、有効なトークンやセッションを失効させる計画を示しました。現在説明されている機能と、今後の拡張計画を分けて把握する必要があります。

セッションは、認証後に接続や操作を続けるためのやり取りのまとまりです。トークンは、システムへのアクセス時に権限などを示すために使われる情報です。新しいセッションの開始を禁止することと、すでに成立しているアクセスを使えなくすることでは、制御の対象が異なります。



例えば、入館証の新規発行を止めることと、すでに発行した入館証を使えなくすることを考えると、違いをイメージしやすいでしょう。ただし、デジタルな認証では、停止の指示がいつ、どの接続先で有効になるかは構成に左右されます。この例は制御対象の違いを説明するもので、Oktaの個別機能の動作をそのまま表すものではありません。

企業が調達や検証で確認したいのは、「キルスイッチがある」という名称だけでは判断できない部分です。新規接続を防ぐのか、既存のセッションにも作用するのか、どのシステムまで制御が届くのかを明確にする必要があります。今回示された拡張計画についても、実際の導入判断には提供状況や適用範囲の確認が欠かせません。

停止という言葉の解釈が部署間で異なると、運用担当者は遮断済みと考えていても、別の担当者が想定した範囲には対処できていない可能性があります。検証時には、問題の検知から対処までの流れに加え、対処後にどのアクセスが利用不能になったかを確認する設計が有効です。停止指示の実行と、その結果の確認を一組で扱うことが求められます。

ケレハー氏は、エージェントの振る舞いと、それがもたらすリスクによって適切な対応が変わると説明しています。エージェントが意図された仕事を進めようとする過程で、想定していなかった境界を越える場合もあり、その際には行動を修正して許可された範囲へ戻す対応が必要になるという見方です。安全管理には、異常を見つける技術とともに、介入の強さを選ぶ設計が含まれます。

ここでいう実行時、あるいはランタイムの安全管理は、エージェントが動作している間の状態や行動を対象にします。導入前にルールや権限を決めておく作業とつながっていますが、それだけで運用が完了するわけではありません。実際に起きたことを観測し、必要に応じて対処する流れが加わります。



企業の運用設計としては、軽微な逸脱と、機密情報への不適切なアクセスにつながり得る行動とでは、対応を分けて検討する余地があるでしょう。これは今回示された考え方から導ける運用上の例であり、具体的な判定基準が発表されたという意味ではありません。何を許容し、どの条件で停止するかは、対象業務や扱う情報に応じて決める必要があります。

すべての警告に対して停止を選べば、業務が中断しやすくなる可能性があります。反対に、処理の継続を優先しすぎれば、許可範囲を外れた行動への介入が遅れかねません。両者のバランスを現場の担当者だけに委ねず、業務責任者とセキュリティ担当者が、判断の基準を共有しておくことが望まれます。

動作を修正して継続させる場合にも、修正後に許可範囲へ戻ったことを確かめる必要があります。警告への対応を記録し、その後の観測につなげる運用であれば、同じ問題が繰り返されていないかも検討できます。対処を一度実行して終えるのではなく、その効果を確認できることが、稼働中の安全管理を支える条件です。

今回の取り組みを日本企業の導入検討に置き換えると、最初の作業は、自社で使うエージェント一つについて管理の流れを具体化することです。対象業務、接続先、許可する操作、観測できる情報、問題発生時の対処を同じ資料にまとめるところから始められます。全社の構成を一度に整理しようとするより、実際の利用場面に沿って不足を確認しやすいでしょう。

例えば、社内情報を参照するエージェントを検討するなら、読み取りを許可する範囲と、更新などの操作を許可する範囲を明確にします。これは特定の製品に備わる機能の説明ではなく、権限を整理する際の一般的な考え方です。接続先の名称だけを列挙せず、その場所で何を認めるかまで決めることで、後から実際の行動と比較する基準を作れます。



その資料を使い、ベンダーには自社製品が担う範囲と、他の製品から受け取る必要がある情報を示してもらうと有効です。検知を担う製品と、アクセスを遮断する製品が異なる場合は、両者の間で何を受け渡すのかも確認対象になります。参照アーキテクチャは検討の共通言語になりますが、存在するだけで自社環境の連携が保証されるものではありません。

調達の観点では、複数ベンダーが役割を共有する設計が広がれば、個々の機能の多さに加えて、製品間で情報や対処をつなげる能力が評価される可能性があります。ただし、今回の情報だけで導入効果や運用負荷を数値化することはできません。企業側は、検知から判断、対処までを実際に試せるかを、評価の一つの軸に据えるとよいでしょう。

着手する際は、本番利用を予定しているエージェントを一つ選び、「許可していない接続先へアクセスを試みたら」という場面を関係部署で確認してください。誰が検知し、何を根拠に判断し、どのアクセスを止め、誰が結果を確認するかまで回答をそろえます。回答が曖昧な箇所を埋めることが、今回の共通設計を自社の運用へ落とし込む具体的な一歩です。

Okta builds shared architecture for agent runtime security

ケレハー氏の説明は、Oktaのイベント「Oktane」で行われた、SiliconANGLE Mediaの配信番組theCUBEによるインタビューに基づきます。theCUBEは同イベントの有料メディアパートナーです。SiliconANGLEは、Oktaを含むスポンサーがtheCUBEやSiliconANGLEのコンテンツに対する編集権を持たないと明記しています。