AIエージェントによる内部脅威が、信頼されたアクセスをセキュリティの中心に据える

AIエージェントは重要な境界を越えた。今では、常時の監督なしに信頼された認証情報を使い、データを読み取り、ツールを呼び出し、企業システムを変更できる。

この変化により、AIエージェントによる内部脅威はモデル安全性の問題からアクセス制御の問題へと変わる。エージェントが記録を漏えいさせたり、未承認のメッセージを送信したり、安全でないワークフローを実行したりするのに、悪意は必要ない。正当な権限、有害な指示、そして行動に移せるだけの自律性があればよい。

Cybersecurity Insidersによる最近の主張は、この逆転を端的に捉えている。企業はかつて、AIを外部攻撃者から守るべきソフトウェアとして扱っていた。今やセキュリティチームは、そのソフトウェア自体が信頼されながらも安全ではないオペレーターになり得るかを考慮しなければならない。

これは、すべてのエージェントを敵対的な存在に分類すべきだという意味ではない。認証済みであることを、行動の安全性の証明として扱うことはもはやできない、という意味である。有効なアイデンティティが答えるのは、誰が、あるいは何がアクセスを要求したかだ。それだけでは、要求された行為がユーザーの真の意図に沿っているかは示せない。

したがって、浮上している対立は人間対機械ではない。広範で継続的なアクセスと、限定的でタスク固有の認可との対立である。セキュリティチームは、従業員や従来型アプリケーション向けに設計された寛容なアクセスパターンを、エージェントにも継承させるかを判断しなければならない。

その答えによって、エージェント導入が制御された自動化をもたらすのか、それとも検知が困難な新しい種類の内部インシデントを生むのかが決まる。

AIエージェントによる内部脅威は、正当なアクセスから始まる

決定的なリスクは、AIエージェントが境界を突破することではなく、企業が意図して付与したアクセスを通じて行動することにある。

従来の内部リスク対策は、従業員、契約社員、侵害されたアカウントに焦点を当てている。これらの主体はすでに信頼境界の内側にいる。外部公開された脆弱性を悪用せずとも、データやシステムを不正利用できる。

エージェントは、このモデルに驚くほどよく当てはまる。OAuth許可、サービスアイデンティティ、APIアクセス、データベース権限、委任された権限を保有できる。また、複数ステップのワークフローにまたがって、これらの権限を組み合わせることもできる。

営業向けブリーフィングの作成を任されたエージェントは、顧客記録を検索し、社内メモを取得し、メールの下書きを作成するかもしれない。コーディングエージェントは、リポジトリを読み取り、ターミナルを開き、ファイルを変更し、プルリクエストを送信する可能性がある。サポートエージェントは、アカウント情報を照会し、返金を開始するかもしれない。

個々の権限はどれも妥当に見える可能性がある。危険な能力は、エージェントがそれらを想定外の順序でつなげたときに生まれる。

これは、エージェントと従来型アプリケーションの根本的な違いである。従来のソフトウェアは通常、あらかじめ決められた経路に従う。エージェントは目標を解釈し、ツールを選択し、中間ステップを実行時に決定する。

その柔軟性は価値を生む一方、旧来の統制に組み込まれた前提を弱める。ある意図されたワークフローのために与えられた権限が、複数の意図しないワークフローを支え得る。エージェントは人間のオペレーターより速く、そうした経路を見つけられる。

プロンプトインジェクションは、この問題をさらに深刻にする。プロンプトインジェクションとは、AIシステムが読むデータ内に欺瞞的な指示を埋め込む攻撃である。エージェントは、その指示を割り当てられたタスクの一部と誤認する可能性がある。

外部フォルダ内の文書を確認するアシスタントを想像してほしい。文書には、機密ファイルを取得してその内容を別の場所に送るようアシスタントへ指示する隠しテキストが含まれている。どちらの行為も承認済みのツールを使うため、エージェントは従ってしまうかもしれない。

システムには、ログイン成功、有効なトークン、許可されたAPI呼び出しが記録される可能性がある。従来型の監視では、認可済みの活動に見える。しかし、事業側から見ればデータ漏えいである。

OWASPのエージェント型脅威に関するガイダンスは、自律的な計画、ツール利用、メモリ、エージェント間の相互作用から生じるリスクを特定している。これらは孤立したモデルの振る舞いではない。モデルと権限を組み合わせることで生まれる、システムレベルのリスクである。

同じ問題は、エージェントが仕様の曖昧な目標を受け取った場合にも現れる。「期限超過の依頼をすべて解決する」という指示は、メッセージ送信、記録の変更、人間のレビューが必要なケースのクローズにつながる可能性がある。最初にモデルが侵害される必要すらない。

だからこそ、意図はアイデンティティと同じくらい重要である。安全な設計では、誰がタスクを認可したのか、どのリソースが対象なのか、どの行為が許可されるのか、そしてその権限がいつまで有効なのかを判断しなければならない。

こうした境界がなければ、認証済みのエージェントは、異例なほど速いペースで活動する内部者となる。

信頼されたアクセスが新たなセキュリティ境界になりつつある

AIエージェントにとっては、正当な業務がすでにアプリケーション、クラウド、データストアをまたぐため、ネットワーク上の場所よりも信頼されたアクセスが重要になる。

ゼロトラストアーキテクチャは、この変化の一部を先取りしていた。NISTのゼロトラスト標準は、ネットワーク上の場所や資産所有だけに基づく暗黙の信頼を退ける。ユーザー、資産、リソース、明示的な認可を中心にセキュリティ判断を置く。

アクセスを要求する主体が自律システムである場合、このモデルの緊急性はさらに高まる。エージェントは、かつて人間の内部者を減速させていた境界を越えて行動できる。デバイスを切り替えたり、複数のインターフェースを開いたり、アプリケーション間で手作業によりデータをコピーしたりする必要はない。

1つの指示が、連鎖的なツール呼び出しを引き起こし得る。その連鎖は、メッセージングプラットフォームからクラウドストレージへ、さらに顧客データベースや外部サービスへと移るかもしれない。エージェントは信頼された統合を通じて、その一連の処理を実行する。

ネットワークファイアウォールには許可された接続が見える。アイデンティティシステムには認識済みの認証情報が見える。アプリケーションログには、割り当てられたアカウントが実行を許可されていた操作が記録される。

それでも、その組み合わせによる結果はポリシーに違反し得る。

したがってセキュリティは、各行為により近づく必要がある。認可では、エージェントのアイデンティティ、所有者、現在のタスク、要求されたリソース、使用中のツール、周辺のリスクシグナルを考慮すべきである。

そのためには、展開されたエージェントごとに固有のアイデンティティが必要になる。共有サービスアカウントは、複数のエージェントが同じ名前で活動を記録できるため、調査を難しくする。また、新しいワークフローが同じアカウントを再利用するにつれ、権限の蓄積も許してしまう。

専用のアイデンティティは、所有関係の追跡を可能にする。セキュリティチームは、エージェントをそのスポンサー、目的、許可されたツール、デプロイ環境、レビュー計画に結び付けられる。無関係な自動化を停止せずに、1つのワークフローだけを停止できる。

ただし、アイデンティティだけでは十分ではない。一意に識別されたエージェントであっても、過剰な権限を持つことがある。また、有効な権限を誤ったタイミングや誤った目標のために使うこともある。

有効な統制は、権限範囲と権限期間の両方を縮小しなければならない。四半期レポートを作成するエージェントは、参照したすべての情報源への恒久的なアクセスを保持すべきではない。現在のタスクに限定された権限を受け取るべきである。

短命な認証情報は、不正利用に使える時間を短縮する。ジャストインタイムアクセスは、タスク開始時に権限を付与し、その後に取り消す。ツールレベルのポリシーは、エージェントが呼び出せる操作を制約する。

これらの統制は、AIエージェントによる内部脅威が示す中心的な教訓を反映している。信頼はエージェントに永続的に付与されるものではなく、特定の条件下における特定の行為に結び付けられるべきである。

企業は、読み取りと実行も分離する必要がある。カレンダーを要約するエージェントに必要な権限は、会議を予定に入れるエージェントの権限とは異なる。コード変更を提案するシステムに、デプロイ権限を自動的に与えるべきではない。

急速な導入の過程では、この区別が消えてしまう可能性がある。チームは読み取り専用のアシスタントから始め、次第に書き込みアクセス、ブラウザ操作、ワークフロー自動化を追加する。当初のリスク評価は、もはや実際に展開されたシステムと一致しなくなる。

したがって、エージェントのインベントリは導入状況だけでなく、能力を追跡しなければならない。セキュリティチームは、どのエージェントが機密データにアクセスできるのか、外部ツールを呼び出せるのか、公開の場で通信できるのか、記録を変更できるのか、取引を認可できるのかを把握する必要がある。

インベントリは、エージェントと同じ速さで更新されなければならない。

既存の内部者対策がエージェントの振る舞いを見逃す理由

人間の速度や動機を前提に設計された統制は、ソフトウェアが疲労もためらいもなく何百もの正当な行為を実行できる状況では十分に機能しない。

人間の内部リスク対策では、しばしば認識しやすい行動変化を探す。従業員が通常と異なる量のデータをダウンロードする、想定外の時間にログインする、通常の職務範囲外の部門へアクセスするといった兆候である。

こうしたシグナルは引き続き有用だが、エージェントは異なるベースラインを生む。継続的に稼働できる。人より多くの記録を処理できる。その活動は従業員のエンドポイントではなく、安定したクラウドインフラから発生する場合がある。

高い行動頻度は、悪意ではなく通常の自動化を示しているかもしれない。低い行動頻度であっても、慎重に標的を絞った情報開示を隠している可能性がある。量だけでは信頼できるシグナルにならない。

意図の推定も難しくなる。人間のユーザーは通常、対話型セッションを通じて行動する。調査担当者は、その行為を職務上の責任、通信内容、既知の業務プロセスと比較できる。

エージェントは、広範な指示を中間的な判断へと変換する。ユーザーはその判断を一度も目にしない可能性がある。最終的な行為は、元の要求から数ステップ離れていることがある。

ログには、その連鎖を保持する必要がある。調査担当者は、ユーザーの指示、モデルの判断、取得したコンテキスト、ツールの選択、認可結果、最終的な影響を再構築できるべきである。

これは、モデル内部のすべての計算を保存するという意味ではない。重要な外部行為と、それぞれを支えた権限について、監査可能な記録を維持するという意味である。

標準的なアプリケーションログは、多くの場合、断片しか提供しない。あるシステムはトークンを記録する。別のシステムはデータベースクエリを記録する。さらに別のシステムは外部送信メッセージを記録する。共通のタスク識別子がなければ、組織はそれらを1つのエージェントワークフローとして結び付けられない。

可観測性の問題は、マルチエージェントシステムでさらに大きくなる。あるエージェントが別のエージェントに調査を委任し、そのエージェントがさらに第3のシステムにツール実行を依頼することがある。元のユーザーが各参加者を承認していなくても、権限は連鎖を通じて移動し得る。

再帰的信頼は、この拡大する関係を表す。組織は1つのエージェントを信頼し、そのエージェントは別のサービスを信頼し、そのサービスはさらに別のアイデンティティやツールに依存する。実質的な攻撃対象領域は、あらゆる接続先へと広がる。

AIエージェントによる内部脅威は、明白な侵入イベントを発生させることなく、この連鎖を悪用できる。侵害されたツール応答が計画エージェントに影響を与える可能性がある。汚染されたメモリエントリが将来の判断に影響する可能性がある。外部文書が信頼されたワークフローを別の方向へ導くこともある。

既存のエンドポイントおよびネットワーク防御も、依然として重要である。マルウェアを遮断し、不審な宛先を検知し、侵害されたインフラを隔離できる。しかし、認可済みの業務行為がユーザーの意図した結果を反映しているかを、確実に判断することはできない。

その判断には、より豊かなコンテキストが必要である。

組織は、エージェントの役割ごとに行動ベースラインを確立すべきである。レポーティングエージェントは通常、承認済みのデータソースを読み取り、特定の文書ストアに書き込むものかもしれない。メール送信や認証情報へのアクセスを試みれば、そのプロファイルの範囲外となる。

ポリシーでは、処理順序に関する制約も強制できる。信頼できないウェブページを読んだからといって、直ちに機密記録へのアクセスを認可すべきではない。データの機密性が変化した場合は、新たな認可判断を行うべきである。

人間による承認は、影響の大きいアクションにおいて依然として有用です。ただし、承認画面には意味のある情報が提示されなければなりません。「続行する」という曖昧な要求では、どのデータが移動するのか、どのレコードが変更されるのかをレビュー担当者は理解できません。

承認画面には、アクションの内容、送信先、影響を受けるリソース、想定される結果を明記すべきです。そうでなければ、人間はセキュリティ統制ではなく、儀礼的なチェックポイントになってしまいます。

最小権限はエージェントではなくタスクに従うべき

最も安全なアクセスモデルは、単一のタスクに必要な最小限の権限だけをエージェントに与え、タスクが変われば新たな判断を求めるものです。

最小権限は長年にわたるセキュリティ原則です。エージェント型システムでは、ワークフローが動的であるため、その実装はより難しくなります。

従来のアプリケーションには、安定した機能セットに対応する権限が付与されます。一方、エージェントは、依頼内容、取得した情報、あるいは前段階の結果に応じて異なるツールを選択する場合があります。

あらゆる可能性を見越して事前にすべての権限を与えれば、開発は簡単になります。しかしそれは、使われていない権限の蓄積も生み出します。操作されたエージェントは、現在のタスクでまったく必要とされない能力を利用できてしまいます。

タスクに紐づく認可は、より良い道筋を提供します。システムは宣言された目標を評価し、必要なリソースに対して制約付きの能力を発行します。その能力は、ステップまたはセッションの終了時に失効します。

Microsoftの最小権限パターンでは、自律性を拡大する前に、アイデンティティ、スコープ、ツールアクセス、監査可能性を定義することが推奨されています。また、責任の所在が明確な所有者を持つ専用エージェントIDも重視されています。

たとえば、経費報告を処理するエージェントを考えてみましょう。必要なのは、提出書類を読み取り、規定と照合し、推奨案を作成することです。支払いを実行する恒久的な権限は必要ありません。

後に、事業上の判断として、定められたしきい値未満の自動払い戻しを認める場合、その書き込み権限は別途分離すべきです。システムは、その権限を認めたポリシーを記録し、境界外の処理ではエスカレーションを要求する必要があります。

この分解により、問題が起きた際の被害を抑えられます。領収書に埋め込まれた悪意ある指示が推奨内容に影響を与える可能性はあります。しかし、それだけで資金の送付先を変更する能力が自動的に与えられるべきではありません。

同じモデルはナレッジワークにも適用できます。調査エージェントはチームで承認された文書を検索できても、出力先は制約されたままであるべきです。機密性の高いソース資料が、公開プロンプト、外部チャネル、無関係なプロジェクトへ流出してはなりません。

アクセス判断にはデータの文脈が必要です。ファイルラベル、プロジェクトの所属、法的保全、顧客に関する制約、機密度によって、同じツール呼び出しが適切かどうかは変わり得ます。

AIナレッジベースを構築する組織は、権限の境界を検索品質の一部として扱うべきです。有用な回答は、所有権や機密性の境界を越えずに、関連情報から導き出されなければなりません。

ツール設計も重要です。広範なツールは、広範な障害モードを生みます。任意のクエリを実行できる汎用データベースコネクタは、承認済みのフィールドを返す目的特化型の関数よりも大きなリスクを伴います。

開発者は、役に立つ範囲で最も狭い操作を公開すべきです。エージェントにメールボックスへの完全なアクセスを与える代わりに、サービスはケースIDに一致するメッセージだけを取得できるようにすることができます。シェルアクセスの代わりに、制御されたビルドコマンドを公開することもできます。

ツールバインディングは、特定のエージェントIDを特定の操作に結び付けます。プラットフォームがツールの存在を認識しているというだけで、エージェントが利用可能なすべての統合を呼び出せるわけではありません。

入力と出力についても、モデルの外部で検証が必要です。モデル自身が提案したアクションがポリシーに違反しているかどうかを、モデルだけに判断させるべきではありません。

独立したポリシーレイヤーは、実行前に送信先、データ分類、取引上限、タスクの文脈を検査できます。そして、操作をブロック、変換、またはエスカレーションできます。

この分離は、エージェントセキュリティに関するよくある誤解に対処します。より優れたプロンプトや強力なモデルはミスを減らせますが、強制可能な境界の代わりにはなりません。

プロンプトは指示です。認可ポリシーは統制です。

この違いは重要です。エージェントはプロンプトを誤解したり、汚染されたコンテキストを引き継いだり、矛盾する指示を受けたりする可能性があります。モデルが予測不能な挙動を示しても、ポリシーエンジンは制限を継続して適用すべきです。

ゼロトラストは役立つが、意図を解決するものではない

ゼロトラストはエージェントの到達範囲を狭められますが、許可されたアクションがユーザーの真の目的に沿うかどうかを自動的に判断することはできません。

これが、信頼されたアクセスをめぐる議論の中心的なトレードオフです。セキュリティベンダーは、アイデンティティ、条件付きアクセス、ゼロトラストをエージェントリスクへの答えとして位置付けることを強めています。これらの統制は重要な弱点に対処します。

MicrosoftのZero Trust for AIは、AIデータ、モデル、ワークロード、ユーザー、エージェントの挙動全体に明示的な検証と最小権限を拡張します。Microsoftは、操作された、過剰な権限を持つ、あるいは目的とずれたエージェントを、潜在的な「二重スパイ」とも表現しています。

この枠組みは有用ですが、組織はゼロトラストを完全な製品カテゴリーとして扱うことには慎重であるべきです。NISTはゼロトラストを、単一のテクノロジー購入ではなく、一連のアーキテクチャ原則として説明しています。

組織は、最新のアイデンティティ統制を導入しながら、エージェントに過剰な権限を残すことができます。認証を要求しながら、あるエージェントタスクと別のタスクを区別できない場合もあります。誰も確認しないログを収集することも可能です。

最も難しいのは、認可されており、かつもっともらしいアクションです。

カスタマーサービスエージェントは、正当に顧客データへアクセスし、メッセージを送信できます。コーディングエージェントは、正当にソースファイルを変更できます。調達エージェントは、正当にベンダーへ連絡できます。

それぞれの悪意ある、または誤ったアクションは、アイデンティティレイヤーではほぼ同一に見えることがあります。

コンテキストに基づく認可は、この差を縮めます。システムは、送信先が承認されているか、要求されたフィールドが必要か、アクションが過去の挙動と一致するか、データ分類が転送を許可しているかを確認できます。

それでも、コンテキストモデルには偽陽性と偽陰性が発生します。厳格な統制は有用なワークフローを中断し得ます。緩い統制は生産性を維持する一方で、有害な組み合わせを許してしまう可能性があります。

組織は、自律性をどこで止めるかを決めなければなりません。影響が小さく、元に戻せるタスクには、より大きな自由を許容できます。影響が大きく、元に戻せないタスクには、より強い検証、そして多くの場合は人間による承認が必要です。

可逆性には特に注意を払うべきです。メッセージの下書きを作るエージェントは、レビュー可能な成果物を生み出します。メッセージを送信するエージェントは、外部世界を変化させます。レコードの削除を推奨するエージェントと、削除を実行するエージェントは異なります。

セキュリティアーキテクチャは、こうした違いを反映すべきです。

チームは、エージェントをモデルとしてだけでなく、システムとしてテストすべきです。モデル評価では、制御された条件下でエージェントが指示に従うかを測定できます。実運用のリスクは、ツール、認証情報、メモリ、データソース、周辺アプリケーションに左右されます。

レッドチーム演習では、悪意ある文書、曖昧な目標、侵害されたツール応答、予期しない権限の組み合わせを導入すべきです。目的は、外部統制が障害を封じ込められるかを観察することです。

OWASPのフレームワークはチームによる脅威の列挙を支援し、NISTのクラウドアクセスモデルは、アイデンティティ層のポリシーと粒度の細かいアプリケーション統制が、分散サービス全体でゼロトラストをどのように支えるかを説明しています。

どちらも、エージェントがビジネス上の意図を理解することを保証するものではありません。この不確実性は、導入判断において可視化されたままでなければなりません。

したがってセキュリティリーダーは、範囲を説明せずにプラットフォームが「エージェントを保護する」と主張する場合、その主張を検証すべきです。エージェントIDを発見できるのか。権限を統制できるのか。ツール呼び出しを検査できるのか。プロンプトとデータを保護できるのか。システム横断の監査証跡を維持できるのか。

多くの製品が対応するのは、ライフサイクルの一部にすぎません。企業には引き続き、ポリシーの所有責任、運用プロセス、インシデント対応、アプリケーション固有の統制が必要です。

AIエージェントによる内部脅威は、単一のパッチで解決できる一つの脆弱性ではありません。確率的な意思決定者を信頼されたワークフローの内部に置くことによって生じる結果です。

信頼されたアクセスが改善しているかを示す3つのシグナル

AIセキュリティの次の段階は、責任あるエージェントに関する広範な約束ではなく、導入可能な統制とインシデントの証拠によって測られることになります。

第1のシグナルは、個別に統制されたエージェントIDの導入です。組織はエージェントを列挙し、所有者を特定し、権限をレビューし、それぞれを個別に無効化できる必要があります。

Microsoft EntraのエージェントIDフレームワークは、主要なアイデンティティプラットフォームが向かう方向を示しています。これは、専用のエージェント構成要素、アクティビティログ、ガバナンス、非人間アクター向けの条件付きアクセスをサポートします。

他のアイデンティティおよびクラウドプロバイダーも、異種環境全体で比較可能な統制を提供するよう圧力を受けるでしょう。企業が単一のエージェントプラットフォームや単一のアイデンティティシステムだけを運用することは、ほとんどありません。

管理者が共有サービスアカウントに頼らず、アプリケーションをまたいで一つのエージェントアクションを追跡できるようになったとき、進展は信頼できるものになります。専用IDが任意、あるいはプラットフォーム固有のままであれば、可視性は断片化したままです。

第2のシグナルは、タスクスコープ付きで短期間の認可がより広く使われることです。エージェントプラットフォームは、ユーザーや開発者から恒久的な権限を継承するのではなく、定義された操作のためにアクセスを要求すべきです。

この変化には、オーケストレーションシステムとアイデンティティインフラのより優れた統合が必要になります。プラットフォームは、ポリシーエンジンが評価できる形式で、エージェントが何を実行しようとしているかを記述しなければなりません。

承認インターフェースも改善が必要です。ユーザーは、機密性の高い権限を付与する前に、リソース、アクション、送信先、想定される影響を確認できるべきです。

ベンダーがこれらの統制をデフォルトとして提供すれば、信頼されたアクセスという主張はより強固になります。安全な設定に大規模なカスタムエンジニアリングが必要であれば、納期のプレッシャーを受けるチームは引き続き広範な権限を選ぶでしょう。

第3のシグナルは、実際のインシデントと独立したテストから得られる公開証拠です。セキュリティチームは、デモの外でエージェントがどのように失敗するかを知る必要があります。

有用な開示では、最初の指示、アクセス経路、関与したツール、失敗した統制、封じ込めに成功した時点が説明されます。安全でない出力への曖昧な言及だけでは、アーキテクチャ上の十分な指針にはなりません。

独立評価では、プロンプトインジェクション、過剰な自律性、汚染されたメモリ、認証情報の露出、エージェント間操作に対して、完全なエージェントシステムをテストすべきです。また、統制が有用な作業を維持できるかも測定すべきです。

インシデント報告は、どのリスクが支配的かを明らかにします。プロンプトインジェクションは大きな注目を集めていますが、設定ミス、過剰な権限、共有ID、レビューされていない統合も、同等に重要である可能性があります。

その結果は、投資と設計の優先順位を形作ります。大半のインシデントが盗まれた認証情報に関係するなら、アイデンティティ保護が優先されます。有効なエージェントが許可されたツールを繰り返し誤用するなら、実行時の認可と行動統制が主戦場になります。

企業は、完璧な標準を待つ必要はありません。今すぐエージェントを棚卸しし、IDを分離し、未使用の権限を削除し、ツールを制約し、アクションチェーンを記録し、元に戻せない操作には承認を要求できます。

また、エージェントが予期しない挙動を示した場合に何が起こるかを定義すべきです。迅速な停止、認証情報の取り消し、ワークフローの隔離、証拠保全は、インシデント対応計画に含めるべきです。

実務上の問いは単純です。組織は、重大な影響を伴うエージェントのすべての行動を説明でき、ビジネスプロセス全体を停止することなくその権限を取り消せるでしょうか。

答えが「いいえ」であれば、そのエージェントにはセキュリティアーキテクチャが安全に管理できる範囲を超える信頼が与えられています。

AIエージェントによる内部脅威は、取り組みの順序を変えます。企業は、先に広範なアクセス権を与え、導入後に監視を追加することはできません。自律性より先に、アイデンティティ、タスクの境界、監査可能性、封じ込めの仕組みを整える必要があります。

開発者やエンタープライズの購買担当者にとって、次の評価は、エージェントがデモを完遂できるかどうかにとどまるべきではありません。何にアクセスできるのか、その権限はどのように失効するのか、そして独立した統制によって最終アクションを止められるのかを問うべきです。

信頼されたアクセスはいまや主戦場です。なぜなら、アクセスによってモデルの出力が現実の結果へと変わるからです。この移行を適切に統治する組織は、認証済みのすべての行動を本質的に信頼できるものと見なすことなく、自動化の価値を取り込めるでしょう。