CrowdStrike Blueprint Alliance、AIエージェントのアイデンティティ格差に対しベンダー連携を推進
CrowdStrikeは、企業がもはや避けられない対立を軸に結成された新たなアライアンスに、創設ベンダー11社とともに参加した。AIエージェントは有用であるために幅広いアクセスを必要とする一方、そのアクセスゆえに統制が難しくなる。CrowdStrike Blueprint Allianceは、共通のセキュリティアーキテクチャによってこの隔たりを埋めることを目指す。
正式名称をBlueprint Allianceとするこの連合は、2026年9月22日に発足した。参加企業は、アイデンティティ、クラウドインフラ、サイバーセキュリティ、データプラットフォーム、アプリケーション開発、エンタープライズソフトウェアにまたがる。この広がりは重要だ。エージェントは一つのタスクを完了する間に、これら複数の領域を横断し得るためである。
この発表は、CrowdStrikeによるAIエージェントセキュリティの新たな提携にとどまらない。企業予算をめぐって競合するベンダーに、共通の運用モデルを支持するよう求めるものだ。そのモデルでは、エージェントを識別可能な主体として扱い、権限を限定し、委任を追跡可能にし、継続的な監視と可逆的な封じ込めを行う。
より難しい問いは、共有された原則が相互運用可能なコントロールへと発展するかどうかである。企業に必要なのは、用語についてのベンダー間の合意だけではない。もともと一つのシステムとして設計されていない製品群にまたがり、一貫した検出、認可、ログ記録、停止の挙動が求められる。
CrowdStrike Blueprint Alliance、エージェントスタックの12領域を接続
このアライアンスは、AIエージェントセキュリティを製品単位の機能から、ベンダー横断のアーキテクチャ課題へと変える。
12の創設メンバーは、AWS、CrowdStrike、Databricks、Docker、Google Cloud、Lovable、Okta、Proofpoint、Salesforce、ServiceNow、Wiz、Zscalerである。GE AppliancesとWorld Central Kitchenは戦略アドバイザーを務める。
公式のアライアンス発表によれば、メンバーはオープンなマルチベンダーのリファレンスアーキテクチャを開発する。この取り組みは、Oktaが2026年3月に初めて提示したセキュリティブループリントを拡張するものだ。
このアーキテクチャは、4つの運用上の問いから始まる。
組織内のエージェントはどこに存在するのか？
各エージェントは何を実行できるのか？
各エージェントは何を実行しているのか？
防御側はどのように対応すべきか？
これらの問いは基本的に聞こえる。しかし大半の企業は、クラウドアカウント、ソフトウェアプラットフォーム、開発環境、データシステム、従業員が導入したツールにまたがって、一貫して答えることができない。
AIエージェントとは、目標を解釈し、コンテキストを収集し、ツールを選択し、限定的な監督の下で行動できるソフトウェアである。顧客サービスエージェントであれば、サポートチケットを読み、アカウント履歴を確認し、返金を承認して、CRMレコードを更新するかもしれない。
各ステップには異なる制御ポイントが生じる。エージェントは認証前にアイデンティティを必要とする。顧客レコードにアクセスする前には認可が必要だ。タスクの実行中は、その行動を監視しなければならない。タスク終了時にはアクセスを取り消す必要がある。
創設原則はこの順序を反映している。メンバーは、すべてのエージェントに人間の認証情報を借用させるのではなく、独立したアイデンティティを付与すべきだとしている。アクセスは恒久的に与えるのではなく、タスクに限定すべきだ。あるエージェントが別のエージェントを呼び出す場合にも、委任は追跡可能でなければならない。
アライアンスは継続的なランタイム監視も求めている。ランタイム監視は、実行前の承認だけに頼るのではなく、エージェントが稼働中に何を行うかを観察する。挙動が危険になった場合、封じ込めは即時かつ可逆的であるべきだ。
CrowdStrikeは、エンタープライズセキュリティにおける検知・対応の側面からこの枠組みに加わる。Oktaはアイデンティティ制御を担い、AWSとGoogle Cloudはインフラを代表する。SalesforceとServiceNowは、エージェントが業務アクションを開始できるアプリケーション環境を運用している。
Databricksはデータインフラを担い、DockerとLovableは開発・デプロイのワークフローに関わる。Proofpoint、Wiz、Zscalerは、通信、クラウド露出、ネットワークアクセスに関する制御を加える。
こうした役割分担は、単独のメンバーだけではアーキテクチャ全体を提供できない理由を示している。アイデンティティプラットフォームはエージェントを認証できても、下流のすべてのアクションを自動的に把握することはできない。エンドポイントまたはクラウドセキュリティ製品は、疑わしい挙動を検知できても、上流のすべての権限を制御できるわけではない。
したがってアライアンスは、信頼できる現状認識から出発している。エージェントセキュリティは、異なるチームが所有し、異なるベンダーが提供するシステムにまたがる。未解決の問題は、それらのベンダーがガバナンスを継続的なものにするほど深くコントロールを接続できるかどうかである。
AIエージェントが既存のアクセス問題をより速い障害へ変える理由
エージェントは権限を再利用し、アクションを連鎖させ、人間のセッションより長く動作できるため、従来のアイデンティティの弱点を増幅させる。
従来のエンタープライズ自動化でも、すでにサービスアカウント、APIキー、ワークロードアイデンティティが使われている。セキュリティチームは、所有者が不明確だったり、権限が無期限に有効なままだったりする場合に、これらの認証情報がどれほど扱いにくくなるかを理解している。
AIエージェントは、この既存の問題に不確実な意思決定経路を加える。次の行動は、モデル出力、取得したコンテンツ、ツールの応答、あるいは別のエージェントが与えた指示に左右される可能性がある。ソフトウェアは、掲げる目標を変えずに経路を変更できる。
この柔軟性こそがエージェントの有用性の源泉である。同時に、広範かつ恒常的なアクセスが特に深刻なリスクとなる理由でもある。侵害または操作されたエージェントは、オペレーターの意図から逸脱したまま、有効な権限を利用できる。
NISTはこのアイデンティティ問題を優先課題として特定している。同機関のエージェント標準化イニシアチブは、自律型エージェントに関するセキュリティ、アイデンティティ、相互運用性、業界主導の標準を対象とする。
同機関はエージェントを、メール、カレンダー、ソフトウェア開発、ショッピングなどのワークフローにまたがって自律的に行動できるシステムと説明している。その有用性は、外部システムや内部データとの接続に依存している。
こうした接続はいくつもの重なり合う問いを生む。組織はエージェントと、それを起動した従業員を区別できるのか。エージェントの所有者とソフトウェアの出所を識別できるのか。特定の行動を支えた権限を証明できるのか。
認証情報の共有は、これらの問いへの回答をさらに難しくする。従業員が個人のエンタープライズトークンを使ってアシスタントを接続することがある。下流のアプリケーションには、エージェントが行動を選択・実行した場合でも、従業員のアイデンティティが表示される。
この仕組みは説明責任を弱める。アプリケーションは有効なユーザーリクエストを記録しても、特定の取引を人が承認したかどうかを明らかにできない可能性がある。セキュリティ調査担当者は技術的には正確なログを受け取るが、最も重要なコンテキストが欠けている。
エージェントが作業を委任するとリスクは高まる。主エージェントが専門エージェントを呼び出し、そのエージェントが別サービスを介してツールを起動する場合がある。転送のたびに、元のユーザー、承認済みのタスク、残されたスコープが不明瞭になる可能性がある。
タスク単位のアクセスは、より適したモデルを提供する。エージェントには一つの任務に必要なリソースとアクションだけを与える。権限は、タスクが完了したとき、大きく変化したとき、または定義済みの条件に違反したときに失効する。
ただし、必要な経路を完全には予測できない場合、最小権限の実現は難しくなる。リサーチエージェントは、作業を始めた後にデータソースが必要だと判断するかもしれない。考え得るすべての権限を与えれば、タスクスコープの目的を損なう。
そのため企業には動的な認可が必要になる。ワークフローの変化に応じて、ポリシーシステムはアイデンティティ、タスク、リソース、コンテキスト、要求されたアクションを評価しなければならない。高リスクのステップでは、すべての日常的なアクションを止めることなく、新たな承認を求められる。
これが、実務的な観点から説明したBlueprint Allianceの背景にある圧力である。企業は、断片化されたソフトウェア環境を横断して行動できるエージェントを求めている。セキュリティチームは、そのアクションがあらゆる受け渡しで帰属可能かつ制限されたままであることを必要としている。
主なトレードオフは、有用なアクセスと制御可能な権限の間にある
アライアンスが成功するのは、すべてのワークフローを繰り返しの人手承認に還元することなく、エージェントの権限を制限できる場合に限られる。
システムへのアクセスを持たないエージェントは、会話型インターフェースにすぎない。無制限のアクセスを持つエージェントは、監視されない管理者になり得る。エンタープライズ導入は、この二つの極端な状態の間で運用されなければならない。
週次の営業報告を作成するエージェントを考えてみよう。CRMレコードを読み、製品データを取得し、最近の会議を分析し、提案を下書きし、要約を投稿するかもしれない。このワークフローは、複数のシステムと事業チームが所有する情報を横断する。
エージェントに必要なのは、顧客レコードを削除したり営業エリアを変更したりする権限ではない。アカウント詳細への読み取りアクセスは必要かもしれないが、一つの文書を公開するための権限は一時的なものでよい。そのスコープはタスクに従うべきである。
アイデンティティは、こうした判断の基盤となる。組織には、エージェント、その所有者、開発者、承認済みの能力に関する一意の記録が必要だ。このアイデンティティは、エージェントが作業の一部を委任する場合にも可視性を保たなければならない。
NISTのアイデンティティに関するガイダンスは、エージェントが一意の識別子、認証情報、エンタイトルメントを持つべきだとしている。これらの属性は、エージェントを運用する人物またはシステムとのつながりを維持すべきである。
既存技術は基盤の一部を提供する。OAuthはパスワードを共有せずに限定的なアクセスを委任できる。ワークロードアイデンティティシステムはソフトウェアプロセスを認証できる。ポリシーエンジンは、定義された条件に照らしてリソースアクセスを評価できる。
しかし、これらのツールがエージェントの意図を自動的に捉えるわけではない。有効なトークンは、ソフトウェアがAPIを呼び出す権限を持っていたことを示せる。しかし、結果として生じたアクションが、ユーザーが承認したタスクと一致していたことを証明するものではない。
この違いは、認証とガバナンスを分ける。認証は、認証情報を提示した主体が誰または何であるかに答える。認可は、そのアイデンティティが何を実行できるかを決定する。ガバナンスは、これらの権限を所有者、目的、監督、レビューに結び付ける。
ランタイムの挙動はさらに別の層を加える。エージェントはポリシーの範囲内で開始しても、文書から悪意のある指示を取得する可能性がある。間接プロンプトインジェクションは、エージェントが処理するよう求められたデータを通じて、信頼できないコンテンツがモデルを操作する際に発生する。
安全なアーキテクチャは、実行前の承認だけでは不十分だと想定しなければならない。監視は、エージェントのアクションを、宣言されたタスクおよび許容された境界と比較すべきである。防御側には、実行を一時停止または終了する能力も必要だ。
可逆性は特に重要である。エージェントを停止すれば追加のアクションは防げるが、メッセージ、データベース変更、外部取引を取り消すことにはならない。基盤となるアプリケーションが対応する場合、システムにはロールバック機構が必要になる。
一部のアクションは元に戻せない。漏えいした秘密情報を再び非公開にはできない。組織外へ送られた支払いは、すぐには戻らない可能性がある。破壊的なコマンドは、監視がアラートを生成する前にデータを消去する可能性がある。
Blueprint Allianceは、単一のコントロールでこうしたアプリケーション固有の制約を解決することはできない。製品間でアイデンティティ、認可、テレメトリ、対応シグナルを交換する方法は定義できる。それでも各プラットフォームは、該当するアクションを自ら強制しなければならない。
だからこそ、中心的な緊張関係は単純な技術的ギャップではなく、トレードオフなのである。より広いアクセスは、エージェントが達成できることを増やす。より強い制限は露出を減らす一方、ワークフローを中断し、承認の負担を増やす可能性もある。
最良の形は、無制限の自律性でも常時の人間確認でもない。低リスクの行動は進め、慎重さを要する段階ではより厳格なチェックを発動する、条件付きの自律性である。12社のベンダーにまたがってそのバランスを実現するには、原則への合意だけでは足りない。
CrowdStrike AI Agent Securityは複数のアライアンスにまたがる
CrowdStrikeは広範なエージェントセキュリティの地位を築こうとしているが、重複する連合は成果物に関する混乱も生み得る。
Blueprint Allianceは、CrowdStrikeが2026年初頭に参加したOpen Secure AI Allianceとは別の取り組みである。名称は似通っており、いずれもAIセキュリティを扱うが、公表されているアプローチは異なる。
CrowdStrikeは7月27日、オープンセキュリティ連合の発足時パートナーであると説明した。Nvidiaが支援するこの取り組みは、オープンモデル、共同研究、セキュリティツール、評価、共同防衛を重視している。
Blueprint Allianceは、エンタープライズエージェント向けのマルチベンダー・アーキテクチャに、より狭く焦点を当てる。中心となるテーマは、検出、アイデンティティ、スコープを限定したアクセス、追跡可能な委任、ランタイム監視、封じ込めである。
CrowdStrikeは独自のエージェント構築・セキュリティ製品も提供している。Charlotte AI AgentWorksでは、組織がFalconプラットフォーム内でカスタムセキュリティエージェントを構築できる。CrowdStrikeによれば、この環境にはガバナンスとガードレールが含まれる。
同社のAgentWorks ecosystemは、複数のプロバイダーによるモデルとインフラをサポートしている。これはCrowdStrikeに、エンタープライズエージェントを統治するルールへの直接的な商業的利害をもたらす。
製品、二者間パートナーシップ、連合にまたがる参加は、CrowdStrikeの影響力を強め得る。オープンなセキュリティ研究からエンタープライズでの施行まで、複数層の技術議論にアクセスできるためだ。
一方で、注目を分散させる可能性もある。企業はいま、複数のアライアンス、フレームワーク、製品アーキテクチャ、提案中の標準に直面している。似た用語が使われていても、互換性のある実装が保証されるわけではない。
リファレンスアーキテクチャは、コンポーネントとその関係性を文書化する。必ずしもプロトコル、認証、テストスイート、または本番統合を提供するものではない。購入者は、アーキテクチャ上の合意と、実証された相互運用性を区別すべきである。
Blueprint Allianceの広がりは、メンバーが各システム間の実際に機能する接続を提供するなら強みとなる。各ベンダーが共通の技術的振る舞いなしに、既存製品へ原則を当てはめるだけなら、弱みになる。
例えば、すべてのメンバーがエージェント検出という考え方を支持しながら、異なる識別子やインベントリ形式を使うことはあり得る。すべてのメンバーが封じ込めを支持しながら、互換性のない停止制御を公開することもあり得る。
グループには具体的な定義が必要になる。何をエージェントと見なすのか。一時的なサブエージェントはどのように登録されるのか。権威あるアイデンティティを保有するシステムはどれか。委任された権限は、クラウドとアプリケーションの境界をまたいでどのように移動するのか。
共通のイベントモデルも必要だ。ある製品が別の製品のテレメトリーを解釈できなければ、ランタイム監視の有用性は低くなる。チームが無関係なログからアイデンティティと認可の連鎖を再構築しなければならない場合、インシデント対応は遅くなる。
独立した検証も重要になる。創設ベンダーには、自社プラットフォームを中心に新興市場を形成するインセンティブがある。参加は価値があるが、顧客、研究者、標準化団体によるテストの代わりにはならない。
戦略アドバイザーであるGE AppliancesとWorld Central Kitchenは、この取り組みを実際の運用に結び付け続ける助けになり得る。製造環境、人道支援の物流、エンタープライズソフトウェアでは、遅延、自律性、障害に対する許容度がそれぞれ異なる。
とはいえ、2つのアドバイザーだけであらゆる導入モデルを代表することはできない。金融取引、医療ワークフロー、ソフトウェア開発、消費者向けエージェントには、それぞれ異なる説明責任の要件がある。アーキテクチャは曖昧にならずに適応可能でなければならない。
企業の購入者にとって、慎重な対応は、前提を置かずに関心を持つことだ。メンバー一覧は、大手ベンダーが共通の問題を認識していることを示している。しかし、それらの製品が統治された一つのシステムとして機能することを、まだ証明してはいない。
リファレンスアーキテクチャは、まだ強制力のある標準ではない
最大の不確実性は、アライアンスがベンダーに沿った設計文書ではなく、テスト可能なインターフェースを公開するかどうかにある。
発足発表は、原則と連合の構造を定めている。必須の標準を定めたわけではない。また、認証機関や拘束力のあるコンプライアンス手続きについても説明していない。
この区別は重要である。任意のアーキテクチャは、製品の振る舞いを変えずに計画を改善し得る。企業は、最小権限や継続的監視といった広い概念との整合性を主張できる一方で、それらを異なる形で実装できる。
アライアンスが想定する規模についても、慎重な帰属が必要だ。発表では、世界のFortune 500企業の平均が2028年までに15万を超えるエージェントを利用するというGartnerの予測を引用している。また、適切なガバナンスを持つと考える組織はわずか13%だとしている。
これらの数値は、連合の発表を通じて提示されたものだ。エージェント数が急速に増加したとしても、エージェントの定義は合計数に大きく影響する。常駐型アシスタント、短命のサブエージェント、自動化、ツール呼び出しは、同じように数えるべきではない。
組織がその規模に近づくはるか前から、検出は難しくなる。従業員は中央での導入を経ずに外部アシスタントを認可できる。開発者はテスト中に一時的なエージェントを作成できる。SaaS製品は通常のアップデートを通じて組み込みエージェントを追加できる。
したがって、インベントリには複数のシグナルを組み合わせる必要がある。アイデンティティシステムは認証情報とアプリケーション権限を示せる。クラウドプラットフォームはワークロードを示せる。セキュリティツールはプロセス、ネットワークアクティビティ、APIの振る舞いを観測できる。
単一のシグナルで、すべてのエージェントを確実に把握することはできない。エージェントは短時間しか存在しない場合があり、共有認証情報を使う場合があり、別のアプリケーション内で動作する場合もある。これが、アライアンスのマルチベンダー構造が理にかなう理由である。
ただし、相互運用性は独自の信頼問題ももたらす。ベンダーは、どのアイデンティティデータ、認可コンテキスト、行動テレメトリーを交換するか決めなければならない。顧客は、プラットフォーム間を移動する機密情報の量を制御する必要がある。
誤検知も別のリスクとなる。監視が異常な行動を誤読すれば、自動的な封じ込めによって正当な業務が中断される可能性がある。封じ込めが弱ければ、危険なエージェントが活動を続ける。アーキテクチャには、影響度と確信度に応じて対応を調整する手段が必要だ。
人間による統制も慎重に設計する必要がある。すべての判断に承認を要求すれば、生産性向上の恩恵の多くが失われる。運用担当者が広範なカテゴリーを承認できるようにすれば、別の名称で常設アクセスを再現しかねない。
連合は測定可能な特性を定義すべきである。参加製品は、引き継ぎをまたいで委任履歴を維持できることを証明できる。別のテストでは、権限を取り消した場合に、接続済みサービス全体で所定の時間内にアクセスが停止することを検証できる。
テストスイートがあれば、顧客は実装を比較できる。共有スキーマは、プラットフォーム間でインベントリとアクティビティデータを交換する助けになる。認証は、完全なセキュリティを示唆することなく、製品がベースライン要件を満たすことを示せる。
アライアンスは障害時の振る舞いも文書化すべきである。セキュリティアーキテクチャは、意図された経路を説明する一方で、利用できないポリシーサービス、遅延するテレメトリー、部分的な権限取り消しにはあまり注意を払わないことが多い。
ある制御に到達できなくなったために、エージェントがより広い権限を得るべきではない。しかし、デフォルト拒否の対応は、不可欠な業務プロセスを停止させる可能性がある。適切な障害モードは、タスクとその結果に依存する。
こうした仕組みが現れるまでは、Blueprint Allianceは、検証済みのセキュリティ層ではなく真剣な提案であり続ける。その価値は、適切なベンダー群を適切な問いの周りに整列させることにある。その整合性がリスクを変えるかどうかは、実行によって決まる。
アライアンスが成果を出せるかを示す3つのシグナル
次の試金石は新たな加盟発表ではなく、独立して運用される製品間でアーキテクチャが機能するという証拠である。
第1のシグナルは、公開された技術仕様である。アライアンスは、エージェントのアイデンティティフィールド、委任記録、認可コンテキスト、テレメトリー形式、対応インターフェースを定義すべきだ。
詳細な仕様があれば、メンバーが共有統制を構築する意図を持つという見方が強まる。製品固有のマッピングを伴う高レベルのフレームワークであれば、顧客は依然としてカスタム統合を必要とするため、その見方は弱まる。
第2のシグナルは、実際に機能するマルチベンダーのデモンストレーションである。信頼できる例では、一つのエージェントをアイデンティティ、クラウド、データ、アプリケーション、セキュリティの各システムにわたって追跡できるべきだ。
デモンストレーションでは、タスク範囲に限定した権限、委任された作業、ランタイム監視、権限取り消しを示すべきである。また、安全でない行動の後に、調査担当者がどのように連鎖を再構築するかも示す必要がある。
この証拠によって、CrowdStrike AI agent securityが他のアライアンスメンバーからアイデンティティとアクティビティのコンテキストを取り込めるかが明らかになる。また、それらのシステムがCrowdStrikeの検知に基づいて行動できるかも示される。
第3のシグナルは、独立したテストである。NIST、エンタープライズの設計パートナー、セキュリティ研究者、または別の中立的なグループが、アーキテクチャが認証情報の共有、間接的なプロンプトインジェクション、過剰な権限、侵害されたエージェントをどのように扱うかを評価すべきだ。
独立した結果は、アライアンスのセキュリティ上の主張を強める。テストの遅延、非公開のデモンストレーション、または自己認証だけでは、中心的な疑問は解決されない。
購入者は、自らの統制を改善する前に待つ必要はない。現在のエージェントを棚卸しし、共有認証情報を排除し、明確な所有者を割り当て、恒常的な権限を狭めることができる。
チームはまた、どの行動に人間の承認が必要で、どの行動を自動的に進められるかを文書化すべきである。すべての機密性の高いワークフローには、エージェント、ユーザー、タスク、権限、ツール、結果を結び付けるログが必要だ。
社内エージェントを構築する組織は、検索可能なAI knowledge baseに、ソース資料、承認、運用上の判断を保持できる。この記録はセキュリティテレメトリーの代替にはならないが、エージェント導入の背景にあるビジネスコンテキストを保存する助けにはなる。
CrowdStrike Blueprint Allianceが重要なのは、企業に欠けているコントロールプレーンを特定しているためだ。エージェントは、検出可能で、個別に識別可能で、狭く認可され、継続的に監視され、迅速に封じ込め可能でなければならない。
メンバーは今、その合意を相互運用可能な振る舞いへと変換する必要がある。エンタープライズチームは、ベンダーにスキーマ、テスト、権限取り消しの保証、クロスプラットフォームのデモンストレーションを求めるべきだ。その回答によって、アライアンスが共有インフラを構築しているのか、それとも単に共通の語彙を共有しているだけなのかが明らかになる。
