CISOの立場にある方なら、取締役会から次のような質問を受けているかもしれません。「当社のAIセキュリティ戦略はどうなっているか？」
そしておそらく、このように回答しているのではないでしょうか。「現在、対応中です。AIポリシーを引き続き策定しており、何を導入するかが明確になり次第、セキュリティを講じる予定です。」
6か月前だったらそういった答えでも安全に感じられました。しかし、今はそのようにはいきません。
今、リスクがあるのは、これから導入しようとしているAIエージェントではありません。すでに自社の環境内で働いているAIがリスクをもたらすのです。
エグゼクティブ・サマリー
- AIガバナンスのギャップ：Oktaの「2025年AI at Workレポート」によると、組織の91％がAIエージェントを展開している一方で、管理戦略を持っているのはわずか10％と示されており、過剰な権限を持つエージェントが差し迫ったリスクとなっています。
- 可視性の盲点： 従来のネットワークやエンドポイントツールでは、侵害されたAIエージェントの特定のアクション、所有者、許可を追跡できません。
- コントロールプレーンとしてのアイデンティティ：アイデンティティは、どのエージェントが誰のために何をしたのか、そしてそれが許可されていたのかどうかを答えられる唯一のセキュリティレイヤーです。
- 統一されたアプローチ：Okta for AI Agentsは、AIエージェントの検出、オンボーディング、保護、およびガバナンスを実施します。
企業がエージェント型AIへ移行することは、もはや将来像ではなく、現実のものとなっています。Oktaの「2025年AI at Workレポート」によると、今日、91％の組織がすでにAIエージェントを使用して複雑なワークフローを自動化し、生産性を高めています。しかし、同レポートでは、危険なガバナンスのギャップも強調されています。導入が急増している一方で、AIエージェントを含む非人間アイデンティティ（NHI）の管理に関する十分な戦略やロードマップを持っていると報告している企業責任者はわずか10％に過ぎません。
シャドーAIのリスク：見えない労働力の管理
アイデンティティ評価を先延ばしする行動は、根本的な事実を見逃しています。リスクは、今後導入しようとしているAIだけではありません。今、すでに実行されている特権付きのエージェントもリスクなのです。
AIポリシーを完全に策定することはしばらく忘れてください。まず、現在の環境について以下の質問を考えてみましょう。
- AIエージェントはどこにいるのか？
- 「エージェントは何と繋がることができるのか？」
- 「エージェントは何ができるのか？」に取り組みながら独自の洞察を提供しました。
セキュリティ責任者は、ほとんどの場合、これらの質問に自信を持って答えることができません。しかし、それはセキュリティプログラムの問題ではありません。構造的なギャップによるのです。エージェントはすでに現場に存在しており、既存のアイデンティティ制御はまだそういったエージェントにまで及んでいない可能性があります。
正式なロールアウトについて議論されている一方で、従業員はOAuthによる許可を通じてサードパーティのAIツールを企業アカウントに頻繁に接続しています。例えば、CursorをGitHubに、ClaudeをGoogle Workspaceに、またはAIによる会議議事録作成ツールをカレンダーに接続するなど、ガバナンスが追いつかないほどのペースでAIが使用されています。
すべての許可は、企業データへの権限を委任された非人間アイデンティティ（NHI）を作成しますが、多くの場合、検証済みの所有者が存在せず、「影響範囲」が不明です。
シャドーAIの現実
最近、ある有名な開発者プラットフォームで発生したインシデントは、脆弱性やインフラの欠陥によるものではなく、従業員の企業アカウントとサードパーティのAIツール間をOAuth経由で接続したことが原因でした。この接続は、IT部門の監視外で完全に許可されていました。そのAIツールが侵害されたとき、事前に付与されていた信頼関係が攻撃経路へと変わり、内部システム、APIキー、トークン、環境変数へと一直線に侵入されてしまいました。これは、シャドーAIが実際にどのようなものかを示す一例です。誰も承認しておらず、IT部門の監視もない、無許可のOAuthグラントによりこのようなインシデントが起きたのです。
目を背けたくなる事実：AIエージェントのセキュリティ対策をAIポリシーが最終的に決まるまで待っていると、リスクがすでに複合化されたものを基盤にガバナンスを適用することになります。
当社の5分間の攻撃シミュレーターでAIセキュリティのギャップを見つけましょう。
アイデンティティがAIガバナンスに不可欠な基盤である理由
従来のセキュリティモデルでは、多くの場合、ネットワークまたはエンドポイントの保護が優先されます。これらは重要なレイヤーですが、どの自律エージェントが何にアクセスしているのか、どうしてアクセスしているのかを根本的に把握することができません。
- ネットワークツールはトラフィックを監視します。しかし、ユーザーに代わって行動するAIエージェントは、正当なAPIトラフィックのように見えます。
- エンドポイントツールはプロセスを監視します。しかし、AIエージェントは正当なユーザーのセッション下で実行される標準的な認可プロセスのように見えます。
どちらのレイヤーも不可欠ですが、インシデント発生時に重要な疑問、「どのエージェントが、誰のために、どの範囲でこれを行ったのか、そしてそれは許可されたのか」に答えることはできません。
エージェントの時代において、アイデンティティは、エージェントの意図と範囲を理解する唯一のセキュリティレイヤーです。そのため、現在では85％のリーダーがアイデンティティとアクセス管理（IAM）をAI戦略において最も重要な要素と位置付けています（Okta、「2025年 AI at Work レポート」）。
先に述べた開発者プラットフォームのインシデントは、エンドポイントやネットワークのエラーではないことを示しています。弊社の理解するところでは、これはアイデンティティの問題です。具体的には、サードパーティのアプリやAIツールにどのようにアクセス権が付与され、それらが何を実行できるか、そしてどのくらいの期間で実行できるかという問題です。
そこで、OktaはOkta for AI Agentsを開発しました。これは、Okta Platformを拡張し、お客様の環境におけるAIエージェントの検出、オンボード、保護、および管理を行うための専用ソリューションです。Okta for AI Agentsは、あらゆるプラットフォームにおけるAIエージェントを検出し、オンボードし、スコープされた最小権限アクセスで接続を保護します。また、アクセスレビュー、完全な監査証跡によりAIエージェントを管理し、AIエージェントが予期しない動作をした場合には、新しいトークンリクエストと将来の認証を阻止するためにキルスイッチを使用してAIエージェントを即座に手動で非アクティブ化させることができます。
エージェントの完全な可視性と制御を実現するための4つの重要な機能
アイデンティティがエージェントのコントロールプレーンである場合、以下の4つのことが統一的に実現されます。
- 最高水準のエージェントアイデンティティ：エージェントが社内で構築されたものや、SaaSツールに組み込まれたもの、または従業員のラップトップで実行されているもののいずれであっても、認証情報や割り当てられた人間の所有者、および管理されたライフサイクルを持つワークロードプリンシパルとして登録されます。CIOから「このエージェントの所有者は誰か、問題が発生した場合の責任者は誰か」と尋ねられた際には、そのように答えられます。
- 暗号化された属性： すべてのアクションは、暗号で署名された人間とエージェントのアイデンティティを持ちます。監査役から「どのエージェントが、誰のためにこれを行ったのか」と問われた際に提示できるのがこの情報です。
- 最小権限の適用：トークンはセッションやアプリごとではなく、単一の呼び出しにスコープが設定されています。つまり、スタンディング特権はなくなります。役員会から「エージェントの1つでも侵害された場合、当社のリスクはどのようになるか」と聞かれたら、こういった理由を説明できます。
- 統合されたガバナンス： エージェントのアクセス要求とアクセス認定は、後付けではなく、アイデンティティ・プラットフォームに組み込まれています。監査担当者より「AIエージェントのアクセスが過去90日間に人間のレビューを受けたことを示すように」と要求された場合にこういった理由を提示できます。
しかし、こういった機能は、エージェントが実行されるすべての場所に適用できるのでなければ、意味がありません。つまり、エージェント戦略はエコシステムに組み込まれているものでなければなりません。エージェントは、Salesforce Agentforce、Amazon Bedrock、ServiceNow AI、またはチームが今後採用するプラットフォーム上で実行される可能性があります。その場合、エージェントが自社のエコシステムをまたぐたびに、エージェントが組み込まれた元のプラットフォームのガバナンスは十分に効かなくなってしまいます。結果として、残されたものはギャップです。
Okta は、そのギャップを埋めるために構築されました。Okta for AI Agentsは、ベンダーニュートラルに設計されており、Azure、AWS、Google Cloudにわたるアイデンティティの仲介処理を抽象化することで、個別の統合を行うことなく、同じポリシーをどこでも均一に適用できます。
既存のIdP（IDプロバイダー）の置き換えでなく、拡張させる設計
ITアーキテクトの主な懸念事項は「アイデンティティの拡散」、つまり、AI向けに新たなアイデンティティ・サイロを追加することへの懸念です。最新のAIガバナンスでは、既存の従業員のアイデンティティを「完全に入れ替える」必要はありません。
アイデンティティプロバイダー（IdP）は、従業員情報を保存するシステムです。そこではサインインポリシーが管理・運用され、多要素認証が強制適用される他、条件付きアクセスによって制御されています。また、長年の統合作業によって人間のアイデンティティ管理がスムーズに実行される場所になっています。こういった点は、エージェントを追加したからといって変更されるべきではありません。
Okta for AI Agentsは、設計上、追加機能として提供されます。既存のIdPとは標準プロトコル（OIDC、SAML）を介して連携し、資格情報の複製をしたり、2回目のサインインを要求したりすることなく、IdPからの信頼を継承します。人間がエージェントを起動すると、OktaはIdPからのアイデンティティ・アサーションを検証し、人間ユーザーとその人間のエージェントの両方の情報を保持した1つの暗号署名付きトークンを発行します。つまり、人間側は既存の仕組みにとどまり、エージェント側に人間向けのガバナンスを適用します。
このように、プラットフォームの再構築やディレクトリの複製、運用上の負担を考えることなく、これまで投資してきたアイデンティティ基盤を拡張することによって、新しい種類のアイデンティティをカバーすることができます。
Oktaが提供するベンダーニュートラルなレイヤーのアプローチについての詳細は、こちらをご覧ください。現在のIdPを置き換えることなく、すべての接続を保護します。
今日答えるべき3つの質問
AIポリシーは後回しにできますが、環境内のエージェントは待ったなしです。
まずは、以下の3つの質問から始めましょう。
AIエージェントはどこにいるのか？
エージェントは何に接続できるのか？
「エージェントは何ができるのか？」に取り組みながら独自の洞察を提供しました。
アイデンティティは、これら3つの質問すべてに答えることができる唯一の基盤であり、将来のポリシーを支える土台となります。
AIガバナンスを直接体験してみましょう。インタラクティブなOkta for AI Agentsのデモをお試しください。
よくある質問（FAQ）
従業員はどのようにシャドーAIを企業ネットワーク内に持ち込むのでしょうか？
従業員は通常、OAuth権限を使用して、サードパーティのAIツールに企業環境への直接的なAPIアクセスを許可することで、シャドーAIを導入します。こういった連携は、AIアシスタントを企業のカレンダーやコードリポジトリに接続するなどのように、ユーザーレベルでシームレスに行われますが、従来のIT部門の監視を回避し、監視されていない非人間アイデンティティ（NHI）を作り出します。
ネットワークやエンドポイントのセキュリティツールは、なぜAIエージェントの動作を認識できないのですか？
従来のネットワークツールは自律的なAIエージェントの活動を正当なAPIトラフィックとみなし、エンドポイントツールはそれを許可されたユーザーのセッション内で実行されている標準的なプロセスとして解釈します。これらの境界にはアプリケーションレベルのアイデンティティコンテキストがないため、どのエージェントがどのアクションを開始したのか、誰のために行動したのか、その影響範囲はどの程度かを判断できないのです。
企業の正式なAIポリシーを最終決定する前に、AIエージェントを保護できますか？
はい、できます。正式な企業統治ポリシーを待っていると、現在影響を及ぼしているセキュリティ上の脆弱性が未対応のままになります。セキュリティチームは、構造的なポリシーの承認を待つのではなく、既存のIdPアーキテクチャを拡張し、非人間アイデンティティ（NHI）プロトコルを通じて自律的なワークロードを検出、承認、および管理することにより、リスクを軽減できます。
AIエージェントのセキュリティを実装するには、完全に別個のアイデンティティディレクトリが必要ですか？
いいえ。効果的なAIガバナンスは、主要なIdPとの追加的な統合を通じて、「アイデンティティの無秩序な増加」を回避する必要があります。OpenID Connect（OIDC）やSAMLのようなオープンなフェデレーション標準を使用することで、Oktaのようなプラットフォームは、ユーザー認証情報を複製せずに、マシンエージェントのアイデンティティを既存の人間向け認証ルールに結び付けたスコープ付きトークンを発行できます。
このブログで言及されている将来の製品、機能、機能性、認証は、情報提供のみを目的としています。ここに記載されている内容は、提供を約束するものではなく、購入の意思決定を行う際に依拠すべきものではありません。
これらの資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネス上の助言ではありません。
このコンテンツは、最新のセキュリティ、法律、および/またはプライバシーの動向を反映していない可能性があります。ご自身の法的助言者および/または専門家からの助言の取得については、利用者ご自身の責任で行うものとし、当資料に依拠すべきではありません。
Oktaは、本コンテンツに関していかなる表明または保証も行いません。また、これらの推奨事項を利用者が実装した結果生じたいかなる損失または損害についても、当社は一切責任を負いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsでご覧いただけます。
