エージェント型エンタープライズのセキュリティ保護：実践的なブループリント

エージェントは強力です。それらは攻撃対象領域でもあります。

AIエージェントは、アクセスを許可されたシステムにおいてのみ、その真価を発揮します。有用なものは、SaaSコネクター、モデルコンテキストプロトコル（MCP）サーバー、APIを介して、最も慎重に保護されているシステム内で、返金の承認、取引の転記、顧客レコードの変更を行っています。

エージェントがアクションを実行するには、これまで対話したことのないシステムから、誰かの代理として、人間がその決定の瞬間を監視することなく信頼される必要があります。監視下にある単一のエージェントは、理解と制御が容易です（図1）。

エージェントがパイロット段階から本番環境に移行し、全社的に導入が拡大するにつれて問題が発生し始めます。1つの監視された接続が、数千の監視されていない接続へと変わります。それぞれに付与される権限は一度だけ、かつ広範に設定されるため、アクセスが混沌とした状態になります（図2）。

1つのエージェント。多数のツールとリソース。

すべてのリンクは、顧客データ、IP、そしてビジネスを動かすオペレーティングシステムにつながっています。

ユーザー × エージェント × 会話 × ツール = アクセスのカオス

すべてのリンクが攻撃対象領域となります。認可は、マシンレベルのスピードですべてのコールを個別に管理する必要があります。

その混沌は一見セキュリティ脅威のように見えますが、通常の脅威とは異なる形で現れます。エージェントは、外部から侵入してくるわけではありません。正当な手続きによって作成され、接続され、アクセス権を与えられます。そのため、トラフィックがファイアウォールに到達する頃には、エージェントはすでに内部に侵入しているのです。

本当の問題は、次に何が起こるかということです。

• これはどのエージェントですか。
• 誰が承認しましたか。
• 何にアクセスできますか。
• このタスクで何ができますか。
• そのアクセスを取り消すにはどうすればよいですか。

これらはアイデンティティと認可に関する問題であり、大まかなスコープは事前に決定できますが、前もって回答することはできません。タスクごとの決定は、ランタイム時に行う必要があります。エージェントの権限は、アクションの実行時に、人間とエージェント両方のアイデンティティに基づいて決定される必要があります。これにより、タスクに合わせて認可のスコープが正確に設定され、すべてのリクエストに責任のある担当者が紐付けられます。この中心的な原則が、アーキテクチャ全体の基盤となります。

セキュリティの青写真はすでに存在しています。予算はそうではありません。

すでに最先端の現場では、この変化の兆しが目に見える形で現れています。たとえばUberは最近、AIエージェントに「本物のアイデンティティ」を付与した具体的な取り組みを公開しました。同社が最終的に行き着いたのは、暗号化されたエージェントアイデンティティと、リクエストを発した人間から最終的なツールに至るまでの「アクターチェーン（実行主体の連鎖）」を確実に引き継ぐ、ホップごとのトークン交換（per-hop token exchange）というアーキテクチャです。これは、私たちが直面している課題が現実のものであり、その解決策となるアーキテクチャが実現可能であることの強力な裏付けとなります。しかし同時に、この仕組みは、大半の企業には到底望めないようなエンジニアリング組織が、自社内で構築・運用した結果でもあるのです。

得られるべき教訓は標準に関するものです。つまり、エージェント用のアイデンティティレイヤーは、エージェントが常に越えているベンダーやSaaSの境界を越えて機能する場合にのみ意味を持ちます。これは、すべての関係者が同じ方法で実装する一貫した標準を使用して構築し、会社概要ごとに設計するのではなく、積み重ねるとして提供する必要があることを意味します。それがOkta for AI Agentsです。

Oktaがエージェント型エンタープライズのセキュリティを確保する方法

Okta for AI Agentsは、その原則をオペレーティングレイヤーに変えます。つまり、すべてのエージェントに検証可能なアイデンティティを提供し、アクションの瞬間に認可を決定し、説明責任を負う人間をチェーン全体で引き継ぎます。この記事の残りの部分では、あるエンタープライズを例に、そのアーキテクチャについて順を追って説明します。

一般的なエージェント型エンタープライズの実装

この仮説を具体的に説明するために、当社が協業しているエンタープライズを統合した架空の企業、Streamward Inc.を例に挙げます。ユーザーがチャットアシスタントを介してリクエストを行うと、マスターエージェントオーケストレーターがその意図を解析し、事業能力に応じてメッシュ全体にサブタスクを委任します（図3）。エージェントは、ダウンストリームシステム、独自のAPI、サードパーティのサービスにアクセスするために、MCPサーバー、OpenAPI仕様で管理されるRESTエンドポイント、ネイティブクラウドデータウェアハウスといった、さまざまなランタイムリソースタイプを組み合わせて使用します。

マルチエージェントメッシュアーキテクチャのサンプル

• Salesforce Agentforce：CRMパイプライン分析、お客様スコアリング、アカウント検索を処理します。
  • 接続されたMCPサーバー：基幹ERP MCPサーバーを介してget_customer_payment_historyを呼び出し、SalesforceのアカウントIDとリアルタイムの請求情報を相互照合します。
• Amazon Bedrock AgentCore：企業のナレッジベースでRAG（Retrieval-Augmented Generation）を実行します。
  • 接続済みMCPサーバー：MCPを介してAWS Aurora PostgreSQLベクトルデータベースに接続し、query_knowledge_baseとfetch_unstructured_contract_pdfを呼び出してセマンティック検索を実行します。
• Google Vertex AI：ローコードのランタイムが自律的なカスタマーワークフローを推進します。
  • 接続されたOpenAPIゲートウェイ：OpenAPI準拠のWorkdayおよびServiceNowゲートウェイを介してコールをルーティングし、read_latest_incident_ticketsを呼び出してcreate_workday_expense_claimをトリガーします。

実装における4つの一般的なセキュリティギャップ

次に、このメッシュを通過する一般的なリクエストを1つ追跡し、よくあるセキュリティギャップを明らかにします。これは、データベースに到達する必要がある、企業の知識ベースのルックアップです。一元的なアイデンティティファブリックがない場合、エージェントが保持するトークンに見られるように（図4）、4つの点で失敗します。トークンに欠けているものにギャップがあります。

シャドーAI

Amazon Bedrock AgentCore内で実行される、自社開発またはサードパーティ製のエージェントは、アイデンティティプロバイダー（IdP）に登録されることなく、チームによって構成またはデプロイされることがよくあります。これらの環境にはセキュリティSDKがインジェクトされないため、エージェントは動的にスピンアップし、企業のアクセスポリシーのEdge周辺で内部リソースに接続します。これらの未加工トークンはマシンクライアントを示していますが、iss（発行者）クレームがなく、背後で検証する人間もおらず、ライフサイクルに責任を持つ所有者もいません。発行していないBedrockエージェントを管理することはできません。

過剰な特権アクセス

管理外エージェントのトークンに含まれるscopeクレームは、過剰なリスクをもたらします。Bedrockエージェントが実行フローを常に中断してシステム境界を越えて再認証することなくターゲットデータベースに接続できるようにするために、開発者はそのエージェントを広範で有効期間の長いサービスアカウントに割り当てる傾向があります。トークンのスコープは、特定のテキストクエリが必要とする範囲をはるかに超えた、永続的で広範な管理領域を対象としています。スコープが過剰に設定されると、プロンプトインジェクションやデータ窃取に対して脆弱なアクセスパスが作成されます。しかし、そのエージェントを取り消すと、単一のサービスアカウントを共有している他のすべての自動化ワークフローが中断してしまいます。

偽装であり、委任ではありません

ルックアップがBedrock AgentCoreからターゲットのAurora DB MCPサーバーに渡る際に、アイデンティティは完全に汎用的なマシン主体に集約されます。データベースエンジンは、query_knowledge_base()を呼び出すサービスアカウントをログに記録しますが、タスクを開始した人間のオペレーターのアイデンティティと、クエリを実行している特定のサブエージェントは記録されません。トークン内に暗号化された委任の系統情報がなければ、リソース境界でユーザーレベルのデータ権限を適用できなくなり、結果としてアイデンティティが完全に消去され、監査証跡が破損します。

ガバナンスなし

エージェントがツール呼び出しや予期しないデータベース読み取りを実行する際、管理されていないマシントークンには、トランザクションアイデンティティも、人間の同意のコンテキストも含まれません。アクションは承認のためのランタイムの一時停止なしでシームレスに実行されるため、セキュリティチームは状況をまったく把握できません。事後になると、自動化されたトランザクションを暗号技術によって人間の管理者と結びつけることが不可能になります。つまり、誰がどのデータ移動を承認したかを法的に証明できなくなります。

ほとんどのエンタープライズは、これらのうち1つまたは2つを修正するにとどまっています。

トークンに見られる4つの一般的なセキュリティギャップ

その1件のリクエストを覚えておいてください。この記事の後半のウォークスルーでは、AgentcoreエージェントがAurora DB MCPツールにアクセスする様子を紹介します。今回はOktaを介してアクセスしており、4つのエラーはどれも発生することなく成功します。

Okta for AI Agentsは、セキュリティギャップに対処します。

Oktaは、信頼境界を実行パスに組み込まれたガバナンスレイヤーに変換します（図5）。Streamwardは、すべてのMCPトラフィックをポリシー適用ポイント（PEP）であるインラインのRuntime Agent Gatewayを介してルーティングします。その背後で、Oktaがポリシー判断ポイント（PDP）として機能します。エージェントが、MCPツール用の資格情報そのものを保持することはありません。これは、コントロールプレーンの考え方を具現化したものです。すべてのリクエストは、関与するアイデンティティを把握したポイントで一旦停止し、その時点で何が許可されるかを判断します。

Okta for AI Agentsを使用したマルチエージェントメッシュアーキテクチャのサンプル

ホップバイホップで進むセキュアなアクセスフロー

いずれかのバックエンドツールに到達する最終リクエストには、検証可能なアイデンティティが含まれます。このアイデンティティは、人間のコンテキスト（subクレーム）とエージェントのワークロードプリンシパル（actクレーム）の両方を保持します。

先ほどと同じ知識ベースのクエリを、今度はOkta経由で実行します。以下の図は、そのエンドツーエンドのプロセスを示したものです。続く各ホップでは、各ステップを順に追いながら、トークンがどのように構築され、受け渡されていくかを説明します（図6）。

エンドツーエンドのセキュアなアクセスフロー

バックエンドツールに到達する最終リクエストは、ユーザーコンテキスト（subクレーム）とエージェントワークロードプリンシパル（cidクレーム）の両方を保持する検証可能なアイデンティティを伝達します。

ホップ1：人間のユーザーからフロントエンドへ

ユーザーがOpenID Connect（OIDC）フローを介してStreamwardのポータルにサインインすると、Oktaは標準のユーザーアクセストークンを発行します。

ホップ2：フロントエンドからオーケストレーター

フロントエンドは自然言語プロンプトを処理し、ユーザーのアクセストークンをベアラートークンとして含んだタスクコンテキストをマスターエージェントオーケストレーターに渡します。

ホップ3：OrchestratorからOktaへのA2Aエクスチェンジ

オーケストレーターは、エージェントであるCorp-Knowledge-Agent介したBedrock AgentCoreでの分析処理がこのタスクに必要であると判断します。オーケストレーターは、ユーザークークンと要求されたスコープをOktaのトークンエンドポイント（/oauth2/v1/token）に送信し、Cross-App Access（XAA）フロー（Identity Assertion Authorization Grant）を開始します。Oktaはエージェントのアクセスポリシーを評価し、該当タスク向けにスコープを縮小した、有効期間の短い使い捨てのID-JAGトークン（urn:ietf:params:oauth:token-type:id-jag）を返します。

ホップ4：OrchestratorからOktaへのトークン交換

オーケストレーターは、オーケストレーターの秘密鍵でクライアントアサーションを作成し、ターゲットのAgentcoreエージェントに割り当てられたカスタム認可サーバーでID-JAGトークンを交換します。Oktaはそこでユーザーアクセスポリシーを評価し、エージェントCorp-Knowledge-Agent向けのスコープ付きアクセストークンを返します。

ホップ5：OrchestratorからBedrock AgentCore

オーケストレーターは、実際のエージェント間（A2A）呼び出しの一部として、スコープ付きトークンをAgentcoreエージェントCorp-Knowledge-Agentに渡します。AgentCoreはトークンを検証し、オーケストレーターエージェントと呼び出し元のユーザーアイデンティティのコンテキストで呼び出しが続行されることを許可します。

ホップ6：AgentCoreからゲートウェイまで

Corp-Knowledge-Agentはゲートウェイを介してAurora DB MCPサーバーでquery_knowledge_baseツールを呼び出し、受信したトークンとアウトバウンドツールに必要な許可（スコープ）を渡します。

ホップ7：Oktaへのゲートウェイ、クロスアプリアクセス

ゲートウェイはXAAフローを再度開始し、インバウンドトークンと要求されたスコープをOktaのトークンエンドポイント（/oauth2/v1/token）に送信します。Oktaはエージェントのアクセスポリシーを評価し、タスクに合わせてダウンスコープされた、有効期間が短く1回限り使用可能なID-JAGトークンを返します。

ホップ8：Oktaへのゲートウェイ、トークン交換

ゲートウェイは、Agentcore Corp-Knowledge-エージェントの秘密鍵でクライアントアサーションを作成し、ターゲットのAurora DB MCPサーバーに割り当てられたカスタム認証サーバーでID-JAGトークンを交換します。Oktaはそこでユーザーアクセスポリシーを評価し、MCPサーバー向けのスコープ付きアクセストークンを返します。

最終的にツールが受け取るリクエストは、完全に属性を特定できるものになります。具体的には、リクエスト元の人間の特定、動作したエージェント、そのスコープ、そして一連のチェーン全体を1つのレコードに結び付けるCoC（Chain of Custody）クレーム（act）が含まれます。権限はランタイムで決定され、タスクにスコープが限定され、その権限に責任を持つ人間から切り離されることはありませんでした。

アーキテクチャによって解決される4つの主要なセキュリティ上の欠陥

この標準化されたアーキテクチャを通じてBedrock AgentCoreの実行フローをルーティングすることで、Streamwardは、管理されていないエージェント構成を破壊する4つの一般的なアイデンティティエラーを正常に無効化します。

シャドーAIの修復

Bedrock Corp-Knowledge-Agentが検証可能な発行者なしで中央のIdPの周りで無秩序に実行されるのを許可するのではなく、エージェントは個別のワークロードプリンシパルとしてUniversal Directoryに直接登録されます。ITガバナンスは、そのライフサイクルに対する明確な所有権と、ネットワーク接続に対する可視性を維持します。

過剰な権限が付与されたアクセスの修復

プロンプトインジェクションの脅威にデータベースレイヤー全体をさらすような、広範で永続的なスタンディング許可を持つサービスアカウントで実行する代わりに、エージェントには実行時に動的に生成される有効期間の短いトークンが発行されます。そのスコープは数学的に共通部分が取られ、その特定の実行ブロックに必要な単一のデータベース操作（Aurora-DB:read）に厳密にダウンスコープされます。

なりすまし防止

マルチホップのactデリゲーションチェーンをトークンのコンテキストに直接埋め込むことで、アイデンティティが汎用的なマシン認証情報に集約されるのを防ぎます。リソースの境界は、管理の来歴を正確に追跡し、アイデンティティの消去を防ぎ、起点となった人間の実際の許可に従ってデータ制御を適用します。

ガバナンスの強化

トークン交換のすべてのステップで、明示的かつ構造化されたイベント（app.oauth2.token.grant.id_jag）が生成されます。変更不可能なトランザクション識別子に関連付けられています。この永続的な監査履歴は、どの人間がどの自動化アクションを承認したかの証拠を、コンプライアンスチームとインシデント対応チームに提供します。

Okta for AI Agentsのコンポーネント

上記のソリューションに関わるOkta for AI Agentsのコンポーネントを見ていきましょう。

エージェントの登録とディスカバリー

このコンポーネントは、不明な自律エージェントをUniversal Directoryに登録することで、既知の検証可能なワークロードプリンシパルに変換します。Universal Directoryでは、それぞれにライフサイクル、指名された人間の所有者、およびポリシーにおける場所が割り当てられます。

手動で登録するよりも速いペースで管理外のエージェントが出現するため、Identity Security Posture Management（ISPM）は、クラウドやMCPネットワーク全体でこれらのエージェントを検出します。これには、本来なら可視化されないノーコードエージェントも含まれ、それぞれを所有者にマッピングします。目に見えないエージェントは、認可もアカウンタビリティの確保もできません。

エージェントの自動オンボーディング

Salesforce、AWS、Microsoft、ServiceNow上に構築されたエージェントはUniversal Directoryに直接インポートされるため、レジストリはそれらの出現と同時に更新されます。

Cross App Access

XAAはIdentity Assertion Authorization Grantを使用して、マルチホップワークフロー全体でのアイデンティティの消去を防止します。エージェントが匿名のサービスアカウントとして機能するのではなく、人間（subクレーム）とエージェント（actクレーム）の両方がトークン内を移動し（図7）、単一のプリンシパルではなくチェーンであるアクタートークンを生成します。XAAは、リクエストがベンダーの境界を越える際に、認証を実在の人物に結び付け続けるためのものです。

XAAフロー

委任された同意

ユーザーに代わってエージェントがSaaSに初めてアクセスする場合、OktaのSecure トークンサービス（STS）が動的に同意を仲介します。通話が続行される前に、ユーザーが帯域外で一度アクセスを認証する間、エージェントは一時停止します。同意は各エージェントに組み込まれるのではなく、アイデンティティレイヤーで確立されるため、変更不可能なエージェントでも制御を継承します。

エージェント間の認可

エージェントメッシュでは、Oktaがすべてのハンドオフを仲介します。1つのステップで2つのエージェント間の接続が構成され（図8）、有効な許可はユーザーの権限と呼び出し元エージェントの権限の共通部分となります。つまり、サブエージェントが最小特権付きの組み合わせを超えることはありません。ネストされたアクターのクレームは、人間から各エージェントを経由して最終的なサービスまで拡張されます。すべてのホップでポリシー制御された権限が付与され、説明責任を負う人間がチェーン内に維持されます。

Oktaでのエージェント間リソース接続の構成

一元化された監査

エージェントは法人ではなく、自己責任を負うことができないため、あらゆるチェーンの最終段階で責任を負う人間を指名できる必要があります。1つの証跡ですべてのトランザクションをキャプチャし、誰が誰の代理で行動したかを証明する明示的な権限付与イベント（図9）も記録します。これは、規制当局、裁判所、または取締役会が要求する記録です。

一元的な監査のためのOktaシステムログ

安全なランタイム制御

Oktaは、インラインのRuntime Agent Gatewayをダウンストリームリソースの前にある中央ポリシー適用ポイント（PEP）としてデプロイし、Oktaはすべてのリクエストのポリシー決定ポイント（PDP）として機能します（図10）。

ランタイムエージェントゲートウェイ

• 仮想MCPサーバー：ゲートウェイは自身をMCPサーバーとして提示します。これにより、Organizationsは、エンタープライズリソースにアクセスするローコードエージェントやノーコードエージェントを保護できます。その際、これらのエージェントがネイティブにトークン交換を処理する必要はありません。
• 認証情報の分離：ゲートウェイは、有効期間の短いXAAトークンと有効期間の長いブローカーSaaSトークンを抽象化するため、これらのリソース認証情報がエージェントに公開されることはありません。
• インラインでのツール呼び出しのセキュリティ：ローコードプラットフォームは、すべてのアウトバウンドのツール呼び出しをゲートウェイ経由でルーティングします。ゲートウェイはその呼び出しをインターセプトし、きめ細かいポリシーとの関係性をワイヤースピードでチェックして、実行前にエッジで有効期間の短いバックエンドシークレットを注入します。発行されるトークンは、リクエストの瞬間に生成され、該当タスクにスコープが限定され、特定のオーディエンスに紐付けられ、数秒で失効させることができます。これは、ファイルに保存されて再利用される可能性のある永続的な資格情報とは対極のものです。

今後の展望：Okta for AI Agentsの高度な機能

このアーキテクチャが現在提供しているのは、すべてのエージェントが検証可能なアイデンティティを取得し、その権限が実行時に決定され、タスクにスコープされるという基盤です。

グローバルキルスイッチの第一段階はすでに導入されており、Shared Signals Framework（SSF）を使用してリスクシグナルを失効へと変えます。これは、接続されているすべてのシステムで連携したリアルタイムの終了へと拡大し、短命なトークンだけでは提供できない制御を実現します。

次に、コントロールプレーンの同じ原則が、エージェントのライフサイクルにおいてまだ適用されていない部分にまで拡張されます。これは、ガバナンスチームがすでに人間のアクセスに対して問いかけている質問を、今度はエージェントに対して問いかけるということです。

• エージェントアクセス認定：各エージェントの権限が他のアクセスと同様の認証とレビューを受けられるようにします。リソース所有者は、保持すべきものを確認し、古くなったものを失効させます。
• アイデンティティとリソース間のアクセスグラフ：個人から、その個人に代わって機能するすべてのエージェントを経由し、それぞれがアクセスできるリソースとスコープに至るまでの完全なパスを追跡します。これにより、問題が発生する前に影響範囲（ブラスト半径）を可視化し、問題発生時には失効させるべきターゲットを明確に特定できます。
• ヒューマンインザループ承認：プロビジョニング時や機密性の高いアクションを実行する際に、最も重要な意思決定プロセスに担当者を介在させます。
• 無人監視下での権限：エージェントは、事前に信頼が付与されるのではなく、過去のふるまいに基づいて無人監視下での権限を獲得し始めます。

これらはどれも新しいコントロールプレーンではありません。エージェントが作成された時点から、その権限がレビュー、縮小、または取り消される時点まで延長された、同じものです。

セキュアなエージェンティック企業のための設計指針

一歩引いて見ると、このアーキテクチャは、すべてのセキュリティチームが問いかけている3つの質問に答えるものであることがわかります（図11）。

1. エージェントはどこにいるのか？ （企業が構築したものと、独自に導入されたもの）
2. 何に接続できますか。（MCPサーバーやSaaSアプリから、他のエージェント、サービスアカウント、レコードのレガシーシステムまで）
3. ユーザーに許可される操作（実行時に決定され、重要な場合は人間にエスカレーションされ、計画どおりに進まない場合は取り消される）は何ですか。

この3つの質問は、Agentic エンタープライズ Blueprintの基盤となる運用規範です。

AIエージェントを大規模に保護するためのOktaのブループリント

Uberのような企業は、AIエージェント向けにこの種のガバナンスを確立する必要性を示しています。しかし、すべての企業がこれを自社で設計する必要はありません。

どのレイヤーにも共通するテーマは同じです。つまり、アイデンティティがコントロールプレーンであり、認可はランタイムで決定され、タスクにスコープされ、責任を負う人間がリクエストとともに移動し、全体がオープン標準で実行されるため、エージェントがアクセスするすべてのベンダーにわたって有効であるということです。

エージェントをそのような条件でファーストクラスのアイデンティティとして扱うことは、エージェント型エンタープライズを保護するための正しい方法です。Okta for AI Agentsは、1年かけて構築するシステムではなく、導入するだけで済むレイヤーとしてそれを実現します。この記事で紹介するアーキテクチャは、構築するものではなく、導入するものです。

OktaとAuth0がAIエージェントを保護する方法をご覧いただくか、Oktaのチームまでお問い合わせください。