ERPセキュリティ、AIエージェントへの対応で苦戦

BankInfoSecurityは、AIエージェントが業務上の権限を得るにつれ、ERPセキュリティ統制が追随できていないという不都合な対立をGoogle News上で浮き彫りにした。

問題は、アシスタントが請求書を要約できるか、あるいは調達に関する質問へ回答できるかではない。エージェントがレコードを取得し、ツールを呼び出し、取引を変更し、複数のエンタープライズシステムをまたいでアクションを調整できるようになったとき、リスクが始まる。

SAP、Oracle、Microsoft、Workdayは、ERPソフトウェアをそのようなモデルへ移行させつつある。これらのエージェントは、財務、調達、人事、サプライチェーンにまたがる反復作業の削減を約束する。しかし、エージェントを取り巻く統制は依然として、人間の従業員と予測可能なアプリケーションを前提に設計された考え方を受け継いでいる。

この不整合こそが、中心的なセキュリティ問題を生む。従来のERPガバナンスでは、どの人物がどのロールを持ち、そのロールでどの取引が許可されるかを問う。エージェント型システムでは、委任された目的、変化するコンテキスト、ツール選択、マシン間の引き継ぎが導入される。

エージェントは有効な認証情報を持ちながらも、安全でないアクションを実行し得る。また、個別には許可された複数のステップを組み合わせ、管理者が意図しなかった結果を生み出すこともある。

ERPベンダーは、アイデンティティ統制、承認ゲート、監査機能を追加している。これらの対策は重要だが、エージェントの自律性と決定論的なエンタープライズ統制の間にある、より根深い対立を解消するものではない。

Google Newsの警告が焦点を当てるのは、チャットボットではなく権限

重要な変化は、ERP AIエージェントがビジネスデータを読む段階から、それに基づき行動する段階へ移行していることだ。

Google Newsを通じて取り上げられたERPセキュリティ報告は、拡大するエージェント能力と、それより遅いセキュリティ適応との競争としてこの問題を位置付けている。

この捉え方が重要なのは、ERPシステムが企業の業務上の真実を保持しているためだ。そこには支払指示、従業員記録、サプライヤー契約条件、在庫状況、顧客残高、財務承認が保存されている。

従来型のチャットボットは誤った回答を生成するかもしれない。一方、実行権限を持つERPエージェントは、誤答を仕訳の計上やサプライヤー変更の承認へと変えてしまう可能性がある。

エージェント型AIとは、目標を解釈し、計画を作成し、ツールを選び、限定的な監督の下で複数のステップを実行できるソフトウェアを指す。あらかじめ定義された経路に従う固定型自動化とは異なる。

従来のワークフローでは、発注書がない請求書を常に却下する場合がある。エージェントは差異を調査し、関連するやり取りを取得し、納品記録を比較し、例外処理を提案できる。

現実の業務プロセスには曖昧さが含まれるため、この柔軟性は価値を生む。同時に、多くの既存セキュリティ統制が依存する予測可能性を弱める。

セキュリティチームは、固定されたワークフローを導入前に検証できる。どのフィールドを読み、どのシステム呼び出しを行い、どの条件で承認を起動するかを把握できる。

エージェントは、そのたびに異なる順序を選ぶ可能性がある。プロンプト、利用可能なツール、取得文書、モデルのバージョン、周囲の会話によって挙動が変わり得る。

つまり、認可はログイン時点で終わってはならない。セキュリティは、エージェントのアイデンティティ、委任された目的、現在のコンテキスト、選択したツール、要求されたデータ、意図された影響を評価する必要がある。

エージェントがアプリケーションの境界を越えると、問題はさらに難しくなる。財務エージェントは、1つのタスクを完了するまでに、メール、調達記録、顧客データ、決済システムを参照する可能性がある。

接続が増えるたびに、攻撃対象領域は拡大する。また、複数のコンポーネントが危険な結果に関与した場合、責任の所在も特定しにくくなる。

Google Newsの読者は当初、この話を生成AIの精度に関する新たな警告と受け取るかもしれない。しかし、その根底にある問題はより重大だ。

ERPセキュリティチームは、受動的なアプリケーションというより、高度に接続された従業員のように振る舞うソフトウェアを統制しなければならない。その従業員は継続的に、機械の速度で、組織の境界を越えて稼働できる。

この変化は、最高情報セキュリティ責任者、ERP管理者、アイデンティティチーム、内部監査人、業務プロセスの責任者に負荷をかける。これらのどの部門も、単独でリスクを管理することはできない。

セキュリティチームはアクセス制御を理解しているが、詳細な業務プロセスの文脈を欠く場合がある。財務部門の責任者は重大な影響を理解しているが、すべての技術的依存関係を把握しているとは限らない。

ERP管理者はロールと取引を理解している。一方で、外部モデル、エージェントフレームワーク、ワークフローに接続されたサードパーティーツールを管理していない可能性がある。

したがって、当面の課題は技術面だけでなく組織面にもある。企業には、最初の指示からその後に生じるあらゆるアクションまで、エージェントを追跡する単一の統制モデルが必要だ。

ERP AIエージェントは人間中心のアイデンティティモデルを崩す

ソフトウェアが目標を再解釈し、自ら実行経路を選択できる場合、有効なアイデンティティだけではアクションの適切性を証明できない。

ERP統制は従来、記名ユーザー、割り当てられたロール、職務分掌を中心としてきた。職務分掌は、1人の人物が機密性の高いプロセスの相反する段階を支配することを防ぐ。

たとえば、サプライヤーを登録する従業員が、そのサプライヤーへの支払いを単独で承認すべきではない。このルールは不正を抑制し、認証情報が侵害された場合の影響を軽減する。

エージェントは、権限が複数の層を通じて移るため、このモデルを複雑にする。人がエージェントに指示し、そのエージェントが別のエージェントを呼び出し、さらにそのエージェントが業務アプリケーションを起動する。

最終的なシステムが認識するのは、認証済みのサービスアイデンティティだけかもしれない。元のユーザー、目的、根拠、リクエストに付随する制約を受け取れない可能性がある。

これにより、委任チェーンの問題が生じる。各システムは直接の呼び出し元を認識する一方、アクションの完全な出所と意図は再構築しにくくなる。

共有されたエージェント認証情報は、この問題を悪化させる。複数のワークフローが1つのサービスアカウントを利用する場合、調査担当者は正当な自動化と不正利用を区別するのに苦労する可能性がある。

永続的な認証情報は、権限が本来の目的を超えて残ることも許す。一時的な照合プロジェクトのために作られたエージェントが、その作業終了後もアクセス権を保持するかもしれない。

人間のアクセスレビューは通常、雇用上のイベントと固定ロールを基準に実施される。エージェントは従業員よりはるかに速く出現し、変化し、複製され、消滅し得る。

また、正式な開発プロセスの外で組み立てられることもある。ある事業チームが、モデルと承認済みツールを接続する際、その組み合わせが新たな特権アイデンティティを生むことを認識していない可能性がある。

OWASPのエージェント型セキュリティフレームワークは、アイデンティティと権限の悪用を中心的なリスクの1つとして挙げている。また、目標の乗っ取り、ツールの不正利用、エージェント型サプライチェーンの脆弱性も指摘している。

目標の乗っ取りは、悪意ある、または信頼できないコンテンツが、エージェントの達成目標を変えるときに起こる。有害な指示は、文書、メッセージ、ウェブページ、ツール応答の中に含まれている場合がある。

これは、単独で動作するアシスタントよりもERPの内部では危険性が高い。エージェントはすでに機密記録や取引機能へのアクセスを持っている可能性がある。

サプライヤーのメールを読む調達エージェントを考えてみよう。侵害されたメッセージは、攻撃者が管理する銀行口座を優先するようモデルに指示したり、社内の購買データを開示させたりする可能性がある。

その要求はユーザーの当初の目的と矛盾するかもしれない。それでも、データと指示を分離する保護策がなければ、エージェントは埋め込まれたテキストを関連する業務コンテキストとして扱う可能性がある。

最小権限の原則は依然として必要だが、その実装はより精緻でなければならない。エージェントに与えるべき権限は、1つの目的と限られた期間に必要なものだけだ。

Oracleの安全な運用に関するガイダンスは、この区別を明確にしている。分析エージェントは、同じワークフローに参加しているからといって調達承認権限を必要とするわけではない。

この原則はなじみ深く聞こえるが、エージェントによって実施は難しくなる。タスク開始後に計画が変化することがあり、実行中に追加のツールを要求する可能性もある。

静的なロールでは、目的、取引額、データの機密性、信頼度、別のエージェントがリクエストを開始したかどうかといった条件を十分に表現できない。

そのため企業には、アクションの時点でポリシーチェックを行う仕組みが必要になる。そのチェックでは、要求された操作と、それを取り巻くコンテキストの両方を評価すべきだ。

影響の大きいアクションには、人間の意図をより強く証明することも求められる。同じエージェントが生成した洗練された要約だけをレビュー担当者が見る場合、確認ボタンでは不十分だ。

レビュー担当者には、元の根拠、提案された変更、ポリシー例外、予想される業務上の影響が必要である。そうでなければ、人間による監督は形式的なものになってしまう。

真のトレードオフは自律性と統制の間にある

エージェントの自律性が高まるほど、アイデンティティ、ポリシー適用、可観測性、復旧に求められる負担も増す。

ERP AIエージェントは、例外を処理できるときに有用になる。しかし、決定論的な統制が最も適用しにくいのも、まさに例外の場面だ。

固定型自動化は、開発者が事前に定義した経路をたどる。エージェントは不完全な情報を解釈し、どの経路が適切かを判断する。

この違いはセキュリティ上のトレードオフを生む。エージェントを過度に制限すれば、既存ワークフローの高価なインターフェースにとどまる。より広い権限を与えれば、エラーが業務上の結果をもたらす。

エージェントがベンダーのクラウド内にとどまっていても、この対立は消えない。統制された環境は露出を減らせるが、アクションが許容されるかどうかは依然として業務ロジックによって決まる。

エージェントにはサプライヤー記録を更新する権限があるかもしれない。しかし、その権限がすべてのサプライヤー更新に正当な目的があることを意味するわけではない。

エージェントは、低リスクに見える能力を組み合わせて高リスクな連続操作を作り出すこともある。請求書の読み取り、サプライヤーの登録、支払い準備は、個別に評価すれば管理可能に見える。

しかし、これらを組み合わせると、不正の経路全体を再現できてしまう。これは、見かけ上は安全なコンポーネントが危険な複合結果を生む「構成上のリスク」と呼ばれることがある。

セキュリティツールは、個々のAPI呼び出しを検査することが多い。各ステップを承認しても、それらを結ぶより広範な計画を見逃す可能性がある。

エージェントメモリも新たな難しさを生む。メモリにより、ソフトウェアはタスクのコンテキスト、設定、過去の観察を複数の対話にまたがって保持できる。

この継続性は性能を向上させる可能性がある。一方で、悪意ある指示、機密データ、誤った前提を、それらがシステムに入ったセッション以降も保持してしまう可能性がある。

検索拡張生成、すなわちRAGは、モデルが回答またはアクションを実行する際に、選択されたエンタープライズ情報を与える仕組みだ。そのセキュリティは、取得される情報の出所、権限、品質、鮮度に依存する。

汚染された知識ソースは、基盤となるモデルを直接侵害せずとも、その後の意思決定を歪める可能性がある。古いポリシー文書も、通常の運用上の失敗を通じて同様の結果をもたらし得る。

このため、情報ガバナンスはAIエージェントのセキュリティの一部となる。チームは、エージェントがどの情報源を利用するのか、誰がそれらを変更できるのか、取得された根拠が意思決定にどう影響するのかを把握しなければならない。

社内ワークフローを構築する従業員にも、信頼できるドキュメントが必要です。検索可能なナレッジベースは、チームがエージェント導入に関する設計判断、脅威モデル、承認要件を維持する助けになります。

ドキュメントは技術的な統制の代わりにはなりません。しかし、エージェントの担当者が変わったり、パイロット運用から本番環境へ移行したりする際に、重要な前提が失われる可能性を下げることはできます。

ツールへのアクセスは、別のリスクも生み出します。ツールは、データベースへの照会、メッセージの送信、業務レコードの変更といったモデル出力を、実際の行動へと変換します。

接続されたツールがすでに認証情報を保持していれば、モデル自身がデータベースの認証情報を直接持つ必要はありません。したがって、そのツールはエージェントの実効的な権限境界の一部となります。

セキュリティレビューでは、ツールのスキーマ、入力検証、認証情報の保管、出力フィルタリング、障害時の挙動を検証しなければなりません。モデルだけをレビューしても、実行経路の大部分を見落とします。

マルチエージェントシステムでは、不確実性がさらに高まります。あるエージェントが調査を委任し、別のエージェントがポリシーを解釈し、第三のエージェントが取引を実行する場合があります。

引き継ぎのたびに、文脈が失われたり、信頼できない出力が混入したりする可能性があります。また、被害につながる判断をどのコンポーネントが下したのかも不明瞭になり得ます。

SAPが公開したセキュリティアーキテクチャでは、エージェントのリクエストを、ID検証、AI処理、業務実行、フォレンジックログまで追跡しています。

このエンドツーエンドの視点は正しい方向性です。しかし、アーキテクチャ図があるからといって、すべての顧客環境で統制が一貫して適用されていることにはなりません。

ERP環境には、カスタムコード、レガシー統合、買収したシステム、外部パートナー、長期化した例外が存在します。こうした違いは、ベンダーのデフォルトのセキュリティモデルを弱める可能性があります。

最も難しい導入は、ハイブリッド環境で生じるでしょう。エージェントは最新のクラウドサービスで開始しても、粗い権限設定と限定的なテレメトリーしかない古いアプリケーションを介して動作する場合があります。

こうした環境では、最新のコンポーネントがチェーン内で最も弱い統制を引き継ぐことがあります。するとエージェントの自律性は、組織がすでに管理に苦慮してきた技術的負債を増幅させます。

監査ログではすべてのエージェント判断を説明できない

ERPセキュリティには、ユーザーの意図をエージェントの推論、ツール呼び出し、データ変更、業務上の結果へ結び付ける証拠が必要です。

従来の監査ログは、よく知られた問いに答えます。どのアカウントがシステムにアクセスしたか、いつ取引が発生したか、どのフィールドが変更されたかを示します。

エージェント型ワークフローには、より長い証拠の連鎖が求められます。調査担当者には、開始ユーザー、委任された目的、モデルのバージョン、取得したコンテキスト、ポリシー判断、ツール呼び出し、最終結果が必要です。

エージェントが実行を拒否した内容を知る必要もあるかもしれません。拒否されたリクエストが繰り返されれば、探索行為、設定不備、侵害された情報源が明らかになる可能性があります。

すべてのプロンプトと応答を記録することは、簡単な解決策ではありません。プロンプトには、給与記録、契約書、個人データ、認証情報、その他の制限情報が含まれる可能性があります。

そのため、完全なログは別の機密リポジトリを生み出しかねません。保存期間、アクセス、暗号化、マスキングのルールは、基礎となる業務データに合わせる必要があります。

モデルの推論には、さらに複雑な問題があります。生成された説明はもっともらしく聞こえても、システムがその出力に至った実際の過程を正確に表しているとは限りません。

セキュリティチームは、説明文を証拠として扱うべきではありません。必要なのは、入力、ツール要求、ポリシー評価、結果として生じた状態変更に関する検証可能な記録です。

これにより、可観測性の意味が変わります。監視は、単にモデルの可用性やAPIエラーを追うのではなく、ワークフロー全体にわたる挙動を捉えなければなりません。

有用なシグナルには、想定外のツール選択、異常な取引量、通常の業務範囲外のアクセス、ポリシー拒否の繰り返し、機密レコードの変更が含まれます。

ベースラインも、エージェントに割り当てられた目的を反映する必要があります。給与照合エージェントと調達エージェントが、同じ通常時の行動プロファイルを共有すべきではありません。

レート制限は、ミスの影響範囲を抑えることができます。しかし、少数の高額なアクションが正当なものかどうかまでは判断できません。

取引のしきい値は、もう一つの層を提供します。それでも攻撃者は活動を小さなアクションに分割したり、低額の変更一つが後の損失を可能にするプロセスを悪用したりするかもしれません。

企業には複数の地点で統制が必要です。エージェントのランタイムはツールを制限し、IDレイヤーは権限を制限し、ERPは業務ルールを検証すべきです。

その後、独立した監視によって実際に何が起きたかを検証する必要があります。同じエージェントに実行、評価、自身の行動の報告を任せれば、信頼が過度に集中します。

取り消し不能、または重要性の高いアクションに対しては、人間による承認が依然として有効です。しかし、レビュアーには操作を見抜くための十分な時間と文脈が必要です。

承認疲れは、安全策を形式的な手続きへ変えてしまう可能性があります。機械の速度で動作するエージェントは、従業員が慎重に評価できる以上のレビュー依頼を生成し得ます。

リスク階層に応じた自律性は、より実行可能なモデルを提示します。影響が小さく可逆的なタスクは自動で進められる一方、機密性の高いアクションには独立した検証を要求します。

低リスクの作業には、説明文の作成、証拠の収集、異常のフラグ付けが含まれます。高リスクの作業には、支払情報の変更、資金の支出、アクセス権の変更が含まれます。

可逆性は統制レベルに影響すべきです。誤ったレポートは修正できますが、外部への支払いやレコードの削除は、長期的な損害を生む可能性があります。

NISTのリスクプロファイルは、AIリスクへの取り組みをガバナンス、マッピング、測定、管理を軸に整理しています。このライフサイクル型のアプローチは、一度きりの承認よりもERPエージェントに適しています。

エージェントのリスクは、ツール、モデル、データソース、権限、業務目的が変わると変化します。変更のたびに、再評価と対象を絞ったテストを実施すべきです。

テストには、敵対的な入力と現実的な業務上の例外を含めなければなりません。クリーンなデータを中心にしたデモでは、矛盾する指示の下でエージェントがどう動作するかは分かりません。

チームは部分的な障害もテストすべきです。エージェントが一つのステップを完了した後、次のステップを記録する前に、下流システムがタイムアウトする場合があります。

繰り返し実行しても重複した影響を生じさせない冪等性がなければ、復旧時にエージェントが同じ取引を再送信する可能性があります。

こうした通常の信頼性問題は、財務記録、アクセス権、規制対象データに影響する場合、セキュリティ問題になります。エージェントの安全性をシステムエンジニアリングと切り離したままにはできません。

ベンダーのガードレールとカスタマイズされたERPの現実

SAPやOracleは自社のエージェントプラットフォームを保護できますが、実務上のリスクを左右する統合、ロール、データ、例外は依然として顧客が管理しています。

ERPベンダーには構造的な優位性があります。自社のアプリケーションモデルを理解しており、既存のID、ワークフロー、監査サービスのそばにエージェントを組み込めるためです。

ネイティブエージェントは、外部モデルにはない業務メタデータを継承できます。また、画面を通じてユーザー操作を模倣するのではなく、承認済みのインターフェースを利用できます。

Oracleは、顧客に対し、エージェントの責任を分離し、連携するエージェント全体で最小権限を適用するよう助言しています。SAPは、IDチェック、テナント分離、出力検証、フォレンジック監査証跡について説明しています。

これらの統制は実際の懸念に対処します。また、組み込み型エージェントは、緩く接続されたサードパーティの自動化より安全だというベンダーの主張も支えます。

ただし、この主張には限界があります。大半の大企業は、標準設定のみで構成された単一のクリーンなERP環境を運用しているわけではありません。

複数のシステムにまたがって、カスタマイズされたプロセスを運用しています。一部のアプリケーションはオンプレミスに残り、他はパブリッククラウドやベンダー管理サービス上にあります。

パートナー、契約社員、銀行、物流事業者、買収した事業部門が、同じプロセスに接続することもあります。境界ごとに異なるIDモデルと統制モデルが導入されます。

ネイティブの財務エージェントであっても、メールから信頼できないコンテンツを受け取る可能性があります。サードパーティの文書パーサーに依存したり、結果を古い決済アプリケーションへ送ったりする場合もあります。

ワークフロー全体の信頼性は、これらの依存関係と同じ水準にとどまります。ベンダーのセキュリティ文書では、顧客によるすべての拡張を網羅できません。

外部エージェントには別のトレードオフがあります。競合するERP、CRM、コミュニケーション、分析プラットフォームをまたいで作業を調整できます。

この独立性は、ベンダーロックインを減らし、より広いワークフローを支援できます。一方で、ユーザーと業務レコードの間に、別のID、オーケストレーション層、ツールエコシステムを置くことにもなります。

したがって実務上の選択は、安全なネイティブソフトウェアと安全でない外部ソフトウェアの二択ではありません。どちらのアプローチにもリスクがありますが、そのリスクが集中する場所は異なります。

ネイティブエージェントは、ERPベンダーのプラットフォーム、クラウド、ガバナンスモデルに信頼を集中させます。外部エージェントは、コネクター、認証情報、モデル、オーケストレーションツールに信頼を分散させます。

セキュリティチームは、分類ラベルを受け入れるのではなく、完全なアクション経路を評価すべきです。ネイティブ製品も、広すぎる設定によって安全でなくなる可能性があります。

外部製品も、限定された短期間の権限のみを与えられ、機密性の高い取引を直接完了できなければ、リスクを下げられる可能性があります。

調達レビューは、こうした違いを反映しなければなりません。標準的なソフトウェア質問票では、委任の深さ、メモリーの挙動、プロンプト処理、ツールレベルの権限を十分に捉えられないことがほとんどです。

購入者は、ERPログにどのIDが表示されるか、そしてそれが元のユーザーを識別するかを尋ねるべきです。また、エージェント間の引き継ぎにわたって、ポリシーがタスクにどのように追従するかも確認すべきです。

ほかにも重要な問いには、モデル更新、保持されるコンテキスト、データレジデンシー、インシデント対応、詳細なテレメトリーへの顧客アクセスが関わります。

ベンダーは、管理者がエージェントを即時停止する方法を説明すべきです。この統制は、単にインターフェースを隠すのではなく、有効な認証情報を無効化し、保留中のアクションを中断する必要があります。

顧客には、変更管理に関する証拠も必要です。モデル、システムプロンプト、ツール定義、検索ソースの変更後に、エージェントの挙動が変化する可能性があります。

従来のアプリケーション更新では通常、決定論的なコードが変更されます。モデル更新では、周辺のワークフローが変わらなくても判断が変化する可能性があります。

したがって、セキュリティテストは導入後も継続しなければなりません。意味のあるコンポーネントが変わるたびに、チームは代表的なタスクと悪用ケースを実行すべきです。

バージョン間で結果を比較し、回帰を調査できる十分な証拠を保存する必要があります。6カ月前に合格したテストは、変更後のエージェントについてほとんど何も示しません。

競争圧力は、この規律を損なう可能性があります。ERPベンダーは顧客にエージェントを導入してほしく、事業部門のリーダーは測定可能な生産性向上を求めています。

IDおよび監視システムの準備が整う前に、セキュリティチームへ広範なパイロットの承認を求める圧力がかかる場合があります。この順序では、ガバナンスが後追いの修復プロジェクトになってしまいます。

より安全な展開は、範囲が限定され、結果を観測できるタスクから始めます。組織がエージェントの挙動を説明、検知、取り消しできるようになって初めて、権限を拡大します。

ERPセキュリティが追いつくかを示す三つのシグナル

次の段階を決めるのは、エージェント固有のID、アクションレベルの強制、実際の本番インシデントから得られる証拠です。

最初のシグナルは、ERPプラットフォームが各エージェントおよび委任されたタスクごとに、固有かつ短期間のIDを採用するかどうかです。共有サービスアカウントは例外となるべきです。

成熟した設計では、元のユーザー、エージェントID、目的、権限をワークフロー全体で維持します。下流アプリケーションは、アクションを許可する前にその文脈を受け取るべきです。

これにより、ERP AIエージェントが既存の説明責任構造の中で動作できるという主張が強まります。広範な認証情報への依存が続けば、その主張は弱まるでしょう。

第二のシグナルは、ベンダーと顧客がトランザクション単位でポリシーを適用しているかどうかだ。ツールの使用許可が、あらゆる出力を許容する権限に変わってはならない。

統制では、トランザクションの種類、価値、送信先、根拠となるソース証跡、取り消し可能性を考慮すべきである。機密性の高い操作には、実行するモデルの外部で行う独立した検証を求める必要がある。

セキュリティチームは、具体的な強制機能を備えた製品リリースに注目すべきだ。責任あるAIをうたうマーケティング文言よりも、設定可能な統制やエクスポート可能なログの方が有用である。

また、こうした統制が接続されたアプリケーション間で機能するかも検証すべきだ。単一ベンダーのインターフェースに限定された保護では、クロスプラットフォームのワークフローをカバーできない。

第三のシグナルは、公開されるインシデント報告の質である。本番環境での障害は、理論上のアーキテクチャが実際のビジネス条件下でどこで破綻するかを明らかにする。

有用な開示では、侵害されたアイデンティティ、操作された入力、影響を受けたツール、不正なアクション、封じ込め手法を特定する。AIエラーへの曖昧な言及では、防御側の助けにはならない。

インシデントでは、人による承認が存在したか、またなぜそれが機能しなかったかも明確にすべきである。その証拠は、監督がリスクを低減するのか、それとも単に責任を移転するだけなのかを示す。

Google Newsの警告を支える中心的な主張は、エージェントの拡大がこの三つの統制を上回る速度で進めば、より強まる。アイデンティティ、強制、証跡が同時に成熟すれば、その主張は弱まる。

組織は、大きな損失が発生するまで自社のエクスポージャーを把握するのを待つべきではない。まず、ERPプロセスに接続されているすべてのエージェントを列挙することから始められる。

そのインベントリには、所有者、目的、モデル、ツール、データソース、認証情報、承認ポイント、停止手順を含めるべきだ。不明な項目は直ちに調査に値する。

次に、チームは指示から最終トランザクションまで、影響の大きいワークフローをいくつか追跡すべきである。支払い変更、アクセス権の付与、仕訳入力、従業員記録の更新は、よい出発点となる。

この作業により、システム間で欠落しているコンテキストが明らかになる。また、単一の認証情報やツールが、業務タスクに必要な範囲を超える権限を持つ箇所も浮き彫りになる。

企業はその後、影響度と取り消し可能性に基づいてアクションを分類すべきだ。読み取り専用の調査に、資金の支出やマスターデータの変更と同じ統制は必要ない。

最後に、セキュリティリーダーは、エージェントが誤った振る舞いをした際に組織がどう対応するかをテストすべきである。封じ込めを伴わない検知では、最も重要な問いが未解決のまま残る。

管理者はエージェントを停止し、その権限を取り消し、証拠を保全し、アクションを取り消し、被害が広がる前に影響を受けたレコードを特定できるだろうか。

ERPセキュリティは、自律性を排除する必要はない。必要なのは、自律性が無制限の権限に決して変わらないようにすることだ。

実務的な次の一歩はシンプルである。稼働中または計画中のエージェントワークフローを一つ選び、それが触れるすべてのアイデンティティ、ツール、データソース、承認を追跡する。チームがその連鎖を説明できないなら、そのエージェントにより広範なアクセスを与える準備はできていない。

誰がそれを停止できるのか、どの証拠が残るのか、どのアクションを取り消せるのかを問うべきだ。その答えは、もう一つの洗練されたデモンストレーションよりも重要である。

Google Newsはこの警告を浮き彫りにした。今、企業チームは、自社のERP統制が人と同じほど慎重にエージェントを管理しているかどうかを判断する必要がある。