Mendの5層セキュリティガイド、プロンプトガードレールを超える本番AIリスクに対応

Mend.ioは、Google Newsにも掲載された5層のセキュリティアプローチを公開した。しかし、その中心的なメッセージは、多くのチームによる本番AIの保護方法に疑問を投げかけるものだ。認証情報を保持し、ツールを呼び出し、メモリを保持し、外部システムを変更するエージェントを、プロンプトガードレールだけで保護することはできない。

MarkTechPostが8月3日に取り上げたこのガイドは、攻撃対象領域をインタラクション、エージェント、統合、モデル、コードの各層に整理している。その実用的な価値は、AIアプリケーションを、単に入力リスクが特殊なチャットボットではなく、実行可能なシステムとして扱う点にある。

この違いが、本質的な対立を生む。開発者は、より少ない中断でエージェントにより多くの作業を完了させたい。一方、セキュリティチームは、エージェントが悪意ある文書、汚染されたツール、過剰な権限、予期しない実行経路に遭遇した際に、決定論的な制限を必要としている。

MCPはModel Context Protocolの略で、AIアプリケーションが外部ツールを検出し呼び出すための標準インターフェースを提供する。モデルをデータベース、ファイルシステム、API、業務アプリケーション、開発環境へ接続できる。

このプロトコルは相互運用性を高めるが、その利便性は各ワークフロー内の信頼境界の数を増やす。エージェントは今や、信頼できないテキストを数秒で重大なアクションへ変換し得る。

もはや問題は、モデルが不適切な回答を生成するかどうかではない。操作されたモデルが、認可されたツールを認可されていない目的に使えるかどうかである。

Google Newsが本番AIセキュリティに焦点を当てる

重要な出来事は、モデルの振る舞いを議論する段階から、入力から実行までの経路全体を保護する段階への移行である。

Google Newsを通じて取り上げられた本番セキュリティガイドは、エージェントセキュリティを5層から成るエンジニアリング課題として提示している。インタラクション層は、プロンプト、取得した文書、ユーザーファイル、その他アプリケーションへ流入する情報を対象とする。

エージェント層には、計画、メモリ、ツール選択、委任タスクが含まれる。統合層は、MCPサーバー、API、データベース、プラグインなど、エージェントの判断を外部システムへ運ぶ接続を対象とする。

モデル層には、言語モデル、その設定、振る舞い上の制約が含まれる。コード層には、アプリケーションロジック、依存関係、インフラ、認証情報、デプロイパイプラインが含まれる。

この枠組みが重要なのは、障害が複数の層をまたぐことが多いためだ。悪意ある指示は文書を通じて入り、モデルの推論に影響を与え、許可されたMCPツールを起動し、通常のAPIリクエストを通じてデータを露出させる可能性がある。

各コンポーネントは設計どおりに動作しているように見える場合がある。セキュリティ障害は、それらの組み合わせから生じる。

従来のアプリケーションセキュリティも、このスタック内で依然として重要である。チームは依存関係にパッチを適用し、シークレットを保護し、入力を検証し、ワークロードを分離し、コードをレビューしなければならない。しかし、こうした対策だけでは、エージェントが正当なツールを誤ったタイミングで選択した理由を十分に説明できない。

モデルは、同じ基本的な媒体で表現された指示とデータを扱う。取得したページには、ユーザーの質問に答える情報、エージェントを誘導し直す指示、あるいはその両方が含まれ得る。

これにより、悪意ある指示がユーザーに見えるプロンプトではなく外部コンテンツを通じて到達する、間接プロンプトインジェクションが発生する。メール、ウェブページ、サポートチケット、社内文書を読むエージェントは、通常の作業中にこうしたコンテンツに遭遇する可能性がある。

攻撃は、タスクを開始した人物には見えないまま進行することがある。エージェントは期待された文書を要約する一方で、密かに別のツールを呼び出したり、汚染された情報をメモリに取り込んだりする可能性がある。

したがって、Mend.ioの5層フレーミングはインベントリ手法として機能する。指示、権限、コード、データ、状態がシステムに出入りし得るすべての場所を特定するよう、チームに求めるものだ。

このインベントリには、デプロイ済みモデル以上のものを含めるべきである。エージェント設定、システムプロンプト、MCPサーバー、利用可能なツール、権限スコープ、メモリストア、モデルプロバイダー、依存関係、責任者を記録する必要がある。

この地図がなければ、1つの侵害されたコンポーネントが別のコンポーネントに到達できるかどうかを判断できない。また、統合の挙動が変わった際に、確信を持ってアクセス権を取り消すこともできない。

この出来事は、新しいプロトコルのリリースでも、単一の公開脆弱性でもない。より明確な本番環境の境界である。エージェントセキュリティは、完全な実行チェーンに従わなければならない。

この境界は、開発者、プラットフォームチーム、セキュリティエンジニア、AIベンダーに同時に圧力をかける。各グループが制御できるのはシステムの一部にすぎない一方、最も深刻な障害はその組織上の区分をまたいで進行する。

AIエージェントは言語を特権的なアクションへ変換する

LLMの出力が実際の権限を持つソフトウェアを制御するようになると、セキュリティ上の問題は本質的に異なるものとなる。

従来のチャットボットは、人がレビューするためのテキストを生成する。エージェントは、目標を解釈し、ツールを選択し、引数を組み立て、結果を確認し、別の人間の判断なしに行動を継続できる。

このループは、不適切なモデル応答がもたらす結果を変える。捏造された文は不便にすぎないが、データベースやデプロイツールに渡された捏造された指示は、運用インシデントになり得る。

ベンダー提案を比較するよう依頼された社内リサーチエージェントを考えてみよう。エージェントはアップロードされた文書を読み、共有ストレージを検索し、調達記録を照会し、推奨案を作成する。

悪意ある提案書には、別のフォルダから機密価格情報を取得するようエージェントに指示する内容が隠されている可能性がある。ストレージツールに広範な権限があれば、モデルによる誤った判断は実際の情報開示経路となる。

コーディングエージェントも同様の問題を生む。リポジトリを読み、依存関係をインストールし、テストを実行し、ファイルを変更し、プルリクエストを作成することがある。信頼できないIssueのテキストやパッケージ文書は、これらの能力を持つ同じモデルに影響を与える可能性がある。

MCPは、こうした接続を一貫して構築しやすくする。これは開発者にとって有益だが、同時にツール説明、ツール応答、リモートサーバーが、エージェントのその後の選択に影響を及ぼし得ることも意味する。

OWASPのエージェントセキュリティガイダンスは、主要なリスクとして、プロンプトインジェクション、ツール悪用、データ流出、メモリ汚染、過剰な自律性、連鎖的障害を挙げている。これらのカテゴリは、独立したものではなく相互に結び付いている。

特に重要なのはメモリである。永続的なエージェントメモリは将来のセッションのために情報を保存し、アプリケーションが設定、過去の作業、蓄積された知識を記憶できるようにする。

信頼できないコンテンツが検証なしにこのストアへ入ると、1回の攻撃が元の会話の終了後も残存し得る。後のユーザーは汚染された事実を受け取ったり、以前の文書の影響を受けた挙動を引き起こしたりする可能性がある。

マルチエージェントシステムは、被害範囲をさらに拡大し得る。1つのエージェントが、異なる権限を持つ別のエージェントへ、指示、要約、認証情報、ツール結果を渡すことができる。

侵害されたリサーチエージェントにはデータベース書き込み権限がないかもしれない。しかし、書き込み権限を持つ運用エージェントに、操作された調査結果を提供することは可能である。

すべてのモデルに悪意ある指示を無視するよう命じるだけでは、この問題を解決できない。モデルは業務を遂行するために自然言語を処理しなければならず、攻撃者は文言、文脈、エンコーディング、配信経路を変化させられる。

したがって、セキュリティの対象はアクション境界でなければならない。ツールが実行される前に、決定論的なソフトウェアが、エージェント、ユーザー、リソース、操作、パラメータの組み合わせが許可されているかどうかを判断すべきである。

読み取り操作が、気付かないうちに書き込みへ変わってはならない。1つのリポジトリへのアクセスが、すべてのリポジトリへのアクセスを与えてはならない。メールの下書きを作成する権限が、送信の許可を自動的に意味してはならない。

影響の大きい操作には、より強力な扱いが必要である。資金移動、本番環境の変更、アカウント管理、データ削除、外部公開、認証情報へのアクセスには、明示的な認可または人間による承認を求めるべきだ。

承認は、実際のアクションに紐付いていなければならない。「続行」のような曖昧な確認は、宛先、操作、影響を受けるリソース、重要なパラメータを表示する承認よりも弱い。

短命な認証情報も露出を減らす。エージェントは現在のタスクに必要な最小限の権限のみを受け取り、タスク終了時にその権限を失うべきである。

このアプローチは、特に開発者がタスク完了率と速度で成功を測る場合、摩擦を生むことがある。しかし代替策は、確率的な推論をアクセス制御システムとして機能させることだ。

言語モデルはアクションを提案できる。しかし、自らの権限を一方的に定義すべきではない。

MCPは接続を標準化するが、完全なガバナンスまでは提供しない

MCPは互換性の問題を解決する一方で、本番チームはその周囲にポリシーと説明責任の層を構築する必要がある。

MCPクライアントは、サーバーで利用可能なツール定義を取得し、モデルに提示できる。モデルは、それらの説明とパラメータスキーマを使ってツールを選択し、呼び出す。

この構造は、カスタム統合作業を減らす。互換性のあるクライアントは、サービスごとに別個のインターフェースを学ぶ代わりに、共有プロトコルを通じて多くのサーバーへ接続できる。

しかし、標準化された検出が、検出されたすべてのツールの信頼性を保証するわけではない。サーバーは侵害、なりすまし、設定ミスを受ける可能性があり、初回のセキュリティレビュー後に更新されることもある。

ツールポイズニングは、この信頼を悪用する。ツール説明内に埋め込まれた悪意ある指示は、ユーザーの通常の操作からは見えないまま、モデルに影響を与える可能性がある。

ツール応答にも同様の指示が含まれ得る。エージェントは応答をデータとして扱うかもしれないが、言語モデルは埋め込まれたテキストを、その後のアクションに影響を与える指示として解釈し得る。

最新のMCP認可ルールには、トークン検証、オーディエンスバインディング、トークン窃取、通信セキュリティ、リダイレクトリスク、混乱した代理人攻撃に対応する要件が含まれる。

これらの要件は、認証および認可の基盤を強化する。しかし、特定の業務アクションがユーザーの現在の目標に照らして適切かどうかは判断しない。

有効なアクセストークンは、そのスコープ内で認識された権限を確立する。信頼できないコンテンツを読んだ後に、モデルが正しい判断に至ったことまで証明するものではない。

本番システムには、モデルの意図とツール実行の間に制御点が必要である。この層は、ID、要求された操作、リソース、パラメータ、セッションリスク、データ分類、過去のアクションを評価できる。

Microsoftは、オープンソースのランタイムガバナンスアプローチを紹介した際に、このギャップを説明した。同社の内部ガバナンスベンチマークでは、45件の敵対的ケースと15件の有効なケースを含む60のプロンプトをテストした。

Microsoftは、システムがプロンプトのみの安全指示に依存した場合、ポリシー違反率が26.67パーセントだったと報告した。同社は方法論と再現用資料を提供しているが、この結果はあくまで同社独自の評価である。

それでもこの結果は、重要な設計原則を示している。指示追従性能を、決定論的なセキュリティ境界として扱うべきではない。

ランタイム制御プレーンは、各ツール要求を許可、拒否、またはエスカレーションできる。また、ツール定義をモデルに公開する前に検査し、応答をエージェントへ返す前に分析することもできる。

このような層では、スキーマ、パラメータ制約、リソースの許可リスト、レート制限、コスト上限、チェーンの最大深度を強制すべきです。エージェントが制御不能なリトライループに陥るのを許すのではなく、繰り返される失敗を止めなければなりません。

たとえば、カスタマーサポートのエージェントはアカウント記録を読み取り、返金に関する提案を作成する必要があるかもしれません。しかし、無制限のデータベースアクセスや、提案したすべての返金を直ちに実行する権限までは必要ありません。

ポリシー層は、読み取り対象を現在の顧客に限定し、機密フィールドを隠し、返金額に上限を設け、支払い前に人間による承認を要求できます。広範な運用権限を与えなくても、モデルの有用性は維持できます。

分離も重要です。高い権限を持つツールは、任意の外部MCPサーバーと同じエージェントコンテキストを共有すべきではありません。

公開Webコンテンツを読むエージェントが、内部管理ツールへの経路を自動的に得るべきではありません。こうした能力を分離すれば、悪意ある外部コンテンツが機密性の高い実行面に到達する可能性を低減できます。

セキュリティチームは、承認済みサーバーのレジストリも維持すべきです。各エントリには、サーバー所有者、コードソース、デプロイ先、認証方式、利用可能なツール、データアクセス、バージョン、レビュー状況を記載する必要があります。

ツールの説明、スキーマ、依存関係、権限、ネットワークの接続先が変更された場合、更新はレビューをトリガーしなければなりません。数か月前にレビューを通過したサーバーに、恒久的な信頼を与えるべきではありません。

MCPサーバーには、従来型のサービス保護も必要です。チームには、安全な通信、認証、パッチ適用、依存関係管理、入力検証、シークレット分離、ログ記録、インシデント対応が求められます。

プロトコルは、これらの統制を置き換えるものではありません。これらを一貫して適用しなければならない場所を、もう一つ増やすだけです。

真のトレードオフは自律性と封じ込めの間にある

機能を一つ追加するごとにエージェントの有用性は高まる一方、操作の成功時に生じ得る被害も拡大します。

このトレードオフは、エージェントのセキュリティをデプロイ直前に付け加えるチェックリストにできない理由を説明しています。セキュリティスキャナーが検査するはるか前に、プロダクト設計がシステムの最大権限を決定するためです。

ツールを持たないエージェントでも、有害または不正確なテキストを生成し得ます。ファイルアクセスを持つエージェントは文書を漏えいさせる可能性があります。シェルアクセスを持つエージェントはコマンドを実行でき、本番システムに接続されたエージェントは稼働中のインフラを変更できます。

広範な権限は、利便性のためにプロトタイプへ持ち込まれがちです。開発者は、詳細な認可に投資する前に、エージェントがエンドツーエンドのワークフローを完了できるかを検証したいと考えます。

こうしたプロトタイプは、予想以上に早く本番環境へ移行することがあります。一時的な認証情報が設定に残り、実験的なMCPサーバーが共有インフラとなり、寛容なツールスキーマが文書化されない依存関係へと変わります。

5層モデルは、こうした近道を明らかにする助けになります。ただし、インベントリだけでそれらを封じ込めることはできません。

各エージェントには、明確に定義された信頼境界が必要です。その境界では、誰が呼び出せるか、どのデータを受け取れるか、どのツールを使えるか、どのリソースに到達できるか、どの結果に承認が必要かを定めるべきです。

チームは、読み取り、下書き、提案、実行の各モードを区別すべきです。これらのラベルは、単なるプロンプトの文言ではなく、強制可能な権限に対応していなければなりません。

リサーチエージェントは、承認済みソースを読み、調査結果の下書きを作成できます。運用エージェントは、デプロイ計画を準備できます。別の統制されたプロセスが、その計画を検証して実行できます。

この分離は自律性を下げますが、レビュー可能な移行を生み出します。調査担当者は、情報がいつ提案になり、その提案がいつアクションになったかを確認できます。

可観測性も同じ目標を支えます。ログには、起点となったユーザー、エージェントID、モデルバージョン、プロンプトまたはポリシーのバージョン、MCPサーバー、ツール名、引数、レスポンス分類、承認記録、最終結果を記録すべきです。

機密データを、こうしたログへ無造作にコピーしてはなりません。セキュリティテレメトリーには、調査に十分なコンテキストが必要ですが、漏えいしたシークレットの新たな保管場所を作ってはなりません。

エージェントIDには特別な注意が必要です。多くのエージェントでサービスアカウントを共有すると、責任の所在を特定したり、侵害されたワークフローを一つだけ取り消したりすることが難しくなります。

IDを分離すれば、エージェントごとの権限設定と、より明確な監査証跡が可能になります。また、リサーチエージェントが突然書き込みアクセスを要求するような異常な挙動を、セキュリティチームが特定する助けにもなります。

政府のガイダンスでは現在、MCPを意図的なセキュリティ設計を要するインフラとして扱っています。NSAが2026年5月に公開したMCPセキュリティガイダンスでは、認証、認可、分離、サーバー検証、ライフサイクル管理、そしてプロトコルの構成要素にまたがるリスクについて論じています。

この注目は、成熟度の変化を示しています。MCPはもはや、ローカルデモを通じて語られる開発者向けの利便機能だけではありません。組織は、侵害されたツールが機密データや運用に影響を及ぼし得る環境での利用を評価しています。

Google Cloudのエージェントセキュリティ統制も、同様の点を指摘しています。このガイダンスは、専用のエージェントID、最小権限ロール、本番リソースへの読み書きツールアクセスを防ぐ制限を推奨しています。

これらは馴染みのあるセキュリティ原則です。しかし、エージェントは動的にアクションを選択し、開発者が列挙していないワークフローへ、個別には有効なツールを組み合わせるため、その適用はより困難になります。

安全でないツール連鎖は、許可された一つの操作の結果が有害な一連の操作を可能にしたときに生じます。検索ツール、ファイルリーダー、外部メッセージングツールは、それぞれ単独でレビューすれば低リスクに見えるかもしれません。

しかし、組み合わせるとデータ流出経路を作り出せます。エージェントは機密情報を検索し、それを読み取り、組織外へ送信します。

したがって、ポリシーは個別の呼び出しだけでなく、連続する操作も検査する必要があります。あるリクエストは単独では有効でも、同一セッション内の別イベントの後では疑わしい場合があります。

コンテキスト認識型の統制は、信頼できない入力と特権的な出力を含む組み合わせをブロックできます。また、エージェントが情報収集から外部アクションへ移る際に、再認可を要求することもできます。

この設計は、ユーザープロンプトの周囲にフィルターを加えるよりも要求が厳しいものです。プロダクト、プラットフォーム、ID、アプリケーションセキュリティ、運用の各チームによる連携が必要になります。

この組織的コストもトレードオフの一部です。セキュリティの責任をモデルプロバイダーだけに負わせながら、企業が広範な自律機能を主張することはできません。

本番環境のセキュリティでも保証できないこと

多層的な統制は露出を低減しますが、現在のどのフレームワークも、あらゆるモデル、ツール、コンテキストの組み合わせにわたってエージェントの安全を保証するものではありません。

最初の不確実性は、評価の質です。セキュリティテストは既知の攻撃を測定できますが、本番入力は継続的に変化し、攻撃者は公表された防御策に適応します。

レッドチームのテストスイートには、直接・間接のプロンプトインジェクション、不正なツール使用、権限昇格、メモリ汚染、データ流出、承認バイパス、再帰的実行、マルチエージェント伝播を含めるべきです。

チームは、デプロイ前と重要な変更の後に、これらのテストを実施すべきです。新しいモデル、システムプロンプト、メモリ設計、MCPサーバー、ツールスキーマ、検索ソース、ポリシーはいずれも攻撃対象領域を変え得ます。

テストに合格しても、恒久的な安全性は確立されません。それは、特定の条件下で定義済みの統制が定義済みの攻撃に耐えたことを示すにすぎません。

誤検知も別の問題を生みます。統制が正当なタスクをあまりに多く中断すれば、ユーザーは回避策を探すか、より広範な権限を求めます。

見逃しはより危険ですが、観測はより困難です。エージェントは要求されたタスクを完了しながら、データを漏えいさせたり、汚染されたメモリを保存したり、不必要なアクションを取ったりする可能性があります。

人間による承認も完全な解決策ではありません。特にアプリケーションが頻繁または不明瞭なプロンプトを提示する場合、ユーザーは確認に慣れ切ってしまう可能性があります。

攻撃者は、承認者に示される情報を操作することもあります。承認インターフェースは、モデルの説明だけではなく、信頼できる実行データからアクションの詳細を取得しなければなりません。

サプライチェーンリスクも未解決のままです。MCPデプロイメントには、異なる当事者が保守するサーバー、SDK、レジストリ、パッケージ、モデル、コンテナ、ホステッドサービスが含まれる可能性があります。

署名済みパッケージは、出所と完全性を確立できます。しかし、署名された挙動が安全であることや、リモートサービスが変更されずに維持されることを保証するものではありません。

組織は、再現可能なデプロイメント、固定されたバージョン、レビュー済みのソースコード、管理されたレジストリ、文書化された更新プロセスを優先すべきです。リモートサーバーには、一度限りの承認ではなく、継続的な検証が必要です。

緊急時の取り消しは、実用的でなければなりません。チームは、アプリケーションリリースを待つことなく、エージェント、サーバー、ツール、認証情報、権限を無効化できるべきです。

メモリシステムにも同等の統制が必要です。運用担当者には、調査のための証拠を保持しながら、疑わしいエントリを検査、隔離、失効、削除する手段が求められます。

この懐疑的な姿勢は、ベンダーの主張にも当てはまります。セキュリティ製品は、プロンプト保護、自動レッドチーミング、エージェント検出、ポスチャー管理、ランタイム強制をますます約束するようになっています。

これらの機能は防御に寄与し得ますが、購入者は各統制がどこに位置し、失敗時に何が起きるのかを問うべきです。疑わしいテキストにフラグを付けるだけの検出器は、結果として生じるアクションに対する認可の代わりにはなりません。

チームは、測定可能な証拠を求めるべきです。有用な質問には、どの攻撃クラスをテストしたか、評価データは利用可能か、バイパスをどう扱うか、強制機構がフェイルクローズするか、などがあります。

レイテンシーと可用性も検討すべきです。すべてのツール呼び出しの前に置かれるポリシーサービスは、重要なインフラになります。

そのサービスがフェイルオープンすれば、エージェントは統制なしに行動できます。フェイルクローズすれば、依存するワークフローが停止します。本番設計では、両方の結果に明確に対処する必要があります。

したがって、5層アプローチは保証ではなく、基盤です。これは、モデル単体のレビューでは見落とされるリスクをチームが特定する助けになります。

その成否は、各層を責任分担、強制可能なポリシー、反復可能なテスト、運用対応へと変換できるかにかかっています。これらの手順がなければ、このフレームワークは、露出を減らすことなく文書化するだけの図表になってしまいます。

エージェントセキュリティの成熟を示す3つのシグナル

次の段階は、強制可能なデフォルト、独立したテスト、実際のデプロイメントから得られる証拠によって評価されるでしょう。

最初のシグナルは、MCPクライアントとサーバーが、より限定的な認可をデフォルトで採用するかどうかです。最新の認可標準への対応は重要ですが、安全なデプロイメントにはリソース固有のスコープと、読み取り操作と書き込み操作の明確な分離も必要です。

より強固なエコシステムでは、広範な権限が明らかに例外扱いとなります。クライアントは各サーバーがアクセスできる対象をユーザーに示し、サーバーは別のリソース向けのトークンを拒否します。

デフォルトの制限は、標準化された接続性が封じ込めと両立できるという主張を強めます。環境依存の認証情報や過大なスコープへの依存が続けば、その主張は弱まります。

2つ目のシグナルは、ランタイムガバナンスに関する独立評価です。ベンダーベンチマークは有用な出発点を提供しますが、購入者には複数のモデル、ツール、攻撃手法にわたる反復可能なテストが必要です。

評価者は、攻撃の防止と正当なタスクの完了の両方を報告すべきです。すべてのツール呼び出しをブロックするシステムは、狭い意味では安全ですが、運用上の目的を果たせません。

結果では、プロンプト検出とアクション強制も分けるべきです。疑わしい言語を検出することと、禁止されたファイル読み取り、データベース更新、外部リクエストを防ぐことは別物です。

3つ目のシグナルは、企業が完全なエージェントインベントリとインシデント記録を作成できるかどうかです。組織は、どのエージェントがデプロイされ、誰が所有し、どのモデルを使用し、どのMCPサーバーに到達できるかを把握すべきです。

また、認証済みログから重大なアクションを再構築できる必要があります。IDの欠落、ツール記録の不完全さ、説明のない権限変更は、ガバナンスより導入のスピードが上回っている兆候です。

ここでナレッジマネジメントとセキュリティ運用が交差します。チームには、要件、エージェント構成、テスト結果、承認、インシデント、是正判断を結び付ける検索可能な記録が必要です。

統制された技術ナレッジベースは、エンジニアがこれらの記録を取得する助けになります。ただし、同じアクセス境界とデータ取り扱いの制約を遵守しなければなりません。

Google Newsへの掲載により、5層のセキュリティモデルはより広く認知されます。その持続的な重要性は、チームがこの認知をより小さな権限とより強力な実行制御へと転換できるかどうかにかかっています。

開発者は、まず本番ワークフローを1つ選び、すべての入力、モデル判断、メモリ書き込み、統合、認証情報、ツール呼び出し、出力をマッピングすべきです。次に、それらのポイント間にある安全でない移動を、決定論的なポリシーがどこで遮断できるかを特定します。

組織は、本番環境の各エージェントが何を実行できるか、どのIDがそれを認可するか、そして1つの侵害されたドキュメントをどのように封じ込めるかを説明できるでしょうか。答えが不十分なら、次に必要なのは別のプロンプトルールではありません。より狭い実行境界、テスト済みの承認経路、そしてエージェントの推論を超えて残る監査証跡です。