2025年9月、Anthropic社は主にAIエージェントによって実行された記録上初の大規模サイバー攻撃を検知し阻止しました。中国政府が支援するグループ(GTG-1002)がClaude Codeを操作し、金融サービス、テクノロジー、製造業、政府機関など、約30組織を標的にしました。(Anthropic report)@@ AIは、偵察、脆弱性の探索、エクスプロイト、認証情報の収集、ラテラル・ムーブメント、データ持ち出しといった戦術的オペレーションの80~90%を自律的に実行しました。人間が介入したのは重要な戦略的決定ゲートだけであり、各フェーズで約20分間の直接的な指示を行う程度でした。この攻撃による数件の侵入成功が確認されました。
これは、概念実証ではありませんでした。これは、今日のほとんどの企業が抱えるアーキテクチャ上のギャップを悪用した運用キャンペーンでした。モデル層のスクリーニングでは操作されたプロンプトは検出されず、エージェントIDフレームワークでは不正な自律動作は検出されず、エージェントリレーでは実行時にツールレベルの制御が実施されたのです。100人以上の業界専門家の意見を基に2025年12月に発表されたOWASP Top 10 for Agentic Applications@@は、これらのエラー・モードを体系化しており、エージェント目標ハイジャック(ASI01)、ツール誤用(ASI02)、アイデンティティおよび権限乱用(ASI03)が上位3つのリスクとして挙げられています。
2025年9月の攻撃チェーン | アーキテクチャが関与する所 | |
|---|---|---|
▶ジェイルブレイク:ロールプレイによる欺瞞+タスク分解 | ← | ✓ モデル:プロンプトスクリーニングによって操作を検出する |
▶ 偵察:サービス列挙、ネットワークスキャン | ↓ | |
▶ 悪用:認証情報の収集、脆弱性のエクスプロイト | ← | ✓ アイデンティティ:有効な委任チェーンが存在しないため、エージェントをブロックする |
▶ ラテラルムーブメント:システムを跨いだ認証情報の再利用 | ↓ | |
▶ データ窃取:データベースクエリ、バルクデータの抽出 | ← | ✓ データ:エージェントリレーはツールまたはパラメータの制約を強制する |
これは孤立した出来事ではありません。組織の88%が、過去1年間にAIエージェントのセキュリティインシデント(確認済または疑いのあるもの)を報告しており(Graviteeの調査)、AI関連の侵害を経験した組織のうち、97%がAIシステムに対する適切なアクセス制御を欠いていました(IBM/Ponemon)。AIエージェントを独立したアイデンティティを持つ存在として扱う組織ははわずか22%です(Gravitee)。
別の言い方をすれば、本番環境にエージェントを導入していて、まだインシデントが発生していないのであれば、それはまだ見つかっていないだけでしょう。
適切なアーキテクチャ
企業は、3つの異なる信頼境界にエージェントを導入しています。内部エージェント(ITヘルプデスクボット、人事エージェント、ERPレポートを取得する財務ボット)は、エンタープライズの境界内で動作します。顧客対応エージェント(サポートアシスタント、エンドユーザーに代わって社内ナレッジベースに問い合わせを行うセルフサービスAI)は、社内リソースと外部の顧客との橋渡しを行います。パートナーエージェント(サプライチェーンの統合や組織を越えたサービス提供)は、完全に組織の境界を越えて運用されます。セキュリティ要件は、各エージェントの追加に伴って高まります。内部エージェントには、アイデンティティとライフサイクルガバナンスが必要です。顧客対応エージェントを追加する場合、委任された認証と同意が必要になります。パートナーエージェントまで拡張すると、ドメイン間の信頼とデータフローの制御を管理することになります。これら3つはすべて、同じ基盤となるアーキテクチャを必要とします。
AWS、Google、Anthropic、Microsoftはそれぞれ、自社のプラットフォーム内で、これら3つのレイヤーに対応するエージェントセキュリティコントロールを提供しています。それはアーキテクチャを検証します。しかし、企業は単一のプラットフォームだけでエージェントを運用しているわけではありません。必要なのは、これらすべてに対応するアイデンティティと認可です。Gartnerは、2028年までに企業侵害の25%がAIエージェントの悪用によるものになると予測しています。McKinseyは、AIエージェントを「デジタルインサイダー」と呼び、従業員と同じガバナンスを必要とすると述べています。アーキテクチャの導入は導入は避けられない道と言えます。問題は、それを能動的に導入するか、事後対応的に導入するかということです。
第1層 モデルセキュリティ | 第2層 エージェントアイデンティティ | レイヤー3 データ許可 |
|---|---|---|
|
|
|
「このモデルは承認されており、範囲内で動作していますか?」 | 「このエージェントは、このユーザーの代理として行動することを許可されていますか?」 | 「このツールはこれらのパラメータで今すぐ実行すべきでしょうか?」 |
第1層:モデルセキュリティ、知能の保護
2025年9月のキャンペーンでは、攻撃者はロールプレイデセプションとタスク分解を利用して安全ガードレールを回避し、多段階攻撃を個別に見ると正当に見えるリクエストに分割しました(Anthropic)。人間が毎分何千ものプロンプトを確認することはありません。モデル層セキュリティは、操作されたプロンプトと侵害されたネットワークの間に存在するものです。
モデル評価と敵対的レッドチーミングにより、本番環境に移行する前に脆弱性が明らかになります。プロンプトインジェクション防御は、ドキュメント、Eメール、またはツール応答に隠された悪意のある指示を捕捉し、出力ガードレールとDLPは機密データの漏洩を防ぎます。継続的なI/O監視はリアルタイムで異常な動作を検出し、それらを結び付けます。これらは理論上のリスクではありません。研究者たちは、実際に悪用されているMCPの脆弱性を発見しました。悪意のあるMCPサーバーによるツールポイズニング、ツール応答を介したプロンプトインジェクション、MCPパッケージに対するサプライチェーン攻撃(OWASP)などです。AWS Bedrock GuardrailsとGoogle Cloud Model Armorはどちらも、実行時に設定可能な、モデルに依存しないスクリーニングを提供します。モデルが侵害された場合、その上に構築するものはすべて意味をなさなくなります。
第2層:エージェントアイデンティティ、アクターの保護
モデルが信頼できるようになったら、エージェントにはアイデンティティが必要となります。共有サービスアカウントではありません。静的APIキーではありません。何か問題が起きたときに対応する所有者、期限が切れるスコープ付きの権限、そして適切なタイミングで終了するライフサイクルを持つ、本物のアイデンティティが必要なのです。
AI以前は、すべてコードでした。何が起こるかを確定的に知っていました。しかし、AIエージェントが登場した今、プロンプトを与えるだけで、どのようなシステムにアクセスするかは保証されていません。予想していなかったシステムに、より高いレベルのアクセスでアクセスするかどうかもわかりません。
ハリッシュ・ペリ(OktaのSVP兼GM)
エージェントアイデンティティは探索から始まります。稼働しているエージェントの数、誰が構築したのか、どのような認証情報を保持しているのかを把握することです。OktaのAI at Work調査によると、エージェントをすでに導入している組織は91%に達するものの、効果的なガバナンス戦略を持っているのはわずか10%に過ぎません。お客様向けのワークショップを開催するたびに、最初の質問は必ず同じです。実際にエージェントは何人いるのでしょうか?答えはほとんどの場合、「わからない」です。すべてのエージェントは、永続的なアイデンティティ、割り当てられた所有者、および分類を持ちます。認可は委任に従います。エージェントは、特定のタスクのために、特定の許可セットを持つ特定のユーザーの代理として行動します。OktaのCross App Access(XAA)は、OAuthを拡張するオープンプロトコルであり、現在MCPに企業主導型認可として採用されており、これらの委任チェーンを監査可能にします。チェーンが途切れると、アクセスは停止します。SCIMによるライフサイクル管理は、人間のアイデンティティと同じガバナンスを提供します。アクセスレビュー、自動プロビジョニング解除、オーナーアカウンタビリティなどが含まれます。委任ユーザーがオフボードされたり、ポリシーが変更されたりすると、失効はすべてのダウンストリームシステムに伝播されます。
しかし、アイデンティティだけではギャップを埋めることはできません。エージェントが承認されていることを知っていることと、エージェントが今すぐ午前2時にこれまで一度もやり取りしたことのない受取人にこの口座から50,000ドルを送金すべきかどうかを知っていることは、同じではありません。
第3層:データ許可、操作の保護
OAuthポリシーはトークンをチェックします。有効なスコープ、有効なオーディエンス、期限切れではないかを確認します。それは必要ですが、十分とは言えません。そのトークンは、エージェントが転送を実行できることを示しています。この金額の送金がこの受取人に意味があるかどうかについては何も書かれていません。
アイデンティティと境界だけでは、エージェントの操作に対する大まかな制御しかできません。ツールの利用に関する安全対策を講じることで、許可する操作をきめ細かく制御できるようになります。
Googleクラウド、エージェント開発キット安全文書
エージェントの動作は決定的ではありません。LLMは実行時にツールを選択し、それまでに行われた推論に基づいてパラメータを入力し、ポリシーが作成されたときには誰も予想していなかったシーケンスで操作を連鎖させます。ここでエージェントリレーが必要になります。エージェントと、それが呼び出すツールとの間のエンフォースメントポイントとしてです。OktaのAgent Relayは、きめ細かいランタイム制御を適用します。ツールレベルのアクセス制御(このエージェントはどのツールを呼び出すことができるか?)、パラメータ制約(金額は制限内か?)、高リスク操作に対するCIBA(クライアントが開始するバックチャネル認証、Client-Initiated Backchannel Authentication)によるヒューマンインザループの承認、アプリを跨いだデータフローのガバナンス(ツールAの出力はツールBの入力として承認されているか?)、そして完全な呼び出し監査証跡を提供します。
エージェントリレーは、アイデンティティに取って代わるものではありません。アイデンティティの次に動作するものです。アイデンティティによってトークンに何を含めるかが決まります。エージェントリレーは、実行時にトークンに含まれる情報を使用して、何を実行するかを決定します。クレームは、あるレイヤーから次のレイヤーへとコンテキストを伝えます。エージェントの役割と、許可されている操作の間にギャップがないようにするのです。
各層がなくなると何が崩れるのか
モデルキュリティがない場合 | エージェントアイデンティティがない場合 | データ認可がない場合 |
|---|---|---|
|
|
|
サイバーセキュリティ業界のトップ企業225社を対象としたKiteworksの調査によると、100%がエージェント型AIをロードマップに組み込んでいる一方で、63%が目的制限を適用できず、60%が不正なエージェントを停止できないことが判明しました。欠落しているコントロールこそが最も重要です。
アーキテクチャが向かう先
3層アーキテクチャは、今日のほとんどの企業が抱える構造的なギャップを解消します。次の段階を定義する3つの分野が急速に成熟しています。
- 再帰的委任:エージェントAがエージェントBに委任し、エージェントBがエージェントCに委任する場合、権限はどこまで伝播されるのか?誰が特定の階層で失効させるのか?OktaのCross App Access(XAA)とID-JAGは、すべてのトークン交換にユーザーアイデンティティとエージェントアイデンティティを埋め込み、委任のたびにスコープを狭めることで、管理の連鎖を維持します。SCIMライフサイクル管理は、委任されたユーザーがオフボードされたときに、確実に失効が伝播されるようにします。残された課題は、委任深度制限とマルチホップ失効シグナリングの標準化です。OAuth Identity and Authorization Chaining仕様は、この課題に積極的に取り組んでいます。
- 認可ドリフト: エージェントは呼び出しの際に認可されますが、ユーザーのアクセス許可はチェーンの途中で変更されます。失効は、既に実行中のオペレーションにどのように到達するのでしょうか。有効期限の短いトークンを積極的に使用することで、影響範囲を限定できます。CIBAベースのステップアップ認証は、リスクの高い意思決定ポイントで認可を再検証できます。Oktaのアクセスポリシーは、グループメンバーシップごとにスコープの許可を適用するため、ディレクトリレベルでの権限の変更は、次回のトークン交換時に有効になります。課題は、正当なオペレーションを中断することなく、アクティブな実行チェーン全体でリアルタイムの失効シグナリングを行うことです。
- クロスドメインの信頼境界:エージェントは、信頼モデルやデータ分類スキームが異なる2つのSaaSアプリケーション間でツールを連携します。境界をコントロールするのは何ですか?単一の信頼ドメイン内では、OktaのXAAとリソースごとのカスタム認証サーバーが、境界を越えるたびにスコープされたアクセスをすでに強制しています。Auth0 Token Vaultは、仲介された同意とトークン変換を通じて、これをサードパーティのOAuthリソース(Google、GitHub、Salesforce)に拡張します。組織の境界を越える問題、すなわち2つの独立したIdPがエージェント委任のために相互信頼を確立する必要があるということが、次の課題です。OAuth Identity Chaining仕様はアーキテクチャの基礎を提供し、Oktaはその開発に積極的に貢献しています。
これらは、明確なアーキテクチャの方向性が今後の方向性として示される難しい問題です。OWASP Agentic Security InitiativeとOpenID Foundationの両方がフレームワークを開発しています。現在、3層構造の基盤を確立した組織は、これらのコントロールが成熟するにつれて導入できるようになります。
各層の現在レベルは?
各層をに対して、自己評価してみましょう。ほとんどの企業は、少なくとも2つの点で「事後対応型」です。
モデルセキュリティ | エージェントアイデンティティ | データ許可 | |
|---|---|---|---|
事後対応型 | モデルレジストリなし、入力または出力のスクリーニングなし | エージェントは、共有APIキーまたは個人の認証情報を使用する | ツールレベルの強制なし、呼び出しログなし |
管理型 | レジストリあり、主要モデルのガードレール、定期的レッドチーミング | エージェント登録済み、静的トークン、手動ライフサイクルレビュー | 一部のツールでのエージェントリレー、部分的な監査証跡 |
アダプティブ | すべてのモデルを管理、リアルタイム監視、継続的評価、DLPの実施 | OAuth委任、SCIMライフサイクル、クロスアプリ失効伝播 | ツールの完全適用、パラメータ制約、CIBA、完全な監査 |
OktaとAuth0は、第2層と第3層にわたって「事後対応型」から「適応型」に移行するためのアイデンティティおよび認可インフラストラクチャを提供します。従業員アイデンティティと顧客アイデンティティの両方に対応するために構築された唯一の独立系アイデンティティプラットフォームとして、Oktaはエージェントアイデンティティを人間アイデンティティと同じガバナンスを持つ第一級の市民として扱います。これは、独自のロックインではなく、XAAやSCIMなどのオープン標準に基づいて構築されたものです。
もし3つのレイヤーすべてで「管理型」と自己評価した場合、それは寛大すぎるかもしれません。
90日間の道のり
1~30日目:診断 | 31~60日目:導入 | 61~90日目:定着化 |
|---|---|---|
|
|
|
おわりに
2025年9月の攻撃は、エージェント型AIの脅威が実際に機能していることを証明しました。業界データは、ほとんどの企業がまだそれに対応する準備ができていないことを裏付けています。3層アーキテクチャは、決して新しい考え方ではありません。これは、世界最大のプラットフォーム企業が独自に構築し、標準化団体が体系化し、インシデントデータが要求するものです。残るのは、それをどれほど早く構築できるかだけです。
コンテキストこそが、新たな認証情報です。インテントこそが、新たな境界です。AIセキュリティの未来は、モデルセキュリティ、エージェントアイデンティティ、そしてデータ認可を単一の信頼連鎖に結びつけることによって構築できます。
これを解決するテクノロジーは、今日すでに存在します。okta.com/aiおよびauth0.com/aiで、OktaとAuth0がAIエージェントをどのように保護しているかをご覧ください。私たちがお手伝いします。私たちと協力してみませんか?
AIセキュリティに関するインサイトをもっと見る
- AIエージェントのセキュリティ:圧倒的な速度で自律的な信頼を構築するOktaによる7部構成のソートリーダーシップシリーズ。
- AIエージェントは、根本的な選択を迫ります。それは誤ったやり方です。アイデンティティは、それを拒否するための基本的な要素です。エージェントは、便利であるか、安全であるかのいずれか。