Amazon・Googleのセキュリティ競争が激化する中、AWSがAIエージェントに厳格な制限を導入

AWSは、攻撃者や汚染されたデータがAIエージェントの推論を操作するリスクを踏まえ、エージェントに強制可能な制限を設けた。この動きにより、価値の高い業務システムへエージェントを安全に接続できるクラウドはどこかを巡るAmazon・Googleの競争が鮮明になっている。

Amazon Bedrock AgentCore Policyは、エージェントが要求するツール操作を、その操作が基盤サービスに到達する前に検査する。操作されたエージェントが危険なリクエストを生成する可能性は依然としてあるが、そのリクエストが外部ポリシーに抵触すれば失敗するはずだ。

この違いは重要である。プロンプトフィルターは、完全なセキュリティ境界を提供したことがない。モデルは、指示と信頼できないデータを同じ確率的な仕組みで処理する。AWSは現在、このモデルを最終的な権限者ではなく、信頼できない意思決定者として扱っている。

Google CloudとMicrosoftも、それぞれのアイデンティティ、ゲートウェイ、情報フロー制御を通じて、同じ大きな方向へ進んでいる。新たな競争は、もはやモデルの品質だけにとどまらない。クラウドプロバイダーは、接続されたすべてのシステムへの無制限なアクセスを引き継がせることなく、エージェントが行動できることを示さなければならない。

AWS、認可をエージェントの外部へ移す

AWSは、エージェントが実行したいことと、インフラが実行を許可することを分離している。

Amazon Bedrock AgentCoreのPolicyは、エージェントとツールのやり取りを保護する境界を設ける。このサービスはAgentCore Gateway経由でルーティングされるリクエストを傍受し、ツール呼び出しを許可する前に各リクエストを評価する。

AgentCore Gatewayは、管理されたインターフェースを通じて、エージェントをAPI、関数、その他のツールに接続する。ポリシーエンジンは、エージェントのプロンプトやオーケストレーションコードの内部ではなく、その接続の横に配置される。

この配置はセキュリティモデルを変える。システムプロンプトは、制限された顧客記録を決して取得しないようエージェントに指示できる。しかし、プロンプトインジェクションは、その指示を無視させたり、異なる解釈をさせたりする可能性がある。

外部の認可エンジンは、モデルの同意を必要としない。明示的なルール、認証済みのID、ツールパラメーター、利用可能なリクエストコンテキストを用いて、提案された操作を評価する。

AWSは、オープンソースの認可言語Cedarを使用して、こうしたルールを表現する。Cedarポリシーは、リクエストを行うプリンシパル、要求された操作、保護対象のリソース、必要な条件を識別する。

このサービスはデフォルト拒否のセマンティクスに従う。ポリシーが明示的に許可しない限り、操作にはアクセスが付与されない。また、一致する禁止ルールは、そうでなければリクエストを許可し得るより広範な権限よりも優先される。

AWSは、AgentCore policy guideでこれらの仕組みを説明している。このガイドによると、ルーティングされたすべてのエージェントリクエストは、ツールアクセスが付与される前に評価される。

開発者はCedarを直接記述することも、要件を平易な英語で記述することもできる。自然言語による作成サービスは、それらの要件をCedarポリシー候補へ変換する。

AWSによると、このサービスは生成されたポリシーをゲートウェイのツールスキーマに照らして検証する。また、過度に許容的、過度に制限的、あるいは満たすことが不可能と思われるルールについても確認する。

この生成プロセスによって、曖昧な要件が安全になるわけではない。AWSは、自然言語のポリシーにも正確で曖昧さのない表現が必要だと警告している。セキュリティチームは、生成されたポリシーを疑いのないコードとして扱うのではなく、結果として得られたCedarをレビューする必要がある。

ポリシーを作成するモデルも、それを強制する仕組みとは別である。デプロイ後は、別のモデルに意見を求めるのではなく、形式化されたポリシーが認可の判断を制御する。

口座情報の閲覧と返金を実行するツールを持つ社内サポートエージェントを考えてみよう。企業は、すべてのサポート担当者に担当口座の閲覧を許可しつつ、高額な返金の承認はスーパーバイザーに限定できる。

悪意ある返金指示を含むメールがあれば、エージェントはその操作を試みるかもしれない。それでも、認証済みの従業員に必要な役割がない場合や、金額がポリシーの上限を超える場合、ゲートウェイはそのリクエストを拒否できる。

拒否されたリクエストが決済システムに到達する必要はない。この結果は、悪意ある指示のあらゆる変種を認識するようエージェントに求めるよりも強力だ。

AWSのリリース文書によると、AgentCore PolicyはAWSの13リージョンで一般提供されている。集中管理されたポリシーは、関連するゲートウェイを通じて接続された複数のエージェントとツールに一貫して適用できる。

CloudWatch統合は、監視と監査のために認可判断を記録する。これらの記録により、セキュリティチームは、エージェントがどの操作を要求し、許可または拒否されたかをより明確に把握できる。

したがって、当面の変化は表面的なものではなく、アーキテクチャ上のものだ。AWSは、不確実なモデルの振る舞いと重大な影響を及ぼすエンタープライズシステムの間に、決定論的なチェックポイントを置いている。

プロンプトインジェクションがAmazon・Googleの競争を変える理由

Amazon・Googleのクラウド競争は今や、侵害されたエージェントを封じ込めることにかかっており、単に回答を改善することではない。

AIエージェントは、非公開情報を取得し、APIを呼び出し、メッセージを送信し、記録を変更できるようになることで有用になる。同じ権限が、操作を受けた後に生じ得る被害も決定する。

プロンプトインジェクションとは、モデルが処理するコンテンツに敵対的な指示を挿入することだ。直接的なインジェクションはユーザーのリクエストから発生する一方、間接的なインジェクションはWebサイト、文書、メール、ツールの応答の中に隠れる可能性がある。

サプライヤーを調査するエージェントは、Webページに埋め込まれた指示に遭遇することがある。そうした指示は、機密ファイルを取得し、別の接続済みツールを通じて送信するよう命じる可能性がある。

コンテンツフィルターは、よく知られた攻撃パターンを検出できるかもしれない。しかし、通常とは異なる表現、エンコードされたコマンド、複数のやり取りに分散した一連の指示を見逃す可能性もある。

根本的な問題は、悪意あるプロンプトにとどまらない。モデルは操作をハルシネーションしたり、業務ルールを誤解したり、個別には許容されるツールを組み合わせて許容されないワークフローを作り出したりする可能性がある。

OWASPはこの状態をexcessive agencyと説明している。LLMが、予期しない出力の後に有害な影響を引き起こせるほどの機能や権限を与えられたとき、リスクが生じる。

認可は、それによって生じる影響範囲を限定する。このシステムは、エージェントがいずれ誤った判断を下すことを前提にし、その判断が無制限の操作へ変わるのを防ぐ。

このアプローチは、確立されたクラウドセキュリティの慣行に似ている。アプリケーションにはタスクに必要な権限だけを与え、機微な操作には追加のチェックを課すべきだ。

エージェントはツールを動的に選択するため、この原則を複雑にする。また、多数の呼び出しを連鎖させ、ステップ間でコンテキストを引き継ぎ、直接の監督なしに長時間動作することもある。

したがって、広範な権限を持つ静的なサービスアカウントは重大な負債になり得る。エージェントは、関与するユーザーやタスクに関係なく、その認証情報に紐づくすべての能力を実質的に得ることになる。

AWSは、AgentCoreのリクエストをOAuthユーザーまたはAWS Identity and Access Managementエンティティに接続できる。これによりポリシーは、エージェントの共有サービスロールだけに依存せず、リクエストの背後にあるIDを考慮できる。

Googleも、GeminiベースのエージェントとModel Context Protocol接続を拡大するなかで、同じ問題に直面している。MCPは、モデルが外部ツールを検出して呼び出せるようにする標準インターフェースだ。

GoogleのMCP security guidanceは、本番アクセスに対する拒否ポリシー、狭い範囲に限定した権限、入力のサニタイズ、監視を推奨している。また、そうしなければセキュリティがエージェントのプログラミングだけに完全に依存する可能性があると警告している。

この収束は重要だ。Amazon・Googleの競争は、しばしばモデルの提供状況、インフラ、データプラットフォーム、開発者ツールを中心に展開してきた。エージェントの認可は、もう一つの主要な購買判断基準になりつつある。

エンタープライズの顧客がエージェントを単独のチャットボットとして導入することはほとんどない。顧客は、エージェントをデータベース、コードリポジトリ、サポートプラットフォーム、クラウドコンソール、社内ナレッジストアに接続したいと考えている。

接続のたびに、有用性と露出の両方が生まれる。接続を容易にする一方で認可が弱いクラウドプロバイダーは、運用上のリスクを顧客に押し戻すことになる。

AWSは、AgentCore Policyをフレームワークやモデルをまたいで利用できる再利用可能な強制レイヤーとして位置付けている。開発者は、複数の一般的なオーケストレーションフレームワークで構築したエージェントとAgentCoreを利用できる。

このオープン性により、AWSは、企業がモデルを変更してもセキュリティポリシーは安定しているべきだと主張できる。組織は、すべての権限ルールを書き換えることなく、ある基盤モデルを別のものに置き換えられる可能性がある。

Googleも、クラウドのアイデンティティ制御、Model Armor、リソースレベルの権限を通じて同様の主張ができる。その強みは、Google Workspace、Gemini、広範なデータプラットフォームに近接していることだ。

Microsoftは、Entraアイデンティティ、Copilot、エージェント開発スタックを通じて圧力を加えている。市場は、AIの推論とエンタープライズの実行の境界を誰が制御するかを巡る三者間の競争になりつつある。

購入者にとって重要なAmazon・Googleの問いは、どのモデルが常に悪意あるプロンプトを拒否するかではない。あらゆる入力とツールの組み合わせに対する完璧な拒否を、信頼性をもって約束できるベンダーは存在しない。

より良い問いは、拒否が失敗した後に何が起きるかだ。安全なプラットフォームは、侵害されたエージェントが利用できるツール、記録、パラメーター、宛先、操作シーケンスを制限すべきである。

Amazon・Googleのセキュリティ戦略はツール境界で交わる

AWS、Google、Microsoftは決定論的な強制へと収束しているが、その強制の組織化方法は異なる。

AWSはAgentCore Policyをゲートウェイの経路に直接配置している。対象となるエージェントからツールへのすべてのリクエストは、要求された呼び出しが進む前にポリシーエンジンに到達する。

Cedarは、チームが検査、検証、分析できる正式な言語をAWSに提供する。AWSはエージェント以外にもCedarの概念を使用しており、エージェント認可を確立されたアプリケーションセキュリティの慣行と結び付ける助けとなっている。

同社のセキュリティ研究者は、モデル自体について率直な前提を置いている。Cedar security analysisでは、組織は多層防御の設計においてLLMを信頼できないアクターとして扱うべきだとしている。

これはモデルが悪意を持つという意味ではない。モデルは確率的であり、操作されたコンテキストの影響を受けやすいため、認可システムが予測可能なモデルの振る舞いに依存できないことを意味する。

Googleが公開しているガイダンスは現在、MCPサーバーとGoogle Cloudリソースの周囲に置く多層的な制御を重視している。これらの制御には、拒否ポリシー、限定的な認証情報、分離されたテスト環境、サニタイズされた入力、制限された本番アクセスが含まれる。

Googleはまた、ワークフローで必要とされない限り、読み書き可能なツールが本番リソースに到達しないようにすることを推奨している。認可済みの操作であっても望ましくない結果を生む可能性があるため、復旧機能も重要であり続ける。

実務上の違いは、開発者体験に表れる可能性がある。AWSは、管理されたゲートウェイでCedarに基づく評価を行う専用のAgentCoreポリシーエンジンを提供している。

Googleは成熟したCloud IAMと製品固有のポリシーを活用できる。しかし開発者は、関連するすべてのツール経路が実際に意図した制御を通過することを、なお確認する必要がある。

その注意点はAWSにも当てはまる。AgentCore Policyが制御するのは、関連付けられたAgentCore Gatewayを経由するトラフィックだ。別の実行経路を持つエージェントは、その特定のチェックポイントを迂回できる可能性がある。

たとえば、ポリシーによってマネージドMCPツール経由のS3操作をブロックできる。ただし、この制限が、同等のコマンドを実行できる別のシェルツールまで自動的にカバーするわけではない。

したがって、アーキテクチャレビューでは、名前付きツールだけでなく、能力そのものを列挙する必要がある。セキュリティチームは、SDK、コマンドライン、ブラウザ、関数、または別のエージェントを通じて、エージェントが同じリソースに到達できないかを問う必要がある。

Microsoftは、情報フロー制御を通じた別のアプローチを開発している。同社のFIDESミドルウェアは、コンテンツに完全性と機密性のラベルを付与し、それらのラベルをツール呼び出しに引き継ぐ。

MicrosoftのFIDESセキュリティモデルは、信頼できないコンテンツが機微な操作に影響することを防げる。また、プライベートデータが公開先へ流れることも制限できる。

このアプローチは、単一アクションの認可が持つ弱点に対応する。データベース検索は許可され、メール送信も許可される場合がある。しかし危険な挙動は、非公開の検索結果が外部メールへ流出するときに現れる。

AWSは、セッション認識型の評価へとポリシーを拡張している。時間的制御は、各リクエストを孤立したイベントとして判断するのではなく、エージェントの直近の行動を検査できる。

この方向性が重要なのは、攻撃者が有害な目的を、正当に見える複数の手順へ分割できるためだ。一連の行動は、個々のアクションだけでは見えないリスクを明らかにできる。

エージェントはまず機密ポートフォリオを読み取り、次に要約を計算し、最後に外部送信を試みるかもしれない。ツール呼び出しはそれぞれ妥当に見えても、それらを結び付ける軌跡には問題がある。

AmazonとGoogleのセキュリティ設計を比較する顧客にとって、用語よりも重要なのはカバレッジだ。高リスクの実行経路が適用範囲外に残るなら、正式なポリシー言語があっても保護は限定的になる。

アイデンティティの伝播も重要だ。ポリシーエンジンは、ユーザー、ワークロード、リソース、アクション、および関連するビジネスコンテキストを確実に把握する必要がある。

エージェントが多数の従業員にサービスを提供する場合、汎用的な「エージェント」アイデンティティでは不十分だ。それではすべてのユーザーにエージェントの最大権限セットを与え、通常のアクセス制御が提供する説明責任を失わせかねない。

組織は、委任された各リクエストの背後にある人間またはワークロードのアイデンティティを維持すべきだ。また、共有認証情報の中に隠すのではなく、エージェント自体にも制約された固有のアイデンティティを割り当てるべきである。

この分離により、異なる2つの問いに答えやすくなる。1つ目は、そのユーザーが当該アクションを要求できるか。2つ目は、このエージェントがこの特定のツールを通じてそのアクションを実行できるかだ。

中央集約型のポリシーは、チーム間の不整合も減らす。これがなければ、開発者ごとにプロンプト、カスタムミドルウェア、個別のツールハンドラの内部で認可を実装することになり得る。

こうした分散したチェックは監査が難しい。エージェントに新しいツール、モデル、ワークフロー分岐が加わるにつれて、チェック内容も乖離していく。

共有ゲートウェイは、すべてのリソースレベルの権限を置き換えられるわけではない。ただし、エージェントの意図が下流サービスに届く前に、組織がポリシーを適用できる一貫した地点を提供できる。

ポリシーの強さは、その適用範囲に左右される

AgentCore Policyはリスクを低減するが、AWS上でホストされるエージェントの安全性を証明するものではない。

このサービスが制御するのは、設定されたゲートウェイとポリシーエンジンを通過するリクエストである。開発者がその境界の外に残したツール、認証情報、ネットワーク経路までは統制できない。

ここでカバレッジの問題が生じる。セキュリティチームは危険なアクションをブロックしたと考えるかもしれないが、別のツールが同じリソースへの別経路を提供している可能性がある。

広範なIAM権限は、このギャップを悪化させうる。エージェントのランタイムロールがサービスを直接呼び出せるなら、ゲートウェイの制限に加え、未承認経路をブロックするリソースポリシーも必要になる。

ポリシー設計も依然として難しい。自然言語による作成は構文上の障壁を下げるが、曖昧なビジネス要件や欠落したセキュリティ前提を解決するものではない。

「アナリストに適切なレポートの閲覧を許可する」という表現は、正確な認可ルールではない。組織は、どのアナリスト、レポート、分類、地域、顧客、運用条件が「適切」に該当するかを定義しなければならない。

生成されたCedarには、レビュー、テスト、変更管理が必要だ。チームは、想定どおりの許可、想定どおりの拒否、不正なリクエスト、欠落したコンテキスト、意図的に敵対的なパラメータの組み合わせをテストすべきである。

すべてを拒否するポリシーは運用障害を招く。一方で、静かにすべてを許可するルールは、その反対の問題を引き起こす。どちらの結果も、構文上は有効に見える可能性がある。

開発者は、エージェントが提供する認可コンテキストも考慮する必要がある。セキュリティ上重要な属性は、信頼できるアイデンティティトークン、リソースメタデータ、または管理されたインフラから取得すべきだ。

モデル自身に、取引が低リスクである、あるいは文書が公開済みであると宣言させるべきではない。そのような主張は、モデルの推論プロセスの外部で検証される必要がある。

監査ログには別の義務も伴う。すべての判断を記録すれば調査には役立つが、チームはその記録を積極的に監視し、有用なコンテキストを保存しなければならない。

拒否されたアクションは、セキュリティ制御が成功したことを示す場合がある。一方、繰り返される拒否は、侵害されたワークフロー、ポリシーエラー、または禁じられた目的をエージェントが継続的に再試行していることを示す可能性もある。

許可されたアクションにも注意が必要だ。特にポリシーがセッション履歴やデータ移動を考慮しない場合、攻撃者は個々には正当な権限を悪用できる。

不可逆的または影響の大きい操作には、人間による承認が依然として有用だ。ただし、エージェントが要求アクションについて誤解を招く説明を提示した場合、承認画面は機能しない可能性がある。

インターフェースは、実際のツールリクエストから取得した信頼できる詳細を提示すべきだ。レビュー担当者には、宛先、リソース、パラメータ、データ分類、予想される影響が必要となる。

セキュリティチームは、ポリシー管理プレーンも防御しなければならない。エージェントが自らのルールを編集したり、より弱いポリシーエンジンを関連付けたり、より広範なアクセス権を持つ認証情報を取得したりできてはならない。

ここでは職務分離が役立つ。開発者はポリシー変更を提案できる一方で、セキュリティ責任者が管理されたワークフローを通じて変更をレビューし、デプロイする。

同じ規律は、社内ナレッジシステムにも当てはまる。検索可能なナレッジベースを構築するチームは、そのコンテンツをエージェントに公開する前に文書の権限を維持すべきだ。

検索は、リクエストしたユーザーの認可に基づいてレコードをフィルタリングすべきである。モデルが受け取る情報は、ユーザーが直接アクセスできる情報のサブセットに限る必要がある。

この設計は、重大な失敗モードを防ぐ。たとえモデルが操作に成功しても、アクセス可能なコンテキストに一度も入らなかった情報を明らかにすることはできない。

組織は、プロンプトインジェクションの検出に全幅の信頼を置くべきではない。検出は有用な防御を追加するが、未知の攻撃や無害に見える指示は分類器を回避する可能性がある。

AWSは、ゲートウェイの入力と出力を評価するため、ポリシーレイヤーでBedrock Guardrailsをサポートしている。この機能はCedarの強制を補完するものであり、置き換えるものではない。

違いは単純だ。ガードレールはコンテンツが危険に見えるかを推定し、認可は要求された操作が許可されるかを判断する。

確率的な検出と決定論的な強制は、異なる問題を解決する。両者を組み合わせれば、どちらか一方のレイヤーですべての失敗を捕捉できると見せかけることなく、攻撃対象領域を狭められる。

AmazonとGoogleのセキュリティ競争では、これらのレイヤーを迂回しにくくするベンダーが優位に立つだろう。安全なエージェントに関するマーケティング上の主張よりも、実証可能な強制のカバレッジの方が重要だ。

顧客は、間接インジェクション、侵害されたツール、代替実行経路、複数ステップのデータ移動を含むレッドチーム演習で、これらの主張を検証すべきである。

また、失敗時の挙動も確認すべきだ。拒否されたツール呼び出しは、エラーやフォールバック経路を通じて機密情報を露出させることなく、保護対象の操作を停止しなければならない。

AWSは、ポリシーをエージェントコードの外部に置くことで、より強力なデフォルトパターンを確立した。残る問いは、顧客が周辺のアイデンティティと経路を同等の慎重さで設定するかどうかだ。

エンタープライズの購入担当者が次に注目すべき点

次の段階では、競合するエージェントプラットフォームにおけるポリシーカバレッジ、セッション認識、移植性が試される。

最初のシグナルは、顧客が時間的ポリシーをどれほど迅速に採用するかだ。単一リクエストのルールは明確な制限には有効だが、多くのエージェント攻撃は認可済みアクションの連鎖として現れる。

時間的評価は、エージェントが機微なデータを読み取った後に外部転送を試みたことを検出できる。また、特定の操作シーケンスの後に追加承認を要求することもできる。

難しいのは、状態管理と解釈だ。システムは、通常のワークフローを妨げたり過剰な遅延を加えたりせずに、危険な軌跡を認識できるだけの履歴を追跡しなければならない。

購入担当者は、どの程度のセッション履歴を評価するのかを正確に説明した公開技術文書を確認すべきだ。また、ユーザー、エージェント、同時実行タスクの間で状態をどのように分離するかも問うべきである。

2つ目のシグナルは、GoogleとMicrosoftが、管理対象エージェントプラットフォームを通じて同等の制御をどのように提供するかだ。3社はいずれも、プロンプト指示だけでは接続されたシステムを保護できないことを認識している。

GeminiエージェントはWorkspaceコンテンツ、クラウドデータ、開発者インフラに近い位置に置かれ得るため、Googleの対応は重要になる。強力なリソース権限はすでに存在するが、エージェント固有の統合も不可欠だ。

Microsoftは、EntraアイデンティティをCopilot、Agent Framework、情報フローラベルと組み合わせられる。その優位性は、Microsoft製ツールとサードパーティツールの両方で一貫した強制を実現できるかに左右される。

AmazonとGoogleの比較は、エンドツーエンドの経路に焦点を当てるべきだ。購入担当者には、ユーザーアイデンティティからエージェントの推論、ゲートウェイ実行、最終的なリソースアクセスまで、アクションにポリシーが追随する証拠が必要である。

3つ目のシグナルは、独立したセキュリティテストだ。ベンダー文書は意図された挙動を説明する一方、レッドチームは欠落した経路、混同されたアイデンティティ、安全でないデフォルト、予期しないツールの組み合わせを明らかにする。

テストには、悪意あるWebページ、汚染されたサポートチケット、侵害されたMCP応答、承認済みリポジトリ内の敵対的な文書を含めるべきだ。各ソースは、間接的な指示をエージェントのコンテキストに持ち込む可能性がある。

研究者は、エージェントが禁止されたリクエストを技術的に異なるアクションへ変換できるかもテストすべきだ。ブロックされたエクスポートが、ブラウザアップロード、シェルコマンド、エンコードされたメッセージ、または別のエージェントへのリクエストに変わる可能性がある。

その結果によって、外部ポリシーが意味のある封じ込めを実現するのか、それとも単なる別の設定レイヤーにとどまるのかが決まる。最も強い証拠は、モデルの挙動を変えても認可境界を越えられない攻撃から得られるだろう。

エンタープライズは、アーキテクチャの改善をこれらの結果まで待つ必要はない。まず、すべてのエージェント、ツール、認証情報、データソース、外部宛先を棚卸しすることから始められる。

各ツールには、可能な限り狭いアクション範囲を与えるべきだ。読み取り専用アクセスは、変更、削除、外部共有、または金融取引の実行と分離して維持すべきである。

短期の委任で対応できる場合、チームは常設認証情報を削除すべきだ。ツール呼び出しをまたいでユーザーアイデンティティを維持し、試行された操作と完了した操作の両方を記録すべきである。

影響の大きいアクションには、信頼できる承認コンテキストを要求すべきだ。セキュリティチームは、意図されたゲートウェイ経路だけを検証するのではなく、保護対象リソースへの代替経路を定期的にテストすべきである。

AmazonとGoogleのクラウドに関する判断では、もはやモデルのベンチマークだけでは不十分です。購入者は、デフォルト拒否の挙動、ID伝播、ポリシー分析、監査の詳細度、セッション制御、強制適用の範囲を比較すべきです。

また、モデルやフレームワークが変わってもポリシーがどう維持されるのかを問う必要があります。特定のエージェント実装に強く結び付いた認可は、移行時の保守コストを高め、迂回されやすくなります。

AWSは明確なアーキテクチャ上の選択を行いました。エージェントの推論は操作され得ると想定し、その影響をエージェント外部の決定論的な制御によって抑える考え方です。

この前提は、モデルが完全に指示に従うと約束するよりも説得力があります。誤りや攻撃が発生することを受け入れつつ、ツールとデータに対する独立した権限を維持するものです。

このアプローチは依然として規律ある設定に依存します。限定的なゲートウェイポリシーでは、過剰な権限を持つランタイム、管理されていないシェル、あるいは認可フィルタリング前に取得されたデータを補うことはできません。

エンタープライズチームは現在、具体的なワークフローを最初から最後まで1つテストすべきです。エージェントを操作し、要求するアクションを観察し、保護対象の操作が外部境界で確実に失敗することを確認します。

このテストは、Amazon、Google、そして他のすべてのエージェントプラットフォームにとって実践的な基準を示します。モデルはだまされる可能性がありますが、インフラストラクチャはそれでも「拒否」と言わなければなりません。