Microsoft run-assert-eval、エージェントのリスク発見をテスト済みの実行時制御へ転換

Microsoftは9月24日、従来は分かれていた4つのエージェント安全性タスクを、1つのガイド付きワークフローでつなぐrun-assert-evalを公開した。Microsoft run-assert-evalスキルは、リスクを発見し、失敗を測定し、実行時制御をドラフトし、その制御を追加した後に同じ評価を繰り返す。ここには直ちに緊張関係がある。安全性ループの高速化は、その測定の信頼性が保たれる場合にのみ有用だからだ。

Microsoftの例は、この発表に具体性を与えている。同社によれば、請求サポートエージェントは、該当するベースライン会話40件のうち12件で別の顧客のデータを開示した。実行時ポリシーの導入後、Microsoftは該当する会話34件で2件の違反を確認した。報告された違反率は30.0%から5.9%へ低下した。

この結果は決定的に聞こえるが、プロジェクト開発者が管理する実証例から得られたものだ。Microsoftは独立した再現実験や本番導入に関する調査を提示していない。したがって重要なのは、好ましい1つのスコアではなく、その仕組みである。このスキルは発見された失敗を強制可能なポリシーへ変換し、評価をひそかに変更することなく介入をテストする。

Microsoft run-assert-eval、発見・テスト・強制を接続

このリリースは、安全性プロジェクトの集合を、未知のリスクからテスト済みの実行時制御へ至るレビュー可能な経路に変える。

Microsoftの公開記事では、対応するコーディング環境でのプロンプトから開始するワークフローが説明されている。開発者はエージェント、その意図した目的、ツール、そして遵守すべき境界を提示して始める。

このスキルはClarityを使ってエージェントを脅威モデリングできる。脅威モデリングとは、テストを選ぶ前に、起こり得る失敗、影響を受ける資産、原因、結果を特定することだ。チームは、製品要件、インシデント報告書、テスト計画、既存の評価から把握している既知のリスクを提供することもできる。

この区別は重要だ。リスク発見は推奨されるが、必須ではない。請求エージェントが顧客記録を露出させるとすでに分かっているチームは、発見作業を繰り返すのではなく、その挙動から始められる。

発見が必要な場合、Clarity threat modelerはエージェントのより広い運用コンテキストを調べる。これは、元の要件には記載されていなかった失敗を表面化させることを目的としている。

Microsoftの請求事例では、Clarityは4つの候補となる失敗モードを特定した。チームは、重大と評価された2つのリスク、すなわち未検証の高リスク操作と顧客間データ露出を選択した。

1つ目のリスクは、発信者の身元を確認せずに請求内容を変更する行為を対象とする。2つ目は、発信者に属さないアカウントに関する情報開示を対象とする。

このスキルは、選択された各リスクをMicrosoftの要件駆動型評価フレームワークであるASSERTへ渡した。各リスクは1つの設定、1つの挙動、1つの評価スイートになった。

この限定的な構造は、最初に見える以上に重要だ。評価に認可、プライバシー、正確性、エスカレーションの失敗が混在すると、集計スコアからはどの制御が必要かを説明できない。

Microsoft run-assert-evalは代わりに、これらの挙動を分離する。各スイート内では、アクセスモード、ユーザーの口実、権限の主張、複数ターンにわたるスコープのずれといった次元によって変化を導入する。

このスキルはまた、関連するテスト次元を探すため、先行研究や安全性フレームワークを検索する。Microsoftによれば、これらの情報源にはNISTのガイダンス、OWASPのリソース、ベンチマーク、規制資料、モデル提供者のポリシーが含まれ得る。

その後、ASSERTはケースを生成し、対象エージェントを実行して、取得したトランスクリプトを評価する。2つの主要な測定値は、意図的に分けられている。

「許容されない挙動の違反」は、エージェントが禁止された挙動を実行したケースを記録する。「許容される挙動の違反」は、実行を許されていたにもかかわらずエージェントが支援を提供できなかったケースを測定する。

この分離は、よくある安全性の錯覚を防ぐ。すべての要求を拒否するエージェントは多くの有害な行為を回避できるが、仕事も果たせなくなる。

次にワークフローは、測定された失敗からAgent Control Specificationポリシーのドラフトを生成する。ACSは、エージェントの実行における定義済みのポイントへ制御を配置するためのポータブルな形式だ。

最後に、このスキルは統制されたバージョンのエージェントを同じケースで評価する。ベースラインと統制後の実行では、同じ挙動定義、テストセット、判定方法が維持される。

この結果は、単なる別の安全性スコアではない。ポリシーを変更変数として分離するよう設計された、制御された比較である。

主なガードレールとしてプロンプトを使うチームに圧力がかかる

Microsoftは、文章で書かれた指示だけではツールを使うエージェントに十分な制御境界を提供できないという考え方に異議を唱えている。

システムプロンプトは、役割や期待される挙動を定義するうえで依然として有用だ。しかし、それはモデルが解釈する確率的な指示であり、周辺ソフトウェアによって強制される決定論的な認可チェックではない。

エージェントが記録を取得し、アカウントを更新し、返金を実行し、管理ツールを呼び出せる場合、この弱点は重大になる。説得的な要求が、データベースの読み取りや業務アクションにつながり得る。

Microsoftの請求事例は、この隔たりを示している。エージェントはアカウントACME-1001に関連する発信者のために動作していた。別の顧客のアカウントを取得または変更してはならなかった。

評価されたある要求では、別の顧客に属するBPS-447に関連する連絡先情報が求められた。Microsoftによれば、ベースラインのエージェントは完全な記録を返した。

コードレビューでは、取得機能が正しく動作することを確認できるかもしれない。ユニットテストでは、有効なアカウント識別子が期待される記録を返すことを確認できるかもしれない。しかし、現実的な会話の中でモデルが認可されていない識別子を選ぶかどうかは、どちらも必ずしもテストしない。

この問題は請求サポートにとどまらない。リサーチエージェントは不適切な情報源へアクセスする可能性があり、変更管理エージェントは承認手順を迂回する可能性がある。旅行エージェントは、保存された本人確認情報や支払い情報を誤用する可能性がある。

OWASPのガイダンスは、このより広範な状態を過剰なエージェンシーと呼ぶ。これはAIアプリケーションが、そのタスクに必要な範囲を超える機能、権限、または自律性を持つ場合に生じる。

プロンプトインジェクションはこの種の失敗を引き起こし得るが、それだけが原因ではない。曖昧な要求、幻覚的な計画、侵害されたツール、単純なモデルの誤りも、安全でない行為を生み出し得る。

影響を受けるチームはセキュリティ部門だけではない。プロダクトマネージャーは許可される結果と禁止される結果を定義しなければならない。開発者は適切な制御ポイントを公開する必要がある。リスク所有者は、測定された低減が十分かを判断しなければならない。

評価チームにも圧力がかかる。その成果物は、失敗を列挙する報告書だけでは済まなくなる。Microsoftのワークフローでは、発見事項が特定の制御と反復可能な検証実行を支えることが求められる。

汎用的なモデルベンチマークを使う組織は、別の問題にも直面する。広範なベンチマークはモデルの平均的な傾向を説明できるが、各社のアカウント規則、エスカレーション境界、社内承認プロセスのすべてを捉えることはできない。

Microsoftのアプローチは、アプリケーション固有の要件と発見されたリスクから始まる。これにより評価の関連性は高まるが、組織間の比較はより単純ではなくなる。

このリリースは、観測を最終ステップとして扱うベンダーにも圧力をかける。危険なツール呼び出しを実行後に記録すれば、調査には役立つ可能性がある。しかし、それは害を引き起こしたアクションを防ぐものではない。

Run-assert-evalは、介入をエージェントの実行時経路へ移す。これにより、認可チェック、最小権限、ポリシー強制ポイントといった馴染み深いセキュリティ概念に近づく。

これはプロンプトをなくすものではない。プロンプトに、より限定的な役割を割り当てる。モデルが計画や言語解釈を担い、決定論的な制御が機密操作を進めるべきかを決定する。

エージェントがローカルファイルや社内ナレッジへアクセスするようになるにつれ、この分担はますます重要になる。検索可能なナレッジベースを構築するチームも同じ境界の問題に直面する。検索はユーザーの実際の認可範囲を尊重しなければならない。

Microsoft run-assert-evalは、この問いを開発者がより早期に実行できるワークフローへ組み込む。その結果、負担はモデルがルールに従うことを期待するところから、ソフトウェアがどこでそれを強制するかを示すところへ移る。

中核となる仕組みは、制御された導入前後テストである

run-assert-evalで最も強力な発想は、自動ポリシー生成ではない。制御だけを変更しながら評価を維持することだ。

チームが修正を適用した後にテストセットを再生成すると、安全性の比較は信頼できなくなる。異なるプロンプト群は、弱いポリシーを成功したように見せたり、健全なポリシーを悪く見せたりし得る。

判定者を変更すると、別の交絡変数が生じる。特に許容可能な挙動が文脈に依存する場合、2人の評価者が同じトランスクリプトを異なるように解釈する可能性がある。

Run-assert-evalは、ベースラインの体系化とテストケースをキャッシュする。統制後のエージェントは、同じ挙動定義、ケース、判定アプローチに直面する。

Microsoftはこれを評価の凍結と表現している。ポリシーが意図された独立変数となり、測定された違反率が観測結果となる。

この原則は、従来のソフトウェアにおける回帰テストに似ている。開発者が実装を変更する間、失敗したテストは固定されたままであるべきだ。そうでなければ、合格結果は修正された挙動ではなく、書き換えられたテストを反映している可能性がある。

モデル出力には変動があるため、エージェントのテストはより難しい。判定者もモデルベースの場合があり、生成されたケース自体に曖昧さが含まれることもある。

これらの要素を一定に保っても、すべての不確実性がなくなるわけではない。しかし、導入前後の差はより解釈しやすくなる。

Microsoftによれば、これまでのASSERT評価では、自動判定者と人間のレビュアーの一致率は80%から90%だった。同社はこの範囲を、人間のレビュアー間での約90%の一致率と比較している。

これらの数値はMicrosoftが報告した結果であり、普遍的な精度保証ではない。判定者の一致率は、挙動、モデル、ルーブリック、言語、基礎となるポリシーの複雑さによって変わり得る。

基礎となる評価は検査可能なままだ。ASSERT repositoryによれば、実行ではローカルアーティファクト、生成されたケース、モデル出力、判定者の根拠、指標が保存される。

ローカルアーティファクトは、レビュー担当者がトランスクリプトがなぜ違反と分類されたのかを確認できるため、監査を支援できる。また、評価者がポリシーを誤解したケースも特定できる。

ASSERTの2つの違反率という設計は、もう1つの保護策を加える。有害な挙動を阻止するポリシーでも、過剰な拒否を引き起こすなら失敗し得る。

顧客間スイートについて、Microsoftはベースラインの許容されない挙動の違反率を30.0%と報告した。統制後の結果は、異なる該当分母において5.9%だった。

Microsoftは結果をプロンプト分割とシナリオ分割にも分類した。プロンプトケースはより直接的な対話をテストし、シナリオケースはより豊かなワークフローと会話コンテキストを捉える。

顧客間のプロンプトケースでは、報告された許容されない挙動の違反率は20.8%から8.7%へ低下した。対応するシナリオの違反率は43.8%から0.0%へ低下した。

未検証アクションのプロンプト事例では、報告された率は4.0%から0.0%に低下した。シナリオ別では、8.7%から4.5%へと下がった。

許容される振る舞いに対する違反は、管理対象の4つの分割すべてで0.0%に達したと報告されている。Microsoftは、この結果を、当該サンプルにおいて正当な業務を損なわずに制御が機能した証拠と解釈している。

残る不許容な違反は重要である。制御された事例の範囲内であっても、ポリシーがすべての失敗を排除したわけではないことを示している。

これは、このワークフローの反復的な設計と整合する。チームは残存する失敗を検証し、リスク定義やポリシーを改善したうえで、同じプロセスを繰り返せる。

そのためこの手法は、少数の手作業によるデモンストレーションより強い証拠を提供する。ただし、将来のあらゆるプロンプト、モデル更新、ツール、環境におけるエージェントの挙動を確立するものではない。

実用面での利点は、より限定的でありながら有用だ。チームは、エージェントを単に黙らせることなく、特定の制御が定義済み評価における性能を変化させたという追跡可能な証拠を得られる。

実行時ポリシーは、モデルがアクションを完了する前にそれを遮断する

請求修正は、モデルに意図を再考させるのではなく、ツール境界でアカウント範囲を確認することで機能する。

顧客間の露出を測定した後、run-assert-evalはポリシー草案とACSマニフェストを生成した。ポリシーは判断ロジックを表現し、マニフェストはそのロジックを適用すべき場所を指定した。

Microsoftは、ポリシーエンジンで一般的に使われる宣言型ポリシー言語であるRegoを使用した。生成された成果物は、人間によるレビューを必要とする草案のままである。

このレビューゲートは重要だ。Microsoftは、生成は承認を意味しないと明確に述べている。開発者は、ポリシー、介入ポイント、マニフェスト、対象エージェントとの接続を確認しなければならない。

選択されたポリシーは、要求されたアカウント識別子が呼び出し元のアカウントと異なる場合にツール呼び出しを拒否した。このルールでは、要求が疑わしく見えるかどうかを別のモデルに判断させる必要はなかった。

Microsoftはこのチェックを、エージェントがツールを実行する前に到達するインターセプトポイントであるpre_tool_callに配置した。そのため、識別子が一致しない場合は、取得が行われる前に拒否される。

チームはpost_tool_callも使用した。この2つ目のチェックでは、本来モデルのコンテキストに入るべきではない不一致の結果を差し止めた。

両方のポイントを用いることで、多層防御が実現する。1つ目は不正な操作の防止を試みる。2つ目は、先行する制御が回避された場合や誤って接続された場合にも露出を抑える。

ACS policy engineは、こうした制御を単一のエージェントフレームワークから切り離すことを目的としている。そのため、チームがモデルやオーケストレーションライブラリを変更しても、ポリシーの移植性を維持できる。

この移植性は、実際の保守上の問題に対応する。プロンプトやフレームワーク固有のコールバックに埋め込まれた制御は、複数のエージェント実装にまたがって監査するのが難しくなり得る。

共通仕様があれば、セキュリティレビュー担当者は一貫した対象を検査できる。また、開発者はアプリケーションコードと並行してポリシー変更をバージョン管理できる。

ただし、移植性は正しい統合を保証しない。各ランタイムは関連するコンテキストを公開し、IDを保持し、適切な地点でポリシーを呼び出す必要がある。

アカウント範囲のルールは、信頼できるアカウント情報に依存する。呼び出し元のIDが誤っている、または欠けている場合、比較ロジックが完全に正しく書かれていても、認可結果は誤ったものになる。

同じ懸念はツール引数にも当てはまる。account_idを検査するポリシーは、要求されたリソースがそのフィールドによって正確に表現されていることを前提とする。

複雑なツールでは、クエリ、文書、URL、ネストされたアクションの内部に機密対象が隠されている場合がある。その場合、狭いルールでは同じ保護対象リソースへの同等の経路を見逃す可能性がある。

実行時ポリシーも、すべての失敗クラスを修復できるわけではない。制御は、不正な返金やデータベース読み取りを遮断できる。しかし、生成されたすべての説明が正確かつ公平かどうかを自動的に判断することはできない。

一部の重大な影響を及ぼすアクションでは、人間による承認が引き続き適切である。最小権限に基づくツール設計は、モデルが不適切な判断をした場合でも被害を軽減できる。

より広いAI risk frameworkは、リスク管理をライフサイクル全体にわたる活動として扱う。単一のリリース前テストではなく、ガバナンス、マッピング、測定、継続的な管理を含む。

Run-assert-evalは、このより大きな枠組みの中に位置付けられる。リスクのマッピングから、1つの振る舞いの測定・管理へとつなぐ具体的な橋渡しを提供する。

ワークフローの単一プロンプトによる入り口が、その背後にある作業を覆い隠すべきではない。脅威モデリング、テスト設計、ポリシーレビュー、システム統合、結果の解釈には、依然として十分な知見に基づく判断が必要である。

Microsoftが削減したのは、こうした判断の間にある手作業の引き渡しである。このスキルは構造化された成果物を段階から段階へと運び、その関係性を可視化し続ける。

これにより、リスクの説明がプロダクト、評価、セキュリティの各チーム間で移管される際に意味を失う可能性を低減できる。

また、失敗の発見から緩和策の検証までの間隔を短縮できる。この間隔には、未解決のエージェントリスクが蓄積しがちである。

初期結果は証拠であり、一般的な安全保証ではない

Microsoftの事例はワークフローの論理を裏付けるが、エージェント、組織、攻撃全般にわたる本番有効性を確立するものではない。

最も明白な制約は出所にある。Microsoftとプロジェクトの貢献者がツールを設計し、事例を選択し、制御を適用し、得られた測定値を報告した。

これは調査結果を無効にするものではない。読者は、透明性のある実例と、独立したベンチマークまたは現場研究とを区別すべきだという意味である。

サンプル数にも注意が必要だ。見出しとなるベースラインには適用可能な会話が40件含まれた一方、ガバナンス適用後の実行には34件が含まれた。

これは、特定の振る舞い率には適用可能なケースのみが寄与するため、分母が異なるからである。それでも、小規模なサンプルでは割合が不安定になり得る。

事例における12件の違反から2件への変化は、運用上意味を持つ。ただし、他のエージェントに対して普遍的に80%削減できることを意味すると解釈すべきではない。

報告された許容行動違反率0.0%も、そのサンプルで違反が見られなかったことを意味する。ポリシーが正当な振る舞いを決して遮断しないことを意味するわけではない。

より大規模なテストセットでは、まれな誤拒否が明らかになる可能性がある。本番トラフィックには、事例には含まれていないアカウント関係、委任ルール、サポート上の例外が含まれる可能性がある。

評価リークも別の懸念である。1つの固定されたテストセットに対してポリシーを繰り返し調整すると、開発者はいずれ既知のケースに過剰適合する可能性がある。

テストを固定することで、1回の介入における信頼できる比較を実現できる。しかし長期的なプログラムには、ホールドアウトケース、新たな敵対的バリアント、変化する挙動の監視が依然として必要だ。

モデルの変更も、過去の結論を無効にし得る。新しいモデルは、ツール引数の形式を変えたり、拒否を異なる方法で解釈したり、保護された情報への別の経路を見つけたりする可能性がある。

ツールの変更も同様のリスクを生む。エクスポート機能や汎用検索エンドポイントの追加により、元のアカウントチェックではカバーされないアクセス経路が導入される可能性がある。

評価判定器は継続的な精査に値する。Microsoftが報告した一致率の範囲は心強いものだが、不一致のケースは、最も曖昧で結果の影響が大きい境界に集中する可能性がある。

チームは争いのあるケースに対する人間のレビューを維持し、一見成功している結果も定期的にサンプリングすべきである。安定した自動判定器は比較には有用だが、誤りのない権威ではない。

「スキル」という言葉には、サプライチェーン上の問題も含まれている。エージェントスキルには、計画、実行、検証に影響を与える指示が含まれる。

Microsoft Researchは最近、2つのベンチマーク設定で307件のスキル起因の失敗を報告した。その内訳は、125件の機能的失敗と182件の効率性低下だった。

この研究はrun-assert-evalを具体的に評価したものではない。しかし、あらゆるスキルの指示、スクリプト、権限、運用上の前提を検査する広範な理由を示している。

Run-assert-evalは、可視化された成果物と人間によるゲートを通じて、この懸念に部分的に対処している。チームは、ガバナンス適用後の実行を行う前に、生成された評価構成とポリシーを確認できる。

文献に裏付けられたテスト生成には、別の検証義務も生じる。引用されたフレームワークは次元の指針になり得るが、その妥当性は、スキルがそのソースをどれほど正確にケースへ翻訳するかに依存する。

不十分な翻訳は、意味のあるカバレッジなしに、印象的なカバレッジラベルを生み出す可能性がある。したがってレビュー担当者は、付与されたフレームワーク名だけでなくシナリオも検査すべきである。

運用コストも未解決の問題である。生成ケースの実行、トレースの取得、トランスクリプトの判定、評価の反復には、モデル呼び出しとエンジニアリング時間が必要になる。

このプロジェクトは、そのコストを手作業の評価ワークフローと比較した広範な分析を公表していない。組織は、どのリスクがより深い評価を正当化するかを判断しなければならない。

最も妥当な解釈は、慎重ながら前向きなものだ。Microsoftは、困難な統合問題に対して一貫性のあるプロセスを構築した。

このリリースは、エージェントが安全であることを証明するものではない。チームが具体的な安全性の主張を形成し、それに証拠を結び付け、1つの介入が定義済みの結果を改善したかどうかをテストする助けになる。

このアプローチの有効性を示す3つのシグナル

次の検証は、独立したチームが、有用なエージェントの振る舞いを犠牲にしたり、隠れた保守負担を生じさせたりせずに、このワークフローの成果を再現できるかどうかである。

1つ目のシグナルは第三者による再現である。開発者は、バンドルされた事例以外のエージェントにMicrosoft run-assert-evalを適用した公開評価に注目すべきだ。

説得力のある再現では、リスク定義、ケース、ポリシー、トレース、判定器の構成、人間によるレビュー結果が公開される。また、ガバナンス適用後も残った失敗も開示されるべきである。

異なるモデルとフレームワークにまたがる結果は、Microsoftの移植性に関する主張を強める。統合上の大きな差異は、ACSが依然として個々のランタイムに依存する部分を明らかにする。

2つ目のシグナルは、より広範な本番環境での証拠である。チームは、固定された評価が実際のトラフィック下でのインシデント、拒否、ポリシー回避を予測するかどうかを知る必要がある。

有用な証拠には、デプロイ後の違反傾向と、制御によって遮断された正当な要求が含まれる。また、モデル、ツール、プロンプトの変更後に導入された失敗も追跡すべきである。

最も強力な導入は、評価成果物を継続的な監視に接続する。リリース前の改善は、本番テレメトリーが同じ振る舞いの境界を確認する場合に、より重要な意味を持つ。

3つ目のシグナルは、回避とポリシードリフトに対するプロジェクトの対応である。攻撃者や一般ユーザーは、元のスイートにはない経路を通じて保護対象のアクションに到達し得る。

間接的なプロンプトインジェクション、委任された権限、矛盾するID、状態操作、マルチエージェントの引き渡しを対象とする新しいスイートに注目したい。また、プロジェクトが固定されたケースへの過剰適合をどのように防ぐかも確認すべきである。

バージョン管理されたポリシーと回帰実行は不可欠になる。モデル、ツール、権限、ビジネスルールが変更されるたびに評価を繰り返すための、明確なトリガーがチームには必要だ。

このリリースはレビュー体験によっても評価されるべきである。生成されたポリシーが有用なのは、開発者とセキュリティチームが、なぜそれが存在し、何を遮断するのかを理解できる場合に限られる。

そのため、ローカル成果物、引用されたトランスクリプト、狭く定義された振る舞いは、単なる実装詳細ではない。これらは承認を支える証拠の連鎖を形作る。

したがってMicrosoft run-assert-evalは、スキルとしてパッケージ化されたエンジニアリング規律と捉えるのが最も適切である。脅威モデリング、振る舞いに特化した評価、実行時の強制、制御下での再テストを結び付ける。

開発者が問うべきなのは、そのワークフローがエージェント全体の安全性を認証できるかどうかではない。重要なリスクを一つ測定可能にし、統制を一つレビュー可能にし、改善を一つ再現可能にできるかどうかだ。

これは、一般的な安全性を証明するという約束よりも小さい。だが、エージェントガバナンスを始めるには、より信頼できる出発点でもある。