ThalesとGoogle CloudのAIセキュリティが制御を追加、自律性がリスクを高める
Thalesは9月28日、Google Cloudとの提携を拡大し、自律システムをガードレールでどこまで確実に制御できるかという未解決の問題を抱えるなか、AIエージェント向けのセキュリティ制御を追加した。Thales Google Cloud AI securityの統合では、Thales AI Security FabricとGemini Enterpriseを接続する。対象となるのは、ユーザー、エージェント、モデル、企業データ、外部ツールの間で生じるやり取りだ。
この発表は、エンタープライズAIにおけるより大きな変化を示している。従来のアシスタントは、主に人が確認するための回答を生成していた。現在のエージェントは、ツールを選択し、機密性の高い記録を取得し、APIを呼び出し、業務システムを変更できる。そのため、悪意ある指示や過剰な権限は、単に不適切な応答を生むだけでなく、運用上のインシデントにつながり得る。
Google Cloudはすでに、エージェントとツール間の接続を制御するポイントとしてAgent Gatewayを提示している。Thalesはその接続の周囲に、検査、ポリシー適用、脅威検知を加える。この提携は、エンタープライズ向けエージェントのセキュリティ層を定義しようとするMicrosoft、Zscaler、Palo Alto Networksなどと同じ戦略的な競争領域に位置する。
中心的な問いは、AIエージェントに追加の保護が必要かどうかではなくなった。政府のガイダンスや独立したセキュリティ研究によって、その点はすでに明らかになっている。真の課題は、統合されたランタイム層が、導入を正当化できないほどエージェントを遅く、高コストに、あるいは機能制限の多いものにせず、一貫して制約をかけられるかどうかだ。
Thales Google Cloud AI Security統合によって変わること
この提携により、AIシステムがデータを読み取り、ツールを選び、または操作を試みる瞬間に、エージェントセキュリティがより近づく。
セキュリティに関する発表によると、Thales AI Security FabricはGoogle Cloud Gemini Enterpriseと統合される。Thalesによれば、この統合システムは、ユーザー、エージェント、モデル、ツール、企業情報に関わる通信全体に対して、可視性、ガバナンス、セキュリティポリシーを適用できるという。
想定される対象範囲には、エージェント型ワークフローの複数の段階が含まれる。システムは、エージェントに入るトラフィックを検査し、エージェントとモデル間のやり取りを観測し、外部ツールへの呼び出しを監視できる。また、エージェントがアクセスできる情報や実行できる操作に制限を適用することも目指している。
こうした区別が重要なのは、エージェントが孤立した単一のモデルセッションではないためだ。エージェントは、意思決定、認証情報、データソース、ソフトウェアインターフェースの連鎖である。引き継ぎのたびに、攻撃者、設定ミス、または信頼性の低いモデル判断が結果を変え得る新たな箇所が生まれる。
Thalesは、プロンプトインジェクション、データ漏洩、安全でない出力、未許可の操作、エージェント間通信を主要なリスクとして挙げている。プロンプトインジェクションは、コンテンツに埋め込まれた敵対的な指示がモデルの挙動を操作することで発生する。メール、文書、ウェブサイト、ツール応答には、ユーザーが気付かないままそうした指示が含まれる可能性がある。
この提携が提示する対応策は、統合された適用レイヤーだ。Thalesによれば、そのFabricはAI特有の脅威を検出し、エージェントの挙動を可視化し、組織ポリシーに違反する操作をブロックできる。さらに同社は、一元化された記録を、コンプライアンスレビューやインシデント調査の支援として位置付けている。
Thalesが示した保険の例を考えてみよう。保険金請求の処理を支援する権限を持つエージェントが、承認済みの情報源以外から個人情報を取得する可能性がある。支払額の計算自体が妥当に見えても、そのワークフローはプライバシー、公平性、コンプライアンスの問題を引き起こし得る。
ランタイム制御は、ワークフローの継続を許可する前に、要求されたデータソース、エージェントに割り当てられた役割、提案された操作を確認できる。要求を拒否し、試行されたアクセスを記録し、あるいは人による承認を求めることが可能だ。これは、ユーザーが送信したプロンプトだけをフィルタリングするセキュリティモデルとは異なる。
この統合は、Google Cloudのより広範なエージェントアーキテクチャにも基づいている。Agent Gateway ecosystemは、ユーザーからエージェント、エージェント間、エージェントからツールへのトラフィックを対象に、ガバナンスされた接続を提供する。Googleはこのゲートウェイを、複数のセキュリティプロバイダーと連携できるオープンな制御ポイントとして説明している。
したがってThalesは、Google Cloudのネイティブ制御を置き換えるわけではない。より広範なアーキテクチャの中で、専門的な検査・適用レイヤーを提供する。その価値は、どれだけ追加のコンテキストを分析できるか、そしてリスクのある活動が業務システムに到達する前にどれだけ確実に介入できるかに左右される。
AIエージェントにモデルのガードレールを超える制御が必要な理由
システムが認証情報を保持し、人による即時のレビューなしに行動できる場合、モデルが安全な応答を返しても、ワークフローの安全性は保証されない。
従来の生成AIセキュリティは、しばしばコンテンツに重点を置く。組織は、有害な回答、機密データの露出、不適切なプロンプトを防ごうとする。これらの懸念は依然として重要だが、エージェントは別のリスク分類、すなわち現実的な影響を持つソフトウェア操作をもたらす。
エージェントは指示を受け、計画を作成し、ツールを選び、取引を実行できる。メッセージの送信、顧客記録の編集、返金の承認、ソースコードの変更、インフラ変更の開始などが可能だ。人が中間の推論を確認する前に、誤りが広がる可能性がある。
この違いが、ランタイム認可が中心的なものになりつつある理由を説明する。ポリシーは、エージェントが何を言うかだけでなく、どのアイデンティティを使用し、どのリソースを要求し、その操作が割り当てられたタスクに適合しているかも評価すべきだ。ワークフローが方向を変えるたびに、この判断を再び行う必要があるかもしれない。
エージェントが連携する場合、問題はさらに難しくなる。あるエージェントが情報を収集し、別のエージェントが推奨を行い、3つ目が操作を実行することがある。侵害されたコンポーネントは、操作されたコンテキストや要求を連鎖の残りに渡す可能性がある。
Thalesは、自社の制御がこうしたエージェント間のやり取りも対象にすると述べている。この約束は重要なギャップに対処するものだが、その価値は実装の詳細によって決まる。セキュリティチームは、アイデンティティの検証方法、委任された権限の表現方法、複数のエージェントにまたがるタスクをポリシーがどのように追跡するかを知る必要がある。
NISTも同じ問題を指摘している。2026年5月のエージェントセキュリティ分析では、エージェントが新しい脅威をもたらすという幅広い合意が確認された。回答者は、既存のサイバーセキュリティの実践も有用である一方、エージェントシステム向けの適応が必要だと述べている。
アイデンティティは、その適応をよく示す例だ。従来のアプリケーションは、多くの場合、予測可能な機能を備えた安定的なサービスアカウントを通じて動作する。エージェントは、動的に計画を組み立て、変化するコンテキストに基づいて複数のツールから選択できる。
そのエージェントに広範な認証情報を与えれば有用性は高まるが、操作を受けた場合の被害も拡大する。あらゆる権限を事前に制限すればリスクは下がるが、正当な業務を完了できなくなる可能性がある。セキュリティチームは、有用な自律性と厳格に限定された影響範囲のバランスを取らなければならない。
監査記録も別の課題となる。調査担当者が、どのユーザーがタスクを開始したのか、どの情報がエージェントに影響を与えたのか、なぜその操作が認可されたのかを判断できなければ、ツール呼び出しを記録するだけでは不十分だ。有用な記録は、人の意図、エージェントのアイデンティティ、データアクセス、結果として生じたシステム変更を結び付けなければならない。
Thales Google Cloud AI securityのアプローチは、ワークフロー全体の可視性を通じてこの問題に対処する。原理的には、共有レイヤーにより、モデル、アイデンティティ、API、アプリケーションのログに分かれて現れる活動を相関付けられる。
この可視性は、セキュリティ運用チームが異常な挙動を認識する助けになり得る。通常は地域別の売上データを読むエージェントが、突然従業員記録や未知の外部エンドポイントを要求した場合、精査の対象となるべきだ。静的なルールですべての正当な手順を予測できない場合、行動コンテキストには価値がある。
ただし、可視性は封じ込めではない。ダッシュボードは、被害が生じた後にインシデントを説明できる。より強い主張は、エージェントの有用性を支える正当な変化を妨げずに、ポリシーが危険な操作をリアルタイムで停止できるというものだ。
ランタイム適用が主要な競争領域になる
戦略的な競争は、クラウドプラットフォームに組み込まれたセキュリティと、モデル、エージェント、ツール全体で一貫したポリシーを約束する独立系制御との間で展開されている。
Google Cloudは、単一のセキュリティサプライヤーに依存するのではなく、Agent Gatewayを中心としたパートナーエコシステムを構築している。同社が公表している参加企業には、Thales、Zscaler、Exabeam、Silverfort、Cisco、CrowdStrike、Palo Alto Networksなどが含まれる。各ベンダーは、エージェントワークフローの異なる部分に対応している。
Thalesは、ImpervaのアプリケーションおよびAPIセキュリティをこの仕組みに持ち込む。公表された対象範囲には、クライアントからエージェントへのトラフィック、エージェントとモデル間のやり取り、Model Context Protocolなどのインターフェースを用いるツールとの連携が含まれる。MCPは、AIアプリケーションを外部データやソフトウェア機能に接続するためのプロトコルだ。
このアプローチは、エンタープライズの購入者に柔軟性をもたらす。企業はGoogleのインフラを使用しながら、既存のセキュリティ運用に適した追加制御を選択できる。また、モデルプロバイダーが提供する保護策に全面的に依存する圧力を下げることもできる。
その代償は複雑さだ。複数の製品が、異なる観点から同じワークフローを検査する可能性がある。セキュリティチームは、アイデンティティ、データ保護、行動分析、認可、インシデント対応をどのコンポーネントが担うのかを決めなければならない。
重複する制御は、深層防御と同じくらい容易にギャップを生み出し得る。ある製品はエージェントのアイデンティティに基づいて要求を承認する一方、別の製品には不正利用を認識するために必要なタスクコンテキストがないかもしれない。さらに別の製品は、返された機密データを理解しないままツール呼び出しを記録する可能性がある。
Microsoftは、より垂直統合されたルートを追求している。同社のエージェントセキュリティ戦略は、アイデンティティ、アクセスポリシー、データガバナンス、生産性アプリケーションを結び付ける。Microsoft Entraはエージェントにアイデンティティを割り当てられ、PurviewポリシーはMicrosoft環境内の機密情報を管理する。
このモデルは、すでにMicrosoftサービスを中心に据える組織に、より明確な管理経路を提供する。一方で、よく知られたプラットフォーム依存の懸念も生じる。1社のアプリケーションに最適化された制御は、ワークフローがクラウド、モデル、サードパーティーツールをまたぐ際に、一貫性の低い保護しか提供できない可能性がある。
Googleのパートナーベースのアーキテクチャでは、オープン性が提案の一部となっている。しかし、オープン性は統合作業をプラットフォームと顧客側に移す。ポリシーが有用であるためには、すべての引き継ぎを通じて維持され、本番トラフィックに十分な速さで判断を下さなければならない。
独立系ベンダーも、関連する課題に直面する。追加レイヤーが単なる監視コンソール以上の価値を提供することを証明しなければならない。購入者は、適用可能なポリシー、実用的な調査機能、日常業務を妨げずにリスクを低減するという証拠を求めるだろう。
ImpervaはすでにウェブアプリケーションとAPIの周辺で運用されているため、Thalesには信頼できる立ち位置がある。エージェントのワークフローは、同じインターフェースの多くを使用する。既存のトラフィック検査、ボット管理、API保護は、クライアントの認識と要求の制御に向けた基盤を提供できる。
エージェントの挙動は、従来のアプリケーショントラフィックとはなお異なる。正当なエージェントであっても、技術的には有効なAPIリクエストを、許容できない目的で実行し得る。この違いを検知するには、ユーザーの意図、委任された権限、データの機微性、先行アクションの順序に関するコンテキストが必要となる。
競争の焦点は、既存のWebセキュリティの枠を越えてここへ移る。ベンダーは、エージェント自身の説明に依存せず、その運用コンテキストを解釈しなければならない。操作されたモデルは、危険な呼び出しに対してもっともらしい根拠を示すことができる。
クラウドプロバイダーにも情報面での優位性がある。モデルサービス、アイデンティティ基盤、ネットワーク、エージェントプラットフォームを運用しているからだ。パートナーは、顧客のプライバシーとシステム性能を尊重しつつ、正確な判断に足るテレメトリーを受け取る必要がある。
したがって、最も強力なアーキテクチャはレイヤー型になる可能性がある。ネイティブのクラウド制御が基盤的なアイデンティティと分離を強制し、専門製品がアプリケーションの挙動や機微データの移動を検査する。不可逆的、または影響の大きい判断には、人間による承認が引き続き適している。
この競争は、最も長い機能一覧によって決着するものではない。企業は、各アーキテクチャが混在環境、委任アイデンティティ、不完全なコンテキストをどの程度適切に扱えるかを評価する。また、インシデント対応者が、互換性のない複数のログをつなぎ合わせずにワークフローを再構築できるかも検討するだろう。
セキュリティの約束にはなお本番環境での証拠が必要だ
ThalesとGoogle Cloudは適切な制御ポイントを示しているが、この発表だけでは、敵対的な圧力下でそれらの制御がどれほど正確かつ一貫して機能するかは立証されていない。
両社は今回の発表で、導入件数、レイテンシー測定値、独立評価、詳細な誤検知率を公表していない。また、統合されたファブリックが本番環境で攻撃を阻止したことを示す顧客事例も特定していない。
この欠落は、製品の方向性を無効にするものではない。ただし、このローンチから導ける結論には限界がある。この統合は、エージェント型ワークフローが安全になったことの証明ではなく、拡張されたセキュリティアーキテクチャとして扱うべきだ。
プロンプトインジェクションは依然として厳しい試験となる。NISTの2026年3月のレッドチーミング結果は、間接的なプロンプトインジェクションをエージェント乗っ取りとして説明している。攻撃者は、エージェントが後に処理する外部コンテンツの中に、悪意ある指示を埋め込む。
こうした攻撃は、根本的な曖昧さを悪用する。モデルは、正当な指示と信頼できない情報を、類似したテキスト形式で受け取る。悪意あるコンテンツがその境界を曖昧にするよう設計されていても、分析すべきデータと従うべき命令を区別しなければならない。
実行時ポリシーは被害を抑えられる。注入された指示がエージェントを説得し、機密記録を要求させることはあり得るが、別の認可レイヤーがその要求を拒否できる。制御側は、モデルがなぜ誤った判断を下したのかを正確に特定する必要はない。
この分離は、パートナーシップにおける最も強力な考え方の一つだ。データアクセスとツール利用に対する決定論的な制限は、モデルレベルのガードレールが見逃す失敗を封じ込められる。最小権限の認証情報と人間による承認は、影響をさらに抑制できる。
ただし、ポリシーエンジンには正確なコンテキストが必要だ。どのユーザーがタスクを承認したのか、エージェントがどの目的に使われるのか、どのリソースが必要なのかを把握しなければならない。範囲が広すぎる、または保守が不十分なポリシーは、技術的に高度な制御レイヤーを寛容なゲートウェイに変えてしまう可能性がある。
誤検知は逆の失敗を招く。エージェントが繰り返し承認待ちになったり、日常的なデータへのアクセスを失ったりすれば、従業員はその利用を避けるかもしれない。管理者は、強制措置が実質的な保護を提供しなくなるまでポリシーを緩める可能性がある。
レイテンシーも重要だ。各検査ステップは処理時間を加える。単一の対話では影響が小さくても、数十回のモデル要求やツール呼び出しを含むワークフローでは大きくなり得る。組織には、現実的なマルチエージェント導入環境での測定値が必要だ。
暗号化とプライバシーは、別の緊張関係も生む。セキュリティツールには、機微情報や悪意ある指示を特定するための十分な可視性が必要だ。顧客は、どのコンテンツが検査されるのか、どこで処理されるのか、どれだけ保持されるのか、誰がアクセスできるのかについて、明確な説明を求めるだろう。
問題は一つの製品にとどまらない。OWASPのエージェントリスクには、目標の乗っ取り、ツールの悪用、アイデンティティの不正利用、メモリ汚染、安全でないエージェント間通信、連鎖的障害が含まれる。単一のトラフィックフィルターで、すべてのカテゴリを解決することはできない。
メモリ汚染は分かりやすい例だ。攻撃者は、エージェントが後で利用するために保存する虚偽または悪意ある情報を植え付ける可能性がある。実行時制御は元の入力を検査できても、有害な影響は数日後、別のワークフローで現れるかもしれない。
連鎖的障害も同様に難しい。一つのエージェントが、別のエージェントには信頼できるように見える誤った結果を生成することがある。個々のツール呼び出しはポリシーを満たしていても、ワークフロー全体は有害な結果へ向かう可能性がある。
したがって、組織には多層防御が必要だ。制限された権限、サンドボックス、署名付きアイデンティティ、保護されたメモリ、検証済みツール、継続的な監視、人間によるレビューを組み合わせるべきである。セキュリティテストは、孤立したモデル応答ではなく、完全なワークフローを対象にしなければならない。
政府のガイダンスもこの立場を補強している。オーストラリアのエージェント導入ガイダンスは、人間による制御ポイント、継続的な監視、最小権限、複数の重なり合う防御を推奨している。また、自律性を段階的に高めることも助言している。
Thales AI Security Fabricは、こうした防御の一つになり得る。この発表は、それをセキュリティプログラム全体として扱うことを正当化するものではない。購入者は、既存のアイデンティティシステム、開発制御、インシデント対応、承認手順とどのように連携するのかを問うべきだ。
エージェントセキュリティがワークフローへ移行する中で圧力を受けるのは誰か
セキュリティベンダー、クラウドプラットフォーム、企業の購入者は現在、エージェントガバナンスを文書化された方針から強制可能なソフトウェアへと変える圧力に直面している。
クラウドプロバイダーは、最も直接的な期待に直面している。顧客には、エージェントを実験段階から業務運用へ移行してほしいと考えているが、法務・セキュリティチームが許容可能な境界を定義できない場合、導入は停滞する。アイデンティティ、アクセス、監査可能性に関する基本的な問いに答えられないプラットフォームは、機微な導入で苦戦するだろう。
Google Cloudの対応は、Agent Gatewayを共通の強制ポイントとして構築し、その周囲を専門パートナーで固めることだ。Thalesは、一つのセキュリティファブリックを通じてアプリケーション、API、モデル、ツールの相互作用をカバーすることで、この戦略を強化する。
Thalesは、このより広い範囲が引き続き管理可能であることを示す必要がある。同社の価値提案は、複数の技術レイヤーにまたがる一貫した視点を顧客に提供できることに依存している。断片化されたポリシーや重複するアラートは、統合の利点を弱めるだろう。
競合するセキュリティベンダーには、同等に広いカバレッジを実証する圧力がかかる。プロンプトだけを保護することでは、もはや不十分だ。購入者は、認証情報、ツール実行、データ移動、メモリ、エージェント間メッセージ、外部アクションを制御する仕組みを必要としている。
アイデンティティプロバイダーも新たな負荷を抱える。エージェントには、個別のアイデンティティ、限定された権限、追跡可能な所有者、管理可能なライフサイクルが必要だ。一時的なエージェントが、タスク終了後に恒久的な認証情報を残してはならない。
アプリケーション所有者にも別の負担がある。エージェントが実行できるアクションと、その条件を定義しなければならない。セキュリティチームは、ワークフローを理解する人々からの運用上の情報なしに、有用なポリシーを作成できない。
開発者は、より構造化されたコンテキストを公開する必要がある。ツール呼び出しがタスク、ユーザー、要求リソース、意図する効果を宣言すれば、セキュリティレイヤーはより良い判断を下せる。構造化されていないプロンプトだけでは、認可の基盤として弱い。
企業の購入者は、調達をガバナンスの終点として扱う誘惑に抗うべきだ。セキュリティファブリックを導入しても、許容可能な自律性は決まらない。組織は依然として、ユースケースを分類し、所有者を割り当て、エスカレーションポイントを定義し、障害シナリオをテストする必要がある。
低リスクのユースケースは、妥当な出発点となる。承認済みの社内文書からレポートを下書きするエージェントは、メッセージ送信や顧客アカウント変更を行うエージェントよりも影響範囲が小さい。評価によってワークフローが引き続き制御されていることが示された後にのみ、権限を拡大すべきだ。
影響の大きいアクションには、明示的な承認がふさわしい。資金移動、本番環境の変更、法的コミュニケーション、人事判断、機微データの開示は、モデルの確信度だけに依存すべきではない。人間によるレビューはワークフローを遅らせる可能性があるが、その摩擦はエラーの結果を反映したものだ。
ナレッジワーカーも、この問題に関心を持つべきだ。こうした制御は、職場のエージェントが閲覧・実行できる範囲を形作る。より良いセキュリティによって、エージェントが有用な社内情報にアクセスできるようになるかもしれない。不適切に設計された制御は、過剰なデータ露出を招くか、正確な業務に必要なコンテキストを遮断する可能性がある。
従業員には透明性も必要となる。エージェントがいつ自分のアイデンティティのもとで行動するのか、どの記録にアクセスしたのか、その出力が外部変更を引き起こすのかを知るべきだ。インシデント発生時、隠れた自動化は説明責任を困難にする。
より大きな変化は組織的なものだ。AIセキュリティは、モデル評価の課題から、日常的なアイデンティティおよびアプリケーション管理へ移行している。これにより、エージェントは従業員、サービス、ベンダー、ソフトウェア導入に適用されるのと同じ運用規律の下に置かれる。
ThalesとGoogle CloudによるAIセキュリティパートナーシップが重要なのは、この移行を明確にした点にある。その成否は発表内容よりも、企業が新たな分断されたガバナンスレイヤーを生み出さずに制御を適用できるかに左右されるだろう。
制御が機能しているかを示す三つのシグナル
次の試験は、測定可能な導入実績であり、その後に相互運用可能なアイデンティティと信頼できる敵対的評価が続く。
第一のシグナルは、成果を開示した本番導入だ。ThalesまたはGoogle Cloudは、ワークフロー、権限、阻止された挙動、運用上のオーバーヘッドを説明する顧客事例を公表すべきである。有用な証拠には、検知精度、承認頻度、レイテンシー、インシデント対応の結果が含まれる。
顧客が安全なエージェントを導入したという曖昧な声明では、ほとんど分からない。最も強力なケーススタディは、制御が現実的なプロンプトインジェクションや未承認のツール呼び出しをどのように阻止したかを示すものだ。また、正当なアクティビティがどの程度中断されたかも説明すべきである。
こうした証拠が示されれば、実行時の強制措置が実用的なエージェント導入を支えられるという主張が強まる。顧客名が明かされず、測定値も非公開のままであれば、購入者はこの統合を有望ではあるが未実証のものとして扱うべきだ。
第二のシグナルは、プラットフォームをまたぐより強力なアイデンティティと認可だ。NISTはすでに、エージェントの識別、委任、監査、否認防止に関する課題を指摘している。市場には、どのエージェントが、誰のために、どの権限で行動しているのかを一貫して証明する方法が必要だ。
企業のワークフローは、一つのベンダーの環境内にとどまることがほとんどないため、相互運用性が重要になる。エージェントはGoogleのモデルを使用し、サードパーティーのデータベースに問い合わせ、Microsoftのアプリケーションを呼び出し、社内開発ツールを実行する可能性がある。
一つの再利用可能な認証情報に広範なアクセスを付与することなく、ポリシーはこのワークフローに追随しなければならない。特定のタスクに結び付いた短期間の認可は、リスクを低減するだろう。検証可能な記録は、結果に重大な影響を与えるすべてのアクションを、エージェントと責任を負う人間またはサービスの双方に結び付けるべきである。
オープンなアイデンティティ標準の進展は、Google Cloudのパートナー戦略を強化するだろう。分断が続けば、技術スタックのより多くを管理する緊密に統合されたプラットフォームが有利になる。
第3のシグナルは、独立した敵対的テストである。ThalesとGoogle Cloudは、間接的なプロンプトインジェクション、悪意あるツール出力、認証情報の悪用、メモリポイズニング、侵害されたエージェントに対して、統合システムをテストすべきだ。評価では、攻撃が検知されたかどうかだけでなく、封じ込めを測定する必要がある。
有用なテストでは、モデルが失敗することを前提とする。その上で、外部の制御がデータ流出や不正なシステム変更を防止できるかを問う。これにより、モデルの安全性に関する主張と、周辺アーキテクチャがもたらす実用的なセキュリティ価値を分けて考えられる。
独立研究者は、マルチエージェントのワークフローによって生まれる回避経路も検証すべきだ。あるポリシーが単一の直接的な要求を阻止しても、個別には許容される複数の行為によって、同じ禁止結果が生じることを許してしまう可能性がある。
この発表は適切なタイミングで行われた。企業はエージェントに情報の要約以上を求める一方、規制当局やセキュリティチームは、より明確な説明責任を要求している。こうした圧力により、実行時制御は任意の機能ではなく、必須要件となる。
ただし、自律性が高まるほど立証責任も重くなる。エージェントに与えられる権限が大きいほど、アイデンティティ、権限、ポリシー、監査記録が攻撃下で連携して機能するという証拠を、購入者はより多く必要とする。
ThalesとGoogle CloudのAIセキュリティ統合を評価する組織は、範囲を限定した1つのワークフローと、明確な失敗許容枠から始めるべきだ。すべてのツール、認証情報、データソース、不可逆的な操作をマッピングする。その後、制御がユーザーを承認手続きで圧倒することなく、不正利用を阻止できるかをテストする。
決定的な問いは実務的なものだ。ワークフローが変更されるたびに、このパートナーシップはエージェントの広範な能力を、厳密に認可された行動へと変換できるのか。実運用での測定、相互運用可能なアイデンティティ、独立したテストが、その答えを示す。
