AI 代理人責任許可およびヒューマンオーバーライドデリジェンスの取得

導入

Agentic AI は、ソフトウェアが情報の生成からアクションの開始に移行できるため、勤勉の境界線を変更します。エージェントは、支払いの草案、ユーザーの作成、クラウド インフラストラクチャの変更、顧客とのコミュニケーション、在庫のコミット、返金の承認、申請書の提出、または規制された結論の準備を行うことができます。同じモデルは、読み取り専用のリサーチ ワークフローではリスクが低く、資格情報や運用ツールに接続されている場合はトランザクション クリティカルになります。したがって、取得チームはワークフロー レベルで権限と結果を注意深く管理する必要があります。

現在の標準の状況は発展しつつあります。 NIST は 2026 年 2 月に AI エージェント標準イニシアチブを立ち上げ、ソフトウェアと AI エージェントのアイデンティティと認可に関する作業を個別に提案しました [7-10]。その公開資料では、識別、認可、監査、否認防止、および即時注入制御が実際的な問題として特定されています。 OWASP は、過剰なエージェンシーを過剰な機能、許可、または自律性の組み合わせとして説明し、影響の大きいアクションについては最小限の特権、下流の認可、および人間の承認を推奨しています [17-19]。これらのソースは、有用なコントロールの質問を定義しています。これらは、ターゲットが管理を実施していること、または特定の責任の配分が法的に有効であることを確立するものではありません。

実際には人間の監視も機能しなければなりません。欧州連合法第 14 条 AI では、特定の高リスク システムについては、必要に応じて出力を無視、無効化、反転、または中断する機能など、効果的な監視を行うように設計することが求められています [23-24]。表示された承認ボタンは、レビュー担当者がアクションを理解したこと、十分な情報を持っていたこと、適切な権限を持っていたこと、または実行を阻止できることを示すものではありません。トランザクションのデリジェンスでは、リクエストから結果および救済に至るまでの完全なパスをテストする必要があります。

この文書ではその道筋を示します。法的助言を必要とする経済的リスクとして責任を扱い、セキュリティ証拠を必要とする技術的および組織的システムとして許可を扱います。そして、両方を価格、取引保護、統合に結び付けます。このフレームワークは、AI エージェント ビジネスまたは AI 対応ターゲットを評価する戦略的バイヤー、プライベート エクイティ スポンサー、取締役会、取引チーム、融資者向けに設計されています。

1 買収の決定と責任範囲を定義する

最初の文書には、買い手がビジネスを買収する理由と、どのエージェントの機能が価値に含まれるかを記載する必要があります。この理論は、顧客の分布、独自のワークフロー データ、より低いサービス コスト、専門家チーム、購入者の運用の自動化、または制御層の所有権に依存する可能性があります。それぞれの論文では、責任と統合に関するさまざまな問題が生じます。社内導入用に取得した製品は、購入者が従業員、顧客、および規制上の影響に直接さらされる可能性があります。これらの影響は、ターゲットがベンダーとして運営されている間には限定的でした。

境界では、すべての法人、製品、エージェント、ワークフロー、環境、顧客構成、モデル、コネクタ、ツール、資格情報、サービス アカウント、ポリシー エンジン、承認サービス、データ ストア、およびインシデント プロセスを識別する必要があります。ターゲットが所有するコンポーネントを、顧客が管理する ID、オープンソース ソフトウェア、サードパーティ モデル、パートナー プラットフォームから区別する必要があります。デモンストレーションでは、誰の権限が使用されたか、またはその権限が終了時に譲渡されるかどうかを示さずにアクションを示すことができます。

購入者は、一般的なアーキテクチャを検討する前に、結果として生じるアクションを列挙する必要があります。結果には、資金の移動、権利の創設または終了、情報の開示、生産システムの変更、顧客または規制当局への声明、雇用の決定、安全への影響、および不可逆的な公表が含まれます。このリストは、法務、セキュリティ、財務、運用、保険の管理を整理するための記録となります。

責任は、観察された義務、主張された請求、起こり得る義務、および将来の運営リスクに分けられる必要があります。 IAS 第 37 号は引当金と偶発債務に関する原則を定義しており、一方 IFRS 第 3 号は企業結合で引き受ける負債に対処しています [1-3]。会計上の結論は取引ごとに異なります。勤勉記録は、法的分析や会計分析の技術的なスコアを置き換えるのではなく、事実、範囲、不確実性、および責任あるアドバイザーを保存する必要があります。

2 プリンシパルエージェント権限チェーンをマッピングする

すべての本番アクションは、プリンシパル、エージェント、権限のチェーンを通じて追跡できる必要があります。プリンシパルとは、その目的が追求されている個人または組織です。エージェントは、定義されたワークフロー内で動作するソフトウェア インスタンスです。権限は、本人または他の権限のある当事者が委任した、制限された一連のアクションです。このチェーンには、使用された ID、適用されたポリシー、選択されたツール、提供されたパラメーター、受け取った承認、実行応答、および保持された証拠も含まれます。

ターゲットは、ユーザーの権限がどのように表現されるかを示す必要があります。従業員の OAuth スコープを通じて従業員の代わりに機能するエージェントは、共有特権サービス アカウントを使用するエージェントとは異なります。共有アカウントは、帰属、分離、取り消しを弱める一方で、運用上は便利である可能性があります。購入者は、委任された権限がユーザー、目的、リソース、時間、値、およびアクションの種類によって制限されたままであるかどうかをテストする必要があります。

オーケストレーションでは権限が失われる可能性があります。調整エージェントは、別のプラットフォームを通じてツールを呼び出す専門エージェントに委任する場合があります。最終システムは、最後のツール呼び出しのみを記録する場合があります。ディリジェンスは、完全な委任チェーンを再構築し、下流コンポーネントが元のプリンシパルよりも大きな権限を取得できないことを確認する必要があります。制御は、モデルによって解釈される命令だけではなく、信頼できるシステムによって強制される必要があります。

アクションによって紛争が生じた場合、否認防止が重要になります。記録には、どの認証された ID が作業を要求したか、どのエージェントとバージョンが動作したか、どの証拠が提示されたか、どの人間が承認したか、正確にどのようなアクションが実行されたか、および記録が変更できるかどうかが示される必要があります。 NIST の現在のエージェントアイデンティティに関する作業では、実装に注意が必要な領域として監査と否認防止が強調されています [8-10]。購入者は、ターゲットの実装を検査し、代表的な記録をテストする必要があります。

3 実稼働許可グラフを構築する

アカウントをアクションに関連付けずにリストする場合、権限インベントリは不十分です。運用許可グラフは、プリンシパル、エージェント、ツール、リソース、機能、環境、および承認ルールを接続する必要があります。明示的な権限と、グループ、ロール、トークン、プラットフォーム、顧客統合を通じて継承された有効なアクセスの両方を示す必要があります。一時的な権限、緊急ロール、および休止中のコネクタは同じグラフに属します。

権限は、操作 (検出、読み取り、作成、変更、削除、承認、実行、エクスポート、偽装、委任、管理) ごとに分類する必要があります。グラフでは、本番環境とテスト環境、内部環境と顧客環境を区別する必要があります。また、資格情報が意図されたエージェント パスの外で使用できるかどうかも識別する必要があります。限定的に記述されたツールでも、広範なデータベース、クラウド、またはメッセージングの権限を持つアカウントで実行できます。

購入者は、必要な権限と有効な権限を比較する必要があります。必要な権限は、定義されたタスクと顧客の約束に従います。有効なアクセス許可とは、ID と基盤となるシステムが実際に許可するものです。違いは許可余剰です。余剰は、到達可能なリソース、アクションの種類、および潜在的な結果によって定量化される必要があります。ターゲットは、広範なダウンストリーム権限を保持しながらインターフェースのオプションを減らし、爆発範囲を変更しない場合があります。

証拠には、現在の ID プロバイダーのエクスポート、クラウドとアプリケーションのロール、ツール定義、コネクタ構成、コードとしてのポリシー、トークンの有効期間、シークレット ストア、承認ルール、失効テストが含まれる必要があります。スクリーンショットとポリシー文書はコンテキストを提供します。機械可読なエクスポートと観察された実行により、運用状態の強力な証拠が得られます。

4 アクションを結果と可逆性によって分類する

アクション分類により、どのコントロールと取引応答が比例するかが決まります。有用なマトリックスは、財務上の影響、法的影響、情報の機密性、業務の混乱、外部の可視性、影響を受ける人口、および回復可能性をスコア化します。スコアは、ツール呼び出しの見かけの単純さではなく、連鎖アクションを含むアクションのもっともらしい結果に基づく必要があります。

可逆性を実現するには、反対のコマンド以上のものが必要です。削除された記録は復元できますが、外部開示を取り消すことはできません。資金の移動後に支払いが取り消される場合があり、遅延や回収リスクが発生する可能性があります。顧客メッセージは、契約への依存や風評被害が残ったまま修正することができます。したがって、分類では、技術的に回復可能な行為、運用上回復可能な行為、財務的に回復可能な行為、および事実上不可逆的な行為を区別する必要があります。

アクションの速度は露出に影響します。一度レビューを受けて実行された弱い決定は、検出される前に数千のアカウントにわたって実行された同じ脆弱性とは異なります。価値、数量、頻度、顧客数に制限があると、損失が限定される可能性があります。購入者は、ポリシー施行ポイントで制限が適用されるかどうか、またエージェントがアクティビティを複数のコールに分割して制限を回避できるかどうかをテストする必要があります。

分類によって、承認、記録、監視、回収、保険分析が促進されるはずです。読み取り専用の証拠収集は自動制御の下で行われる場合があります。結果的なアクションの準備には検証が必要な場合があります。不可逆的なアクション、または外部から見えるアクションの実行には、独立した権限のある人が必要になる場合があります。実際の法的要件は、ワークフローと管轄区域によって異なります。

5 モデル外でのポリシー適用のテスト

自然言語の指示はエージェントを導くことができます。これらは、結果的なアクションを許可する唯一のメカニズムであってはなりません。購入者は、各ツールのリクエストを ID、リソース、アクション、コンテキスト、および制限に対して検証するポリシー適用ポイントを特定する必要があります。完全なメディエーションとは、再試行やセカンダリ エージェントまたはキャッシュされた資格情報を介した呼び出しなど、関連するすべてのリクエストがチェックされることを意味します。

OWASP の過剰な機関指導では、機能、権限、自律性を制限し、ダウンストリーム システムで承認を強制することが推奨されています ^[17]。買収チームは、敵対的なシナリオおよび通常のシナリオを通じてこれらのコントロールをテストする必要があります。許可されていないリソース、変更されたパラメータ、間接的なプロンプト挿入、期限切れの権限、競合する命令、値またはボリュームの制限を超える繰り返しの呼び出しと要求を試行する必要があります。

政策変更も必然的です。ターゲットには、ツール スキーマ、許可されたアクション、承認しきい値、システム プロンプト、モデル ルーティング、およびサービス アカウント ロールを変更できるユーザーが表示される必要があります。変更は分離、レビュー、テスト、リリース、ロールバックに従う必要があります。エージェント ロジックと運用ポリシーの両方を変更できる開発者は、名目上の承認制御をバイパスできる可能性があります。

購入者は、ポリシーバージョンを製品バージョンにリンクするテスト証拠を保持する必要があります。ラボ管理は、同じ施行パスが顧客の作業に適用される場合にのみ役立ちます。例外、非常時アクセス、および手動オーバーライドには、定義された権限、限られた期間、強化されたログ記録および遡及レビューが必要です。

6 勧告作成の承認と実行を区別する

トランザクションチームは、人間か自律かという二項対立を避ける必要があります。ワークフローでは、証拠の観察、アクションの推奨、トランザクションの準備、承認の要求、承認されたトランザクションの実行、および結果の検証を行うことができます。異なるコンポーネントが各ステージを所有する場合があります。ディリジェンス マップでは、情報がどこで意思決定となり、どこで意思決定が世界の変化となるかを特定する必要があります。

推奨事項が決定的なものとして提示されたり、体系的に信頼されたり、未承認のデータから生成された場合には、推奨事項に責任が生じる可能性があります。レビュー担当者が定期的に承認する支払い、契約、または構成を設定する場合、準備によってリスクが生じる可能性があります。査読者が要約だけを見た場合、承認が弱くなる可能性があります。承認後にパラメータまたは状態が変更された場合、承認されたアクションから実行が逸脱する可能性があります。

購入者は、承認と実行の間の結合をテストする必要があります。承認記録では、正確なアクション、リソース、金額、取引相手、ポリシー、有効期限を特定する必要があります。重要な変更は承認を無効にする必要があります。執行では、古い承認、変更された承認、または再実行された承認を拒否する必要があります。システムは、提案された状態と実行された状態の両方を保持し、相違点を調整する必要があります。

この分離は評価にも影響を与えます。人間の権限の下で作業を確実に準備する製品は、自律的に実行しなくても大きな価値を提供する可能性があります。経営陣の予測では、顧客、規制当局、保険会社が説明責任を必要とする場合、承認の削除が価値を高めると想定すべきではありません。経済モデルには、実際に顧客に受け入れられる制御設計のコストとスループットを含める必要があります。

7 人間によるオーバーライドが有効かどうかを評価する

人間参加型ラベルは、能力、情報、権限、タイミング、独立性、作業負荷に分解する必要があります。レビュー担当者は、アクションとその結果を理解するために十分な情報を必要とします。レビュー担当者は、それを拒否、変更、または停止する実際の権限を持っている必要があります。介入は、取り消し不能に実行される前、または被害を抑えるのに十分な早めに行われなければなりません。

インターフェイスのデザインは重要です。承認表示では、モデルによって生成された説明とソース証拠を区別し、主要なパラメーターを表示し、ポリシーの例外を強調表示する必要があります。操作的なデフォルトや曖昧なバンドルを避ける必要があります。承認疲れにより、名目上の管理が日常的な確認になってしまう可能性があります。目標は、レビューの量、時間、拒否、修正、エスカレーション、および下流の結果を測定する必要があります。

自立は行動次第です。ユーザーは通常のワークフローを承認する一方で、財務、セキュリティ、または規制されたアクションには別の役割が必要になります。職務の分離は、単に文書化するだけでなく、アイデンティティとポリシーとして実装する必要があります。エージェントは、独自のレビュー担当者を選択したり、不都合な証拠を隠蔽したり、人間の決定後に承認リクエストを書き換えたりすることができてはなりません。

オーバーライドおよび停止メカニズムは、負荷と障害が発生した状態でテストする必要があります。購入者は、エージェントの資格情報の取り消し、キューにあるアクションの中断、実行中の作業の封じ込め、および安全な回復を観察する必要があります。 EU AI 法の第 14 条では、特定の高リスク システムに関連する監視機能として、監視、解釈、無効化、取り消し、および中断を特定しています。 ^[23]。適用には法的分析が必要です。運用テストはトランザクション全体で引き続き役立ちます。

8 ニアミスと隠れた介入のインシデントを再構築する

インシデントの評価には、不正なアクション、過剰な許可、即時注入、データ漏洩、誤った決定、承認の失敗、リプレイ、ツールの誤用、暴走コスト、顧客からの苦情、制御のバイパスを含める必要があります。ニアミスや手動リカバリは、システムが危うく影響を及ぼしそうになった場所、または文書化されていない介入に依存していた場所を示すため、貴重です。

購入者は、セキュリティ チケット、カスタマー サポート、サービス クレジット、エンジニアリングの問題、モデル評価の失敗、クラウド ログ、保険通知、法的請求、払い戻し、取締役会の報告など、いくつかの記録を調整する必要があります。単一のレジスターでは、製品品質、顧客の成功、操作エラーなどに分類されるイベントが省略される場合があります。共通の識別子とタイムライン分析により、関連するイベントが明らかになります。

各イベントについて、ディリジェンスは、開始条件、使用された権限、検出時間、影響を受ける範囲、封じ込め、回復、顧客とのコミュニケーション、コスト、法的評価、修復の検証を特定する必要があります。根本原因ラベルは、モデルの動作、データ、オーケストレーション、ツール、アイデンティティ、ポリシー、インターフェイス、人間によるレビュー、組織プロセスを区別する必要があります。

隠れた介入はリスクと経済の両方に影響を与えます。スペシャリストは、製品の指標に現れることなく、エージェントを継続的に監視し、アクションを修復し、顧客を落ち着かせることができます。購入者はリクエストから最終結果までのワークフローをサンプルし、人的時間と給与計算およびサポート システムを調整する必要があります。管理が再設計される前にこの労力を取り除く買収モデルは、相乗効果を誇張しながら責任を増大させる可能性があります。

9 アクションコホートを通じてエクスポージャを定量化する

予想されるエクスポージャーは、全社的な単一の確率ではなく、行動コホートによって推定される必要があります。コホートは、ワークフロー、アクション クラス、顧客、管轄区域、権限レベル、承認設計、モデル バージョン、および環境によって定義できます。各コホートは、量、例外、不正な試行、無効化、取り消し、インシデントおよび回復措置を観察する必要があります。

単純化された予想損失モデルでは、アクションの量にイベントの確率と結果を乗算し、検出、対応、顧客、法律、規制、および修復のコストを加算します。過去の頻度が低く、影響が集中している可能性があるため、テール シナリオには個別の処理が必要です。共有ポリシー、認証情報、モデル、またはコネクタが多くの顧客に同時に影響を与える場合、相関関係が重要になります。

管理者の仮定は明確であり、観察された証拠とは切り離されている必要があります。導入履歴が短い場合、権限が最近拡張された場合、またはインシデントがキャプチャされなかった場合、クレームが存在しない可能性は低いとは言えません。外部ベンチマークはシナリオ設計に情報を提供する可能性がありますが、ターゲットのワークフロー、制御、契約上の割り当てと一致することはほとんどありません。

モデルは、総エクスポージャー、保険の仮定、契約上の上限、補償の権利、回収可能性、および残存エクスポージャーを示す必要があります。回復可能性は、除外、制限、通知、保持、取引相手の信用およびタイミングについてテストする必要があります。回復が遅れたり争われたりした場合でも、買収の決定は堅実なままでなければなりません。

10 顧客契約と責任分担を確認する

顧客の契約は実際のワークフローにマッピングする必要があります。関連条項には、サービスの説明、許可された使用、顧客の指示、承認、データの役割、モデルとサブプロセッサーの変更、セキュリティ、監査、インシデント通知、保証、免責条項、サービス レベル、補償、賠償責任の上限、保険、終了と移行が含まれます。購入者は、顧客間で交渉された例外を比較する必要があります。

責任は、プロバイダー、顧客、モデルベンダー、クラウドプラットフォーム、統合パートナー、エンドユーザーの間で分担される場合があります。製品が意味のある顧客制御なしにアクションを実行する場合、または販売プロセスが管理された結果を表す場合、顧客が決定に対して引き続き責任を負うという条項は、実際的な価値が限られている可能性があります。弁護士は、各管轄区域における執行可能性と行為を評価する必要があります。

デリジェンス チームは、契約上の許可と技術的な許可を調整する必要があります。契約で読み取り専用アクセスが許可されている一方で、実稼働資格情報で変更が許可されている場合、そのギャップはトランザクションにとって重大です。顧客がモデル変更前に承認を必要とする場合、ターゲットにはバージョンと通知がどのように管理されるかを示す必要があります。文書化されていない顧客固有の制御により、統合が遅れる可能性があります。

収益の質は負債の配分に関連しています。結果価格設定により、運営リスクをプロバイダーに移転しながら、支払い意欲を高めることができます。顧客が広範な終了またはサービスクレジットの権利を留保している間、最小限のコミットメントで現金をサポートできます。モデルには、実際の約束に必要な配送コストと管理コストを含める必要があります。

11 規制および管轄区域の経路を評価する

Agentic AI は、セクター、消費者、雇用、金融、プライバシー、サイバーセキュリティ、製品、競争および専門的なルールと交差する可能性があります。トランザクション チームは、結果として生じる各ワークフローを、それを提供する法人、顧客の場所、影響を受ける人物、データの場所、意思決定の種類にマッピングする必要があります。グローバル製品には、展開全体で異なる義務とリスクの割り当てが存在する可能性があります。

EU AI 法は、リスクベースの枠組みを確立し、高リスクシステムに対する人間による監視要件を含んでいます [23-24]。データ保護当局は、自動化された意思決定、説明責任、データガバナンスに関するガイダンスを公開しています[25-26]。米国の連邦および州の要件は発展を続けていますが、部門の規制当局はAIが有効な行為に既存の法律を適用することができます。この文書は、適用可能性に関する法的結論を提供していません。

買い手はターゲットの法定目録、分類分析、影響評価、規制当局への対応、顧客表明、変更監視プロセスを要求する必要があります。在庫が現在の製品および管轄区域に関連付けられているかどうかをテストする必要があります。ワークフロー、権限、顧客数が変化すると、汎用ポリシーが時代遅れになる可能性があります。

規制の変更は評価と統合に属します。コンプライアンス作業では、新しい承認の役割、データ管理、文書化、テスト、顧客への通知、または製品の制限が必要になる場合があります。トランザクション モデルには、コスト、タイミング、収益への影響を含める必要があります。合法的な運営または譲渡が重大な同意または是正に依存する場合、終了条件が適切な場合があります。

12 テストデータのプライバシー知的財産と機密保持

多くの場合、行動する権限は、データにアクセスする権限を意味します。購入者は、ワークフローごとにデータ ソース、目的、法的根拠、顧客の指示、保持、転送、モデルの使用および削除をマッピングする必要があります。エージェントのメモリ、トレース、可観測性により、プライマリ システムを超えて機密情報が複製される可能性があります。ツールの結果、ユーザーがアクセスを許可されていないソースからのデータが取り込まれる可能性があります。

権利登録には、コード、プロンプト、ポリシー、ツール スキーマ、ワークフロー設計、評価セット、顧客構成、トレーニングおよびフィードバック データ、ドキュメント、特許、商標、企業秘密が含まれている必要があります。作成者、譲渡、ライセンス、制限、サブライセンス、管理の変更、終了を特定する必要があります。サービスの実行に必要な顧客データへのアクセスによって、譲渡可能な資産が自動的に作成されるわけではありません。

機密保持のリスクは行動にも及びます。エージェントは、承認インターフェイスを通じて情報を送信したり、外部システムに入力したり、推論を開示したりできます。購入者は、宛先のホワイトリスト、データ損失防止、編集、顧客の分離、ログをテストする必要があります。制御が再試行、セカンダリ エージェント、およびサポート ツールに適用されることを検証する必要があります。

IFRS 3 および IAS 38 は、企業結合における識別可能な無形資産に関連する会計要件を規定しています [1、4]。購入価格の割り当ては、購入者が顧客データまたはサードパーティのテクノロジーを使用する操作権限を持っているかどうかを解決するものではありません。法的および技術的移転の分析は、評価の前提に先立って行う必要があります。

13 サードパーティモデルのツールとエージェントプロトコルを評価する

エージェント製品は通常、モデル プロバイダー、クラウド、ID システム、エンタープライズ アプリケーション、データ サービス、コネクタに依存します。購入者は、各依存関係、契約、許可範囲、サービス レベル、価格、データ処理、監査権、変更管理、継続性、補償および終了の一覧表を作成する必要があります。マテリアルの依存関係は、ターゲットの主要なアーキテクチャに現れるのではなく、ツールまたはプロトコルの背後に存在する場合があります。

プロトコルの相互運用性により、配布が増加し、許可範囲も広がります。購入者は、サーバーとツールがどのように検出、認証、説明、信頼されるかを特定する必要があります。ツールのメタデータはモデルの選択に影響を与える可能性があります。コネクタまたはスキーマを更新すると、モデルを変更しなくても効果的な動作が変更される場合があります。レジストリ、署名、許可リスト、バージョンの固定、およびテストを検査する必要があります。

プロバイダー条件により、障害がサードパーティのサービスに起因する場合でも、ターゲットに責任を割り当てることができます。その場合、ターゲットは顧客に対して回収できる以上の負債を負う可能性があります。トランザクション モデルでは、一連の上限、除外、保険を示す必要があります。集中には、顧客全体にわたる共通のモデル、クラウド、アイデンティティ、コネクタの依存関係が含まれる必要があります。

移植性を主張するには、本番環境と同様のテストが必要です。モデルまたはツールを置き換えると、動作、遅延、コスト、評価、顧客の承認が変わる可能性があります。購入者は、移行期間と制限された機能の期間を測定する必要があります。テスト済みの代替が行われていないマルチプロバイダー図は、復元力の弱い証拠です。

14 セキュリティプロンプトインジェクションと混乱した副リスクを調査する

エージェントは、正当な権限を利用して無許可の目的を追求すると、混乱した代理人になる可能性があります。間接的なプロンプトの挿入、操作されたツールの出力、侵害されたメモリ、または悪意のあるピア エージェントがアクションに影響を与える可能性があります。結果は、有効なアクセス許可とポリシーの適用によって決まります。したがって、セキュリティレビューは、攻撃経路をビジネスアクションと回復に結び付ける必要があります。

購入者は、脅威モデル、レッドチームの結果、セキュリティテスト、依存関係スキャン、機密管理、隔離、監視、およびインシデント対応を検査する必要があります。顧客のドキュメント、メッセージ、Web サイト、ツールの出力からの入力をテストする必要があります。また、承認内容を操作して、レビュー担当者が実行されたアクションとは異なるアクションを承認できるかどうかもテストする必要があります。

最小限の権限により、潜在的な危害が軽減されます。エージェント、ユーザー、サービスの ID を個別に設計すると、アトリビューションを向上させることができます。有効期間の短い認証情報、リソース制限、トランザクション制限、宛先制御、および独立した検証により、露出を制限することができます。ロギングでは、管理されていない機密データの保存を作成することなく、イベントを再構築するのに十分なコンテキストを保存する必要があります。

MITRE ATLAS と OWASP は、テストを構造化できる脅威と制御の分類法を提供します [17-21]。ターゲットのリスクは、独自のワークフロー、アーキテクチャ、顧客との取り組みを通じて評価される必要があります。一般的なチェックリストに合格しただけでは、本番アクションが許可されており、回復可能であることを証明することはできません。

15 責任を評価と購入価格に結び付ける

割引キャッシュフロー、市場アプローチ、先行取引、コストアプローチなどの伝統的な評価方法が引き続き有効です[5-6]。エージェントの責任は、収益の持続性、貢献、管理コスト、保険、運転資本、修復、顧客維持、統合のタイミング、テールエクスポージャを通じてインプットに影響を与えます。購入者は、これらの商品を再構築する前に、高成長率の適用を避ける必要があります。

独立した予測には、顧客と規制当局が受け入れる運用管理モデルを含める必要があります。人間によるレビュー、セキュリティ運用、評価、法的サポート、およびインシデントへの対応には配送コストがかかります。それらを即時の相乗効果として取り除くと、価値が誇張される可能性があります。追加の制御によりコンバージョンと維持率が向上する可能性がありますが、その利点は証拠によって裏付けられ、個別にモデル化される必要があります。

責任スケジュールでは、既知の義務、特定の偶発的事項、管理の修復および将来の営業リスクを区別する必要があります。既知の項目は、契約および会計に応じて、純負債または運転資本に影響を与える可能性があります。不確実な事項は、価格、エスクロー、補償または保険に影響を与える可能性があります。将来のリスクは、買収日の負債を生み出すのではなく、事業計画や統合に影響を与える可能性があります。

値は証拠の状態によって公開される必要があります。制限された権限、テストされた人間による制御、完全なアクション記録、安定したインシデントのパフォーマンス、および調整された契約を備えたターゲットは、ポリシーステートメントに依存するものよりも強力な予測をサポートします。確率加重モデルは、未解決の各コントロールがキャッシュ、タイミング、ダウンサイドをどのように変化させるかを示す必要があります。

16 デザイン表現の補償エスクローと保険

定義が技術的な現実を反映している場合、取引文書は特定されたリスクを割り当てることができます。代表者は、権限、顧客の指示、データの使用、知的財産、セキュリティ、インシデント、法規制遵守、材料モデルまたはツールの変更、評価記録、および保険に対処する場合があります。開示スケジュールでは、ワークフローおよび顧客レベルで例外を特定する必要があります。

特定の補償は、既知の請求または定義されたエクスポージャーに対処できます。エスクローまたはホールドバックは回復可能性をサポートできます。保証および補償保険は、除外、保持および引受を条件として、選択された代表リスクを移転する場合があります。サイバー、テクノロジーのエラーと不作為、専門職の補償およびその他のポリシーは、被保険者、期間、トリガー、除外、制限、サブリミット、および通知について検討する必要があります。

保険は額面通りにモデル化されるべきではありません。アルゴリズムエラー、自律的行動、規制上の罰則、契約上の責任、または既知の状況に対する補償は、制限されるか除外される場合があります。買い手は、ポリシーの文言、仲介業者の提出物、請求履歴、および支配権変更の扱いをアドバイザーとともに確認する必要があります。制限、保持、収集遅延の後も残留暴露が残ります。

取引チームは法的保護と行動を連携させる必要がある。広範な保証を証明して回復するのは難しい場合があります。運用許可のエクスポート、インシデント記録、顧客の例外に関連付けられた定義済みの表現は、よりテストしやすくなります。起草と執行には取引顧問が必要です。

17 完了条件と約款を使用して管理ギャップを是正する

クロージング条件は、買収した事業の譲渡と運営に必要な事項に焦点を当てるべきです。例には、孤立した資格情報の取り消し、重要な権限の余剰の削減、承認バインディングの実装、ログの保存、知的財産の譲渡、顧客またはベンダーの重要な同意の取得、重大なインシデントの解決などが含まれます。可能であれば、署名する前に証拠と受け入れテストを定義する必要があります。

重大度の低い作業は、クローズ前の規約、統合計画、特定の予算を通じて管理できます。販売者は、通常の管理を維持し、モデル、ツール、許可、インシデント、および顧客の義務に対する重大な変更を通知する必要があります。買い手は、法的または競争上の懸念を引き起こす方法でクロージングする前に、運営管理を引き受けることを避けるべきです。

検討の延期は、永続的な運用証拠に関連付けることができます。対策には、重要な調査結果の終結、顧客維持の検証、コスト管理後の貢献度の調整、移植性のテスト、合意された統合マイルストーンの完了などが含まれる場合があります。インセンティブは、受け入れ、安全性、現金なしに自律量の増加に報いるべきではありません。

トランザクション ファイルには、どのギャップが決定、価格、構造、タイミング、または統合に影響を与えるかを示す必要があります。重要性のない長いリストは、最も大きな結果をもたらす経路を解決できないまま、取引を遅らせる可能性があります。ガバナンスは、各条件に対して所有者、証拠基準、期限を割り当てる必要があります。

18 4 つの仮想取得ケースを構築する

国庫支払い代理人は、サプライヤーへの支払いを準備し、制限内で実行します。その主なリスクは、支払い権限、受取人の変更、金額制限、分離、リプレイ、回収です。顧客契約代理人は、承認されたテンプレート内で修正案を作成し、送信します。その危険には、明らかな権限、不正なコミットメント、開示、バージョン管理、顧客の信頼が含まれます。

クラウド管理エージェントはインシデントを診断し、インフラストラクチャを変更します。その危険には、特権昇格、セキュリティ構成、サービス中断、データ アクセス、および段階的な変更が含まれます。規制請求代理人は証拠を収集し、請求プロセスの一部を推奨または実行します。そのリスクには、不公平な結果、不正確な支払い、説明、異議申し立て、記録保持、および部門の義務が含まれます。

各ケースでは、仮想的な管理上の仮定を使用して、フレームワークがどのように機能するかを示します。この仮定は、特定の企業や市場を説明するものではありません。実際の買収には、契約、生産許可輸出、承認記録、行動追跡、事件、請求、保険、財務記録、法的分析が必要です。

これらの事例は、自律性だけが推進力ではないことも示しています。契約代理人は訴訟の量が少なくなり、法的影響が大きくなる可能性があります。クラウド エージェントは、大きな技術的影響範囲を維持しながら、強力な変更制御の下で動作する可能性があります。証拠の準備が高度に自動化されている場合でも、請求代理人は人間の判断を必要とする場合があります。価格は検証されたリスクと経済モデルに従う必要があります。

19 暴露と修復の経済学の実例

仮想財務省のケースでは、年間 120 万件のアクション、不正行為の確率が低く、平均結果が高く、予想される年間損失と対応コストが USD 4.8 million であると想定されています。契約ケースは 420,000 アクションと USD 3.6 million を想定しています。クラウドの場合は 750,000 のアクションと USD 7.2 million を想定しています。請求ケースは 240 万件のアクションと USD 5.4 million を想定しています。これらの金額は管理上の例示です。

また、4 つのケースでは、アイデンティティ、ポリシーの適用、承認バインディング、ロギング、テスト、顧客作業、および運用プロセスの変更にわたる 1 回限りの修復の USD 22 million も想定しています。反復的な増分制御コストは、USD 9 million で想定されます。事業計画では、どの金額が既存の収益を保護するか、成長を可能にするか、損失を削減するかを特定する必要があります。

別の確率加重責任モデルでは、支払いイベント、契約上のコミットメント、クラウドの中断、データ開示、および規制結果イベント全体で予想される総エクスポージャーの USD 29.4 million が割り当てられます。図では回収可能性が不明確であるため、保険および賠償金の回収は除いています。この数字は意思決定ツールであり、会計上の見積りではありません。

感度は、アクションの量、イベントの確率、結果、検出時間、回復、顧客の集中度、保険および制御の有効性を変化させる必要があります。相関関係のある障害は、特定のケースに値します。共有ポリシーの変更により、個々のワークフロー履歴が強力であるように見えても、多くの顧客が危険にさらされる可能性があります。

20 権限の継続性を中心に最初の 100 日間を計画する

第一の目的は、責任ある権限の継続です。購入者は、所有権を確立する際に、本番環境の ID、ポリシー、承認、ログ、顧客との約束、およびインシデント対応を保存する必要があります。プラットフォームを変更する前に、重要な認証情報、人材、ベンダー、顧客固有の管理を特定する必要があります。

統合は行動コホートごとに進める必要があります。読み取り専用ワークフローは、多くの場合、より早く移行できます。結果の高い実行は、バイヤー環境でテストされた ID、ポリシー、承認バインディング、モニタリング、および回復を待つ必要があります。各移行には、ベースライン、変更計画、テスト、ロールバック、および必要に応じて顧客または規制当局の決定が必要です。

購入者は、モデル、プロンプト、ツール、アイデンティティ、承認を同時に変更することを避ける必要があります。制御されたシーケンスは、パフォーマンスまたは制御の変化の原因を特定するのに役立ちます。システムが統合された後も、ターゲットの証拠は、収益、保証、顧客および規制の目的でアクセス可能なままでなければなりません。

シナジーレポートには、承認されたアクション、人間によるレビュー、例外、インシデント、調整後の貢献および現金が含まれる必要があります。例外コスト、顧客損失、または残留エクスポージャーが増加した場合、人件費の削減は相乗効果を実現できません。取締役会は、買収理論に関連付けられた簡潔な権限と責任のダッシュボードを受け取る必要があります。

21 閉店後の政府代理人の権限

クローズ後のガバナンスでは、ビジネスオーナー、技術オーナー、セキュリティオーナー、法務またはコンプライアンスのオーナー、および重要なワークフローごとに独立した保証の役割を割り当てる必要があります。運営委員会は、アクション分類、リスク選好度、権限制限、顧客例外および重大な変更を承認する必要があります。法律、政策、または顧客の義務によって義務付けられている場合、結果的な決定には責任ある人間の所有権が維持される必要があります。

指標には、有効な許可、許可の余剰、承認量、拒否と変更、不正な試行、ポリシーの失敗、取り消し、インシデント、検出と回復、顧客からの苦情、サービス クレジット、残留エクスポージャと管理コストが含まれる必要があります。施策はワークフローと顧客ごとに分割する必要があります。総発生率が低いと、集中した重大な結果のコホートが見えにくくなる可能性があります。

変更ガバナンスは、モデル、ツール、プロンプト、ポリシー、アイデンティティ、しきい値、データ、顧客構成をカバーする必要があります。リリース証拠には、通常のシナリオ、境界シナリオ、敵対的なシナリオに対するテストが示されている必要があります。重要な変更は、契約または法律で義務付けられている場合、顧客、保険会社、または規制当局による審査を開始する必要があります。

独立した保証は、ポリシーだけではなく実稼働システムをテストする必要があります。内部監査、外部の専門家、または管理部門は、権限チェーンをサンプリングし、決定を再現し、修復を検証できます。調査結果は、資本配分、製品範囲、顧客との約束に関連している必要があります。

22 投資委員会の権限記録を作成する

投資委員会の文書は、技術的な調査結果を価値、保護、運営責任に関する決定に反映する必要があります。それは、考えられる最大のエクスポージャーを引き起こす 10 個以下の結果的な行動経路、各経路についてレビューされた生成証拠、未解決のギャップ、および残留リスクを受け入れる責任者を特定する必要があります。小規模な構成観察の長いカタログでは、価格や運用能力を変更する取得の問題が曖昧になる可能性があります。

各マテリアルパスについて、記録には、プリンシパル、委任された目的、有効な身元、許可、執行ポイント、人間による制御、行動量、考えられる結果、検出方法、回復ルート、および顧客の割り当てを記載する必要があります。観察された生産証拠と、管理者の表現およびシナリオの仮定を区別する必要があります。その後、委員会は、エクスポージャーがすでに存在しているのか、不確実な事象に起因するものなのか、閉鎖後の統合によって生じたものなのか、あるいは計画された管理改善に依存しているのかを確認することができます。

この論文では、負債の見方と財務モデルを調和させる必要があります。該当する場合、人員配置、保険、顧客の修復、技術作業および統合の遅延の管理が、予測キャッシュ フローに表示される必要があります。特定の請求、条項、または偶発的な事項については、会計顧問および法律顧問と検討する必要があります。価格調整、エスクロー、補償および条件付対価は、閉店後に顧客にサービスを提供するために必要な運営管理の代替として扱われるべきではありません。

意思決定の選択肢は明確である必要があります。買い手は、検証後に提示された価格で続行する、値を調整する、ワークフローまたはエンティティを除外する、条件が満たされるまでクロージングを遅らせる、展開を段階的に行う、追加の売り手保護を要求する、または取引を拒否することができます。それぞれの選択肢には、決定を変更する証拠とそれを入手する期限を記載する必要があります。この構造により、未解決の赤旗が記録されていない仮定になるのを防ぎます。

委員会は閉鎖後の権限モデルも承認する必要がある。代理店事業を所有する経営陣、結果的な決定権限を保持する役員、技術管理およびセキュリティ管理の所有者、保証ルート、および取締役会のエスカレーションを必要とする状況を指名する必要があります。最初の 100 日の予算と順序は、承認されたリスク選好と顧客のコミットメントと一致する必要があります。

最後に、決定記録には反対意見と条件を保存する必要があります。査読者は、より多くの証拠が蓄積されるまで、より低い権限レベルを要求しながら、商業論文を受け入れることができます。顧客の同意、サードパーティモデルへの依存、または保険の除外が最終的な問題であると考える人もいます。これらの立場を記録すると、説明責任が向上し、統合チームに自律機能をリリースするための明確な境界が与えられます。

証拠公開スケジュールにより、条件を測定可能な署名後の作業に変換できます。各項目には、ベースライン記録、テスト母集団、合格しきい値、独立したレビュー担当者、障害への対応、および価格、タイミング、または導入への影響を指定する必要があります。証拠は、委員会、取引顧問、保険会社、統合チームが同じ結果を参照できるように、安定した識別子を使用して管理されたリポジトリに保存する必要があります。テストが失敗した場合、単にチケットをクローズするのではなく、影響を受けるアクション コホートと顧客のコミットメントに対応する必要があります。このスケジュールは、権限が拡大される前に、サポートされていない仮定を期限切れにし、新たな承認を必要とするものでなければなりません。この規律は、投資決定を所有権変更後の経営行動に結び付けます。

四半期レビューでは、残留エクスポージャを承認された買収案件と比較し、すべての重要な出発、所有者、救済策、期限を文書化する必要があります。

結論

AI エージェントの買収は、モデルの機能とソフトウェア収益だけでは理解できません。買い手は、そのアイデンティティ、許可、ツール、承認、アクションによって価値と責任を生み出すことができる権限システムを獲得することになります。したがって、勤勉記録は、誰が、誰の権限の下で、どのような証拠と救済策を用いて、どのような結果を引き起こすことができるかを証明する必要があります。

提案されたフレームワークは、その質問をトランザクション作業に変換します。境界を定義し、プリンシパルとエージェントのチェーンを再構築し、権限グラフを構築し、結果として生じるアクションを分類し、強制と人間によるオーバーライドをテストし、アクションとコホートのエクスポージャーを定量化し、調査結果を評価と取引保護に結びつけます。現在の基準と規制を質問と管理のソースとして扱いますが、ターゲット固有の証拠を必要とします。

最も強力な買収ケースは、限定された権限、下流の強制執行、有意義な人的管理、完全な行動記録、調整された顧客契約、テストされた回収、およびコストのかかるクロージング後の運用モデルによってサポートされます。証拠が未熟なままの場合、買い手は想定価値を減額したり、修復を要求したり、統合を段階的に進めたり、取引構造を通じてリスクを割り当てたりすることができます。投資決定には、残留エクスポージャーとそれを受け入れる責任者を記録する必要があります。

権限・許可証拠室

運用プリンシパルとエージェントのマップ、ID、サービス アカウント、グループ、ロール、トークン、シークレット、ツール定義、コードとしてのポリシー、権限のエクスポート、顧客スコープ、一時的な権限、非常事態アクセス、取り消しテスト、および変更履歴を提供します。必要な権限と有効な権限を調整し、結果として生じる権限の余剰を特定します。

人間の制御と行動に関する文書

アクションの分類、承認ルール、レビュー担当者の役割、インターフェイスのキャプチャ、承認と実行のバインディング、有効期限、リプレイ防止、テストの上書きと停止、レビュー指標、不一致、エスカレーション、取り消し、および回復の証拠を提供します。リクエストから最終状態までの代表的な署名付きトレースを含めます。

賠償責任契約と保険ファイル

顧客とプロバイダーの契約、交渉された例外、苦情、請求、条項、偶発的事項、保険契約、仲介業者への提出、通知、回収および法的分析を提供します。技術的な許可と運営行為を契約上の権限と責任の割り当てにマッピングします。

トランザクションおよび統合制御ファイル

評価調整、エクスポージャーシナリオ、修復予算、表明、開示、補償、エスクロー、クロージング条件、規約、条件付対価、最初の100日計画、顧客の同意、コントロールオーナーおよび取締役会の報告を提供します。価値のリリースごとにテストするために必要な証拠を保存します。

提案された勤勉構造。結論には、ターゲット固有の法的会計の技術的および商業的レビューが必要です。

提案された制御ラダー。ワークフロー固有の法律ポリシーと顧客の要件が実際の権限を決定します。

すべてのディメンションが本番環境で動作しない限り、目に見える承認ステップでは不十分です。

管理上の前提条件。数値は観察、予測、会計上の見積り、または評価の結論ではありません。

USD 百万単位の管理上の仮定。実際の範囲には、検証済みのアーキテクチャ顧客と法的証拠が必要です。

USD 百万単位の管理上の仮定。予想される総エクスポージャーは、保険補償回復税または購入価格処理前の USD 29.4 million です。

提案されたフレームワーク。実際の金融商品には、最新の法定税務会計規制保険および財務上のアドバイスが必要です。

情報源

1. IFRS財団。 IFRS第3号の企業結合。 一次ソースを読む
2. IFRS財団。 IAS 第 37 号は、偶発負債および偶発資産を規定しています。 一次ソースを読む
3. IFRS財団。企業結合における条件付対価の会計処理。 一次ソースを読む
4. IFRS財団。 IAS 第 38 号無形資産。 一次ソースを読む
5. IFRS財団。 IFRS第13号の公正価値の測定。 一次ソースを読む
6. 国際評価基準評議会。国際評価基準。 一次ソースを読む
7. 米国国立標準技術研究所。 AI エージェント標準イニシアチブ。 2026 年 8 月 14 日に更新されました。 一次ソースを読む
8. 米国国立標準技術研究所。 AI エージェント標準イニシアチブを発表します。 2026年2月17日。 一次ソースを読む
9. 米国国立標準技術研究所。ソフトウェアおよび AI エージェントの ID と認証の導入を加速します。 2026年。 一次ソースを読む
10. 米国国立標準技術研究所。ソフトウェアエージェントのアイデンティティと権限に関する新しいコンセプトペーパー。 2026 年 2 月 5 日。 一次ソースを読む
11. 米国国立標準技術研究所。人工知能リスク管理フレームワーク。 一次ソースを読む
12. 米国国立標準技術研究所。生成 AI プロファイル NIST AI 600-1。 一次ソースを読む
13. 米国国立標準技術研究所。サイバーセキュリティフレームワーク2.0。 一次ソースを読む
14. 米国国立標準技術研究所。デジタル ID ガイドライン。 一次ソースを読む
15. 米国国立標準技術研究所。ゼロトラスト アーキテクチャ SP 800-207. 一次ソースを読む
16. サイバーセキュリティおよびインフラストラクチャセキュリティ庁。安全な設計。 一次ソースを読む
17. OWASP財団。 LLM06 2025 過剰な代理店。 一次ソースを読む
18. OWASP財団。 AI エージェント セキュリティのチートシート。 一次ソースを読む
19. OWASP財団。エージェント AI の脅威と軽減。 一次ソースを読む
20. OWASP財団。 Agentic AI セキュリティ検証標準。 一次ソースを読む
21. ミトレ。 AI システムの ATLAS Adversarial Threat Landscape。 一次ソースを読む
22. ミトレ。安全な AI フレームワーク。 一次ソースを読む
23. 欧州連合。規制 EU 2024 1689 人工知能法第 14 条。 一次ソースを読む
24. 欧州委員会。 AI 法律の規制枠組みと実装。 一次ソースを読む
25. 英国情報コミッショナー局。 AI とデータ保護に関するガイダンス。 一次ソースを読む
26. 欧州データ保護委員会。自動化された意思決定とプロファイリングのガイダンス。 一次ソースを読む
27. 国際標準化機構。 ISO IEC 42001 人工知能管理システム。 一次ソースを読む
28. 国際標準化機構。 ISO IEC 23894 人工知能リスク管理。 一次ソースを読む
29. 国際標準化機構。 ISO IEC 27001 情報セキュリティ管理システム。 一次ソースを読む
30. 国際標準化機構。 ISO IEC 27005 情報セキュリティリスク管理。 一次ソースを読む
31. OECD。 OECD AI 原則。 一次ソースを読む
32. OECD。 AI システムの分類のためのフレームワーク。 一次ソースを読む
33. 世界知的所有権機関。人工知能と知的財産。 一次ソースを読む
34. 米国連邦取引委員会。 AI の主張を抑制してください。 一次ソースを読む
35. 米国証券取引委員会。人工知能と投資詐欺の投資家への警告。 一次ソースを読む
36. オープンAI。エージェント SDK トレース。 一次ソースを読む
37. オープンAI。エージェントのワークフローを評価します。 一次ソースを読む
38. オープンAI。エージェントのトレースグレーディング。 一次ソースを読む
39. 人間的。責任あるスケーリングポリシー。 一次ソースを読む
40. グーグルクラウド。エージェント AI システムのデザイン パターン。 一次ソースを読む
41. マイクロソフト。エージェント AI アーキテクチャと責任のある AI。 一次ソースを読む
42. Linux財団。エージェントティック AI ファンデーション。 一次ソースを読む
43. クラウドセキュリティアライアンス。 AI マトリックスを制御します。 一次ソースを読む
44. インターネット セキュリティ センター。 CIS の重要なセキュリティ管理。 一次ソースを読む
45. インターネット エンジニアリング タスク フォース。 OAuth 2.0 セキュリティの現在のベスト プラクティス。 一次ソースを読む
46. インターネット エンジニアリング タスク フォース。 JSON Web トークンの現在のベスト プラクティス。 一次ソースを読む
47. OpenID財団。金融グレード API セキュリティ プロファイル。 一次ソースを読む
48. 米国国立標準技術研究所。バック・トゥ・ザ・フューチャー Agentic AI に強力なアイデンティティ基盤が必要な理由。 2026年8月27日。 一次ソースを読む
49. モデルの評価と脅威の研究。タスク完了時間のホライゾン オブ フロンティア AI モデル。 一次ソースを読む
50. MLコモンズ。 AI 安全性ベンチマーク。 一次ソースを読む