AIオーケストレーションフレームワークは、今や企業にとって重大なセキュリティ上の意思決定

Google Newsは8月6日、企業に向けた厳しい警告を取り上げた。AIオーケストレーションフレームワークを選ぶことは、攻撃者が自社システムへ到達できる場所を選ぶことにもなる。

CSO Onlineの見出しは、この選択を重大なセキュリティ上の意思決定として位置づけている。この捉え方が重要なのは、オーケストレーションソフトウェアがもはや言語モデル間のリクエストを振り分けるだけのものではないためだ。エージェントをデータベース、ブラウザ、コードリポジトリ、顧客記録、本番運用ツールへ接続できる。

対立の構図は明快だ。開発者は、エージェントの能力を高め、展開を容易にするフレームワークを求める。一方でセキュリティチームには、モデルが指示を誤解したり、悪意あるコンテンツを取り込んだり、誤ったツールを呼び出したりしても、確実に強制できる境界が必要となる。

この緊張関係は、もはや仮説上の脅威モデルの域を超えている。NISTによれば、多くのエージェントは間接的なプロンプトインジェクション、いわゆるエージェント・ハイジャックに依然として脆弱だ。この攻撃では、本来は正当なタスクを実行するエージェントが読み取るコンテンツの中に、悪意ある指示が隠される。

エージェントが行動できるようになると、改ざんされた指示はシステムイベントへと変わり得る。その結果、不正なメッセージ送信、ファイルの露出、レコードの改変、危険なインフラコマンドの実行などが起こりうる。

そのためGoogleの研究者と学術パートナーは、組織はエージェントを単に基盤モデルの性能を向上させる対象としてではなく、システムとして保護しなければならないと主張している。その分析は、最小権限、完全媒介、情報フロー制御、モデルの外部にある耐改ざん性の高い強制機構を重視している。

この立場は、多くのAIプロジェクトの現在の購買方法に疑問を投げかける。チームはしばしば、モデル対応、ワークフローテンプレート、メモリ機能、開発速度でフレームワークを比較する。これらの観点は重要だが、各アクションを誰が承認するのか、侵害されたワークフローをどう封じ込めるのかは明らかにしない。

その問いに答えるのがオーケストレーションフレームワークだ。これは確率的なモデル出力と決定論的な企業システムの間に位置する。この配置により、アーキテクチャ上の好みがセキュリティ境界へと変わる。

Google Newsの警告が実際に変えるもの

オーケストレーション層は、ベンダーが通常の開発者向けインフラとして提示している場合でも、特権的なコントロールプレーンになっている。

AIオーケストレーションフレームワークは、モデル、エージェント、ツール、データソース、メモリ、ワークフロー状態を調整する。どのコンポーネントがリクエストを処理し、どのコンテキストがコンポーネント間を移動するかを決定する。

この定義は運用上のものに聞こえる。しかし、フレームワークが認証情報を保存し、ツールを呼び出し、タスクを委任し、下流のアクションを承認する場合、セキュリティ上の影響が明らかになる。

従来のチャットボットは、人間が確認するためのテキストを返す。オーケストレーションされたエージェントは、受信トレイを確認し、契約書を取得し、顧客記録を更新し、別の従業員へ通知できる。アクションが増えるたびに、誤った、あるいは操作された指示が及ぼし得る影響も拡大する。

したがって重要な変化は、単一製品のリリースではない。行動を推奨するAIから、接続されたワークフローを実行するAIへの移行である。

NISTのハイジャック分析は、根本的な弱点を明確に説明している。モデルは、信頼された指示と信頼できないデータを同じ言語インターフェースを通じて受け取る。単なる命令のように見えるコンテンツと、実際の命令を区別することに苦労する場合がある。

受信したサポートチケットを要約するよう依頼されたエージェントを考えてみよう。あるチケットには、内部ファイルを取得して応答に含めるようエージェントへ指示する隠しテキストが含まれているかもしれない。高性能なモデルは、そのテキストをタスクの一部として扱う可能性がある。

次に何が起こるかは、オーケストレーターが決める。制約のあるフレームワークなら、ファイル要求を拒否し、ユーザーの権限を確認し、人間の承認を求められる。寛容なフレームワークなら、注入されたテキストを成功したツール呼び出しへ変えてしまう可能性がある。

このため、フレームワークの評価はモデル評価とは実質的に異なる。モデルベンチマークは、テスト条件下でのモデルの挙動を推定する。オーケストレーションレビューは、モデルが誤った動作をした場合に、周囲のシステムが何を許可するかを検証する。

この違いは責任の所在も変える。アプリケーションチームは、モデルプロバイダーがすべてのセキュリティ制御を担うと想定できない。モデルベンダーも、自らが運用していないデータベース、チケット管理プラットフォーム、クラウドアカウント、社内APIの内部で権限を強制することはできない。

オーケストレーション層を展開する企業は、こうした接続を管理する。したがって、結果として生じるID設計、権限境界、ログ要件、インシデント対応プロセスも所有することになる。

Google Newsが新たな脆弱性カテゴリを発見したわけではない。セキュリティ研究全体ですでに見られる変化を浮き彫りにした。エージェントのセキュリティは現在、単に悪意あるプロンプトに対するモデルの耐性ではなく、モデルを取り囲むアーキテクチャに左右される。

この点は、調達時の質問票を直ちに変えるべきだ。購入者は、フレームワークがエージェントをどのように認証し、認証情報をどのように制限し、ワークフローをどのように検証し、重大なすべてのアクションをどのように記録するかを尋ねる必要がある。

また、証拠も必要だ。ロールベースアクセス制御に対応しているというチェックボックスだけでは、制御がツール、メモリ、委任されたエージェント、バックグラウンドタスクをカバーしているかは分からない。

最も重要な機能は、フレームワークがデモをどれほど速く完了できるかではなく、デモが本番ワークフローになったときにもポリシーを維持できるかどうかだ。

AIオーケストレーションフレームワークのセキュリティが異なる理由

エージェンティックシステムは、不確実な推論と実際の権限を組み合わせるため、従来のアプリケーションセキュリティやモデルガードレールだけでは十分に対処できないリスクを生む。

従来のソフトウェアは、エンジニアが検査できるコードパスに従う。入力が脆弱性を引き起こすことはあっても、意図された実行ロジックは通常、ソースコードまたはコンパイル済みコンポーネントに存在する。

エージェントの振る舞いは異なる。モデルは実行時に計画を作り、コンテキストに基づいてツールを選択し、結果を観察した後に次のステップを調整する。似た二つのリクエストでも、異なる実行経路が生じ得る。

この変動性はテストを複雑にする。セキュリティレビューでは、固定された一つのワークフローを検査して、将来のすべての経路がそれに従うと想定することはできない。オーケストレーターは、アプリケーションチームが明示的に記述していない経路も含めて、ルールを強制しなければならない。

プロンプトフィルターだけでは、この保証を提供できない。悪意ある言語の特定を試みるが、攻撃者は表現、エンコーディング、文書構造、コンテキストを変えられる。無害なコンテンツが指示に似ている場合もある。

NISTの2026年レッドチーミング結果は、その難しさを示している。研究者らは、400人超の参加者から25万件超の攻撃試行があったと報告した。テスト対象となったすべての最先端モデルに対し、少なくとも一つの攻撃が成功した。

レッドチームの調査結果は、すべてのエージェントが必然的に侵害されることを意味するものではない。企業がモデルレベルの耐性を完全なセキュリティ境界として扱うべきではない理由を示している。

安全なオーケストレーション設計は、モデルがときに誤った判断を下すことを前提とする。そして外部制御により被害を限定する。

最小権限は、そのような制御の一つだ。エージェントには、ユーザーや開発者が持つすべての権限ではなく、現在のタスクに必要な権限だけを与えるべきである。

これは長年のセキュリティ原則であるため、聞き慣れたものだろう。タスクが動的に変化し、認証情報が委任ワークフローをまたいで移動する場合、これをエージェントに適用することは難しくなる。

顧客の苦情を調査するエージェントには、一件のサポートケースへの読み取りアクセスが必要な場合がある。しかし、すべての顧客記録に無制限にアクセスする必要はない。データベース全体をエクスポートする権限も不要だ。

完全媒介も、もう一つの重要な原則である。上流のエージェントがより広範なワークフローを以前に承認していたとしても、すべての機密性の高いアクションはポリシーチェックを通過すべきだ。

媒介がなければ、下流のツールは過剰な信頼を継承し得る。侵害されたオーケストレーターは、接続されたエージェントが独立した検証なしに受け入れるコマンドを発行できてしまう。

OWASPのエージェンティックセキュリティに関する資料は、集中型オーケストレーションを単一障害点となり得るものとして挙げている。そのガイダンスは、厳格な認証、署名付きワークフロー定義、下流エージェントによる独立したスコープ検証を推奨している。

そのオーケストレーションガイダンスは、個々のプロンプトから委任された権限の連鎖へと注目を移す。一つの弱いリンクが、それを信頼するすべてのエージェントに影響し得る。

情報フローも別の課題を生む。フレームワークが、エージェントによる機密情報の読み取りを適切に認可しても、その情報が後にどこへ送られるかを制御できない場合がある。

たとえば、リサーチエージェントは、権限を持つ従業員のために社内ロードマップを取得できるかもしれない。後続のツール呼び出しが、そのロードマップの一部を外部検索、分析サービス、公開メッセージに誤って送ってしまう可能性がある。

フレームワークは、アクセスと移動の両方を追跡しなければならない。情報を読む権限があることは、接続されたあらゆるチャネルを通じて開示する自動的な許可ではない。

メモリは境界をさらに複雑にする。エージェントメモリは、対話間で有用なコンテキストを保持できるが、汚染された指示、秘密情報、不正確な結論も保持し得る。

今日遭遇した悪意ある文書が、数日後のワークフローに影響を与える可能性がある。そのためセキュリティチームには、メモリの来歴、保持、分離、削除に関する制御が必要となる。

こうした要件は、フレームワークの選択が長期的な影響をもたらす理由を説明している。チームが共有認証情報と不透明なメモリを中心に数百のワークフローを構築した後では、ポリシー強制を後付けするのは難しい。

パイロット段階で最も速いフレームワークが、本番環境でセキュリティを確保するには最も遅いフレームワークになり得る。開発者の利便性は、後にすべてのツールと委任経路へセキュリティ制御を組み込む必要が生じると、負債となる。

本当の競争は能力と封じ込めの間にある

主な競争は、あるフレームワークと別のフレームワークの間ではない。エージェントの能力を拡張することと、エージェントが失敗した際にも封じ込めを維持することの間にある。

フレームワークベンダーは、より多くのシステムをエージェントが利用できるようにすることで競争している。コネクター、ブラウザ制御、コード実行、永続メモリ、マルチエージェント委任、自動リトライを追加している。

各機能はタスク完了率を改善し得る。同時に、それぞれがID、認可、データ処理ルールを維持しなければならない新たな場所を生み出す。

これは不都合な逆転をもたらす。オーケストレーションフレームワークを魅力的にする機能が、侵害時の影響を拡大する可能性もある。

ブラウザツールは、この問題をよく示している。エージェントが最新情報を調査し、Webアプリケーションを操作できるようにする。一方で、自動化された閲覧者を操作するために設計された信頼できないページにもエージェントをさらす。

コード実行も別の例だ。エージェントがデータを分析したり、プロジェクトを変更したりできるようにする。しかし、モデルの誤りをファイル変更、認証情報の露出、破壊的なコマンドへと変えてしまう可能性もある。

マルチエージェント委任は、専門エージェント間で作業を分割することでスループットを高める。しかし、どのIDがアクションを認可したのか、どのコンポーネントが有害な指示を提供したのかを不明瞭にする可能性がある。

オーケストレーションフレームワークは、その連鎖を維持しなければならない。セキュリティチームは、元のリクエスト、中間の判断、ツール引数、返されたデータ、最終的な副作用を再構築できる必要がある。

通常のアプリケーションログは、多くの場合、断片的な情報しか捉えない。あるツールはAPI呼び出しを記録しても、それを引き起こしたモデルのコンテキストを保持していないことがある。モデルのトレースは推論を示しても、外部システムで何が変更されたかを確認できない場合がある。

Googleと大学の研究者は、エージェントが計画、メモリ、外部ツール、実行を組み合わせるため、オペレーティング環境になぞらえて比較している。彼らの主張では、実施・強制の仕組みはモデルの外部に置かれる。

あるシステムセキュリティ分析は、実際に起きたエージェント攻撃11件を調査した。すべての攻撃が安全な情報フローの原則に違反し、その大半は最小権限の原則にも違反していた。

ここから得られる教訓は、モデルが無関係だということではない。より優れたモデルはミスを減らし、悪意ある要求をより多く拒否できる。しかし、すべての企業システムに対するアクセス方針を定義することはできない。

したがって、フレームワークは計画と実行を分離すべきである。モデルはアクションを提案できる一方、そのアクションを許可するかどうかは決定論的なポリシー層が判断する。

高リスクのアクションには、より厳格な扱いが必要だ。送金、コンテンツの公開、データの削除、権限の変更、コードのデプロイには、自然言語の指示とは別に明示的な制御を求めるべきである。

一部のアクションでは人間による承認が必要になる。他方、狭い制限の範囲内で自動実行できるものもある。適切な閾値は、可逆性、データの機密性、潜在的な影響によって決まる。

この階層的なアプローチは、有用な自動化を維持する。すべての検索クエリや文書要約について、人間の承認を強いるものではない。

むしろ、公開ウェブページを読むことと顧客データをエクスポートすることは異なると認識する。安全なフレームワークは、その違いを強制可能なポリシーとして表現すべきである。

モデル非依存のアーキテクチャは、慎重に実装すれば封じ込めを支援できる。組織は、すべての権限ルールやツール統合を作り直さずにモデルを置き換えられる。

ただし、モデルの可搬性が自動的にセキュリティをもたらすわけではない。多数のモデルをサポートするフレームワークでも、認証情報を一元化し、実行トレースを隠し、ツールへの広範なアクセスを付与する可能性がある。

オープンソースも完全な代替指標にはならない。ソースコードの公開はレビューやカスタマイズを改善できるが、安全な導入は依然として設定、保守、運用上の規律に左右される。

プロプライエタリなサービスは、より強力な管理型の分離を提供する可能性がある。一方で、実施・強制の挙動に対する可視性を制限することもある。購入者には、アーキテクチャ、テスト、契約上のコミットメントに基づく証拠が必要だ。

実務的な比較は、障害時の挙動に焦点を当てるべきである。チームは、エージェントが敵対的な指示に従った後、トークンを漏えいした後、または権限を超えて委任した後に何が起きるかを問う必要がある。

フレームワークは実行前にアクションを止められるか。影響を受けたワークフローを特定できるか。管理者は、すべてのエージェントを停止せずに認証情報を無効化し、メモリを隔離できるか。

より多くのタスクを完了できても、これらの問いに答えられないフレームワークは、信頼できる封じ込めを伴わない能力を提供している。そのトレードオフは、開発者の選定プロセスだけでなく、セキュリティレビューにも含めるべきである。

Google Newsの見出しでは購入者が検証できないこと

見出しは正しいリスクを示しているが、どのフレームワークについても、マーケティング上の約束どおりに制御を実際に強制していることまでは立証できない。

AIオーケストレーションをめぐるセキュリティ上の主張は、依然として比較が難しい。ベンダーは、ガバナンス、ガードレール、可観測性、エンタープライズ制御といった言葉を、統一された技術的定義なしに使っている。

ある製品はガードレールをプロンプトフィルターとして定義するかもしれない。別の製品は、各ツール呼び出しの前に決定論的な認可を行う場合がある。これらの制御が同等の保護をもたらすわけではない。

可観測性も同様に曖昧になり得る。フレームワークはトークン使用量とレイテンシーを表示しても、認証情報の受け渡し、メモリへの書き込み、ポリシー判断、下流での変更を省く可能性がある。

購入者は、障害事例を中心に組み立てたデモを求めるべきである。洗練された成功ワークフローから得られる封じ込めに関する情報は少ない。

有用なテストは、信頼できないコンテンツから始まる。チームは、権限を持つエージェントが処理すべき文書、メール、サポートチケット、ウェブページに敵対的な指示を埋め込める。

その後、レビュー担当者は、システムがそのコンテンツを信頼された指示から分離するかを観察すべきである。禁止されたツール呼び出しが、実行前にブロックされるかも確認すべきだ。

テストでは委任も検証すべきである。プライマリエージェントが、異なる権限を持つ専門エージェントに悪意ある要求を渡す場合がある。

下流のエージェントがオーケストレーターからのすべてのコマンドを信頼するなら、アーキテクチャは脆弱性を移動させるだけである。各エージェントには、独立して強制可能なスコープが必要だ。

認証情報の扱いにも同様の精査が必要である。長期間有効な共有シークレットは、侵害された1つのワークフローが無関係なタスクに影響し得るため、広範な露出を生む。

スコープを限定した短期認証情報は、その露出を減らす。フレームワークは、それらを特定のID、リソース、アクション、時間枠に結び付けるべきである。

セキュリティチームは再試行の挙動も調べるべきだ。自動再試行は一時的な障害からのワークフロー復旧を支援するが、安全でないアクションを繰り返したり、不適切に設計された承認プロセスを迂回したりする可能性がある。

失敗したトランザクションが、ポリシー実施をすり抜けるまでバリエーションを試すべきではない。再試行も同じ認可および冪等性の制御に従う必要がある。

監査記録には完全性保護が必要だ。オーケストレーション層を支配する攻撃者が、調査に必要な証拠を消去または書き換えられてはならない。

ログは、エージェントの権限外にあるシステムへ流すべきである。安定した識別子を通じて、プロンプト、ツール呼び出し、承認、ID変更、外部結果を結び付ける必要がある。

インベントリも未解決の問題だ。企業は、存在を把握していないエージェントを統制できない。

事業部門は、中央の調達プロセスを通さずにローカルフレームワーク、ブラウザーエージェント、自動化サービス、ソフトウェアプラグインを導入できる。このシャドー導入はポリシーを断片化し、データ移動を見えにくくする。

NISTは、間接的なプロンプトインジェクション、汚染されたモデル、敵対的な入力なしで起きる有害なアクションを含め、エージェントシステムの保護に関する情報を業界と研究者に求めている。

このエージェントセキュリティの取り組みは、未成熟な分野を反映している。組織がすでにエージェントを本番システムへ接続する一方で、標準は発展途上にある。

セキュリティ責任者は、確実性を過度に主張すべきではない。どのフレームワークも、プロンプトインジェクションが決して成功しないことや、すべての自律的な判断が正確であり続けることを保証できない。

擁護可能な主張は、より限定的である。外部での実施・強制、スコープを絞ったID、分離、監査可能な実行は、障害の発生可能性と影響を低減できる。

チームは自らの実装も評価しなければならない。適切なプリミティブを備えたフレームワークでも、開発者が承認を無効化し、管理者認証情報を使い回し、無制限のツールを公開すれば危険になり得る。

ここではドキュメントの品質が重要になる。開発者には、安全なコネクター、ポリシーテスト、認証情報ローテーション、メモリ分離、インシデント対応の明確なパターンが必要だ。

組織的な知識も重要である。エージェントのワークフローは、内部ポリシー、技術文書、過去の判断に依存しており、それらはしばしば分断されたシステムにまたがって存在する。

統制されたエンジニアリングナレッジベースは、検索と取得の規律を改善できるが、検索と取得は認可に取って代わるものではない。関連情報も、承認された境界の内側にとどめなければならない。

したがって、懐疑的な結論が重要である。適切なフレームワークを選ぶだけでは、エージェントセキュリティは解決しない。それは、チームが問題を解決するために必要な制御を持てるかどうかを決める。

セキュリティチームが次に注視すべき3つの兆候

次の段階を決めるのは、強制可能なエージェントID、独立してテストされたオーケストレーション制御、そして測定可能な本番導入である。

最初の兆候は、ソフトウェアおよびAIエージェント向けのID・認可標準における進展である。

人間向けのIDシステムは、個人が認証し、その後に承認済みのアプリケーションを利用することを前提としている。エージェントシステムには、サブエージェントの作成、サービスの呼び出し、ユーザー不在時の行動が可能な委任IDが導入される。

セキュリティチームには、各エージェント、その所有者、現在のタスク、許可された委任深度を信頼性高く識別する方法が必要だ。また、人間の要求者が持つすべての権限を暗黙に継承しない認証情報も必要になる。

機械可読なエージェントIDと、タスクにスコープを限定した認可を定義する標準に注目すべきである。主要クラウドプラットフォームやエンタープライズソフトウェアプロバイダーによる採用は、公開そのものより重要になる。

フレームワークが、検証可能な委任チェーンを備えた相互運用可能な短期認証情報を実装し始めれば、この兆候は中心的な主張を補強する。IDがアプリケーション固有の寄せ集めにとどまれば、主張を弱めることになる。

2つ目の兆候は、個別モデルではなくエージェントシステム全体を測定する独立したセキュリティテストである。

現在の評価では、モデルが悪意あるプロンプトに従うかどうかをテストすることが多い。本番環境のリスクは、ツールの権限、メモリ、ワークフローのルーティング、分離、ポリシー実施にも左右される。

将来のベンチマークでは、攻撃が実際の未認可な影響を引き起こしたかを報告すべきである。モデルが安全でないテキストを生成することと、オーケストレーションされたシステムが禁止されたアクションを完了することを区別すべきだ。

NISTの大規模テストは初期の基盤を提供している。OWASPの検証作業も、オーケストレーションと自律的なアクション全体にわたり、エージェントのリスクをテスト可能な制御へと変換している。

新たに登場した検証標準は、監査や侵入テストのための、より具体的な基盤を組織に与える。フレームワークベンダーは、自社の制御を、購入者が検証できる要件に対応付けるべきである。

独立テストによってフレームワーク間の意味ある差異が明らかになれば、この兆候は記事の判断を補強する。現実的な攻撃条件下で大半の製品が区別できないままであれば、判断を弱めることになる。

3つ目の兆候は、企業がパイロットプログラム後にエージェントをどのように拡大するかである。

5人の開発者が10のワークフローを運用する環境では、フレームワークは安全に見えるかもしれない。何千人もの従業員がツール、データ、メモリを共有するエージェントを作成するようになると、ガバナンス上の圧力は高まる。

セキュリティチームは、本番エージェント数、有効なツール接続数、ブロックされたポリシー違反、人間による承認、認証情報の露出、インシデント対応演習を追跡すべきである。

また、エージェントをどれだけ迅速に隔離できるかも測定すべきだ。封じ込めまでの平均時間は、プロンプトフィルターのアラート数を数えるより有用になる。

インベントリの網羅性も、もう1つの実務的な指標となる。中央集権的なガバナンスを主張する企業は、どのエージェントが存在し、誰が所有し、どのシステムを変更できるかを把握しているべきである。

エージェント導入の拡大に伴い、Google Newsは今後も製品発表やセキュリティ警告を取り上げ続けるだろう。読者は、そうした記事をモデルの下にあるコントロールプレーンを通して評価すべきである。

決定的な問いは運用面にある。フレームワークはすべてのツールで最小権限を強制できるか。委任を通じてIDを維持できるか。調査担当者は、侵害されたエージェントを信頼せずにアクションを再構築できるか。

オーケストレーションフレームワークを選ぶ組織は、自律性を拡大する前にこれらのテストを実行すべきである。敵対的な文書、委任されたタスク、禁止されたツール呼び出しから始める。

次に、アクションが正確にどこで停止したのかをフレームワークに示させる。明確な答えを提供できないなら、そのアーキテクチャは重大な業務に対応できる状態ではない。

調達文書でワークフローインフラストラクチャとして表現されていても、セキュリティ上の判断はすでにそこに存在する。オーケストレーターを特権的なコントロールプレーンとして扱い、その障害時の挙動をテストし、影響の大きい実行は検証可能なポリシーの背後に置くべきである。