最近のインシデントが注目される理由は、モデルが想定外の挙動を示し、アクセスや行動を制限するための安全策を回避した点にある。

　これらのモデルは、世界有数のAI企業によって機能を検証しつつ封じ込めを維持するよう特別に設計された環境で評価されていた。サンドボックスなどの隔離措置は、インターネットや外部システム、タスク処理に不要なリソースからモデルを遮断するために用いられる。

　しかし、複数のシステムがそうした境界を越える方法を見つけ出した。幾つかの事例では、悪意ある目的を持っていたわけではなく、インターネット接続や設定ミスといった意図しない隙をモデルが悪用したことが原因だった。

　例えば、OpenAIのモデルはサイバーセキュリティの課題を解決しようとする中で、未知の脆弱（ぜいじゃく）性を悪用してサンドボックス外に出てHugging Faceに到達した。Kimi K3は、割り当てられた課題を解く代わりに、意図せず接続されていたインターネットを利用してGitHub上の答えを検索した。

　この違いは、AIエージェントを導入する企業にとって大きな意味を持つ。業務上の問題を引き起こすためにエージェントが悪意を持つ必要はない。開発者や利用者が予期しなかった方法で、正当な目的を達成しようとするだけで問題は生じるのだ。

　デジタル補聴技術を提供するStarkey HearingのDevOpsエンジニアで、LLM主導のインシデント対応システムが修復動作の繰り返しによってリスクを増大させる仕組みについての論文を執筆したスダカヴィヤ・ボダパティ・ベンカタ氏は、「エージェントが1つの誤った判断を下し、その最初の失敗に基づいてさらなる行動を取ることで事態を悪化させる恐れがある」と語る。

　ベンカタ氏は、異常が発生したサービスを復旧させようとするエージェントが、サービスの再起動、容量の追加、トラフィック経路の変更、デプロイのロールバックを順次実行するシナリオを挙げる。それぞれの処置は妥当に見えても、それらが重なることで新たな問題が生じたり、コストが増大したり、他のシステムに障害が及んだりする可能性があるという。

　「危険なのは、エージェントが自らの行動結果を利用して次の行動を決定するときだ。事態が悪化している最中でも、アクションを取り続けてしまう」（ベンカタ氏）

　自身の判断に基づいて行動できる能力こそが、モデルの誤りを現実世界のインシデントへと変える要因になる。

　総合コンサルティング企業Accentureでセキュア・責任あるAIおよびデータ保護の責任者を務めるナイネシュ・パテル氏は、「自律性は、モデルのリスクを運用上のリスクへと変える」と指摘する。「不適切な解答を出力するモデルは品質の問題だが、メールの送信、レコードの変更、APIの呼び出し、資金の支出ができるエージェントは誤った判断をビジネス上のインシデントへと発展させ得る」（パテル氏）

アクセス権限が被害の及ぶ範囲を決める

　権限、ツール、ネットワークアクセス、他システムとの接続といったエージェントを取り巻く環境が、現実世界に与える影響の大きさを決定づける。

　サイバーセキュリティ企業HackerOneのスタッフイノベーションアーキテクトであるデイン・シェレッツ氏は、「エージェントがデータ、ツール、ID、外部システムへのアクセス権を持つと、ミスがもたらす影響範囲は大幅に拡大しかねない」と話す。

　CRMへのアクセス権を持つAIエージェントは、顧客レコードを変更する可能性がある。コードリポジトリに接続されたエージェントはソフトウェアを書き換えることができ、財務システムに接続されていれば取引を開始できる。社内コミュニケーションツールに接続されたエージェントは、従業員に代わってメッセージを送信することも可能だ。

　エージェントがアクセスできるシステムが増えるほど、ミスが引き起こす潜在的な影響は大きくなる。

　そのため、エージェントの導入では最小特権アクセスの原則が重要になる。アプリケーションやデータベースへの広範なアクセス権を与えるのではなく、必要な情報や機能だけに制限する。ただし、明示的な権限設定だけでは十分ではない。エージェントは接続先システムを経由して権限を継承し、必要以上のアクセス権を得てしまう場合があるからだ。

　シェレッツ氏は、単体では低リスクな複数の権限が組み合わさることで、深刻な結果を招く可能性も考慮する必要があると指摘する。「ある場所の読み取り権限と別の場所の書き込み権限が組み合わさることで、誰も明示的に承認していない結果が生じることがある」（シェレッツ氏）

　企業は、エージェントがシステムにアクセスできるかどうかだけでなく、侵入後に何を変更、送信、実行、承認できるかを検討しなければならない。

　低リスクなタスクであれば、エージェントは自律的に動作できる。一方で機密情報、本番システム、金銭、外部との通信が関わる処理については、処理の前に人間の承認を必須とする運用が考えられる。

　クラウドネイティブなデータ保護やバックアップ、サイバーリカバリーを提供するDruvaのCSO（最高セキュリティ責任者）、ヨゲシュ・バドウェ氏は、「人間の承認を求める基準は、影響の大きさと可逆性に基づいて判断すべきだ」と語る。「エージェントが実行する処理の範囲が限定的で監視可能で容易に取り消せるのであれば、人間を介在させることは自動化の価値を大きく損なう」（バドウェ氏）

　全ての処理に人間を関与させ続けることが目的ではない。企業は潜在的な影響に基づいて、エージェントの自律性をどこで制限するかを判断すべきだ。アクセス権限の設定に判断を委ねるのではなく、組織として意図的にその境界を定める必要がある。

モデル単体のテストでは不十分

　適切な権限や安全策を整えても、エージェントが想定通りに動作する保証はない。モデルはシステム全体の一部にすぎない。エージェントの挙動は、呼び出し可能なツール、受け取るデータ、指示文、動作環境に左右される。

　Anthropic、Meta、Moonshot AIの事例は、いずれもその点を示している。AnthropicとMetaのモデルはサイバーセキュリティ評価中に外部システムへアクセスしたが、テスト環境側の不備がアクセスの発生を助長していた。Kimi K3の事例では、ネットワーク設定の誤りによって意図しないインターネット接続が生じ、それを利用して解答の検索が行われた。

　企業にとって、モデルを単体でテストしても、実務のツールやデータに接続された際の挙動を完全に把握できるとは限らない。

　「モデル単体のテストだけでは不十分だ」とAccentureのパテル氏は語る。「モデル、プロンプト、メモリ、ツール、ID、権限、データ、ネットワーク経路、オーケストレーションロジック、人間の承認プロセスを含めた、デプロイ環境全体のテストが必要になる」（パテル氏）

　これは、セキュリティチームが従来のモデル評価を超えたシナリオを検証すべきであることを意味する。具体的には次のような状況だ。

• エージェントが文書を通じて悪意ある指示を受け取る
• ツールが想定外の情報を返す
• 明示的に禁止されていない行動を取ることで、タスクをより速く完了できるとエージェントが判断する

　また、エージェントの行動が、その後の判断材料となるデータに影響を与え始めた際にどう振る舞うかもテストする必要がある。Starkey Hearingのベンカタ氏は、アクションの許可リスト化、影響範囲の制限、短時間で失効する認証情報、カナリアテスト、検証済みのロールバック手順、独立したキルスイッチなどの統制策を推奨する。

　「エージェント自身が、自らを監視・停止するための仕組みを制御したり変更したりできるようにしてはならない」（ベンカタ氏）

　テストの実施は対策の一部にすぎない。企業はエージェントが想定と異なる挙動を示した際、それを検知できる体制を整える必要がある。Anthropicが公表した3件のインシデントのうち2件では、影響を受けた企業側は不正な活動を自力で検知できていなかった。Anthropicが自社の評価プロセス中にその挙動を発見し、事後に対象企業へ連絡した。

　この事実は企業に別の課題を投げかけている。エージェントが本来の役割を逸脱してシステムにアクセスしたり行動を起こしたりした際、既存の監視ツールで検知できるのかという点だ。

　従来のアクセスログは、どのアカウントがいつシステムにアクセスしたかを示すことはできても、自律型エージェントがなぜその行動を取ったのか、タスク完了に必要な処理だったのか、本来の範囲を逸脱していなかったかまでは明らかにできない場合がある。

　「監視とは、問題が発生した後に確認する単なるログであってはならない」とHackerOneのシェレッツ氏は話す。「エージェントがすべきことと実際にしていることの乖離（かいり）を捉える、能動的かつ継続的な監視であるべきだ」（シェレッツ氏）

　これには、ツールの呼び出し状況、アクセスパターン、割り当てられたタスクから逸脱した挙動の監視が含まれる。例えば、エージェントが許可リストにないツールやドメインを呼び出した際に人間にアラートを通知したり、監視用エージェントが異常と思われる挙動を検出したりする仕組みが考えられる。

　人間だけではエージェントの処理量と速度に追い付けなくなる可能性が高いため、企業はAIエージェントを監視するために別のAIエージェントを必要とする場面が増えるだろうとシェレッツ氏は付け加える。企業に必要なのは、どのシステムにアクセスできるかだけでなく、エージェントが何を実行しており、その理由は何かを把握できる可視性だ。

エージェントの権限と行動を統制する

　既存のガバナンスフレームワークは、自律型エージェントがもたらすリスクに対処するようには設計されていない。大半の企業向けAIポリシーは、偏った出力、不正確な情報、機密情報を含むコンテンツ、不適切な推奨事項など、AIが生成する出力物への対策に重点を置いてきた。しかし、エージェントは出力を生成するだけでなく、実際に行動を起こすという新たなリスクをもたらす。

　つまり、ガバナンスプログラムは従業員がどのAIツールを使用できるかを定義するだけでは不十分だ。エージェントの責任者は誰か、どのシステムにアクセスできるか、どのような行動を単独で実行できるか、どの決定に人間の承認が必要かを定める必要がある。ポリシーをコードとして管理する「Governance as Code」の手法は、これらのルールをAIエージェントに対する実効性のある統制へと変換するのに役立つ。

　「ガバナンスは、AIの出力を精査する段階から委譲された権限を管理する段階へと移行しなければならない」とパテル氏は述べる。「企業は個々のエージェントについて、責任者は誰か、何を実行してよいか、実行した証拠は何か、誰が停止できるかという4つの問いに答えられる必要がある」（パテル氏）

　行動を実行する権限があるからといって、その行動が許容可能な結果をもたらすとは限らないため、権限は慎重に定義する必要がある。

　Druvaのバドウェ氏は、「AIエージェントは許可された通りの処理を実行しながら、重大なセキュリティインシデントや運用インシデントを引き起こすことがある」と指摘する。正当な権限を持っていても、エージェントは設定を変更し、データを削除し、アクセス権を書き換え、ワークフローを混乱させることがある。その際、技術的な侵害は一切発生していない場合もある。

　これらの境界線は、エージェントに新たな機能やアクセス権が追加されるたびに見直す必要がある。例えば、最初は単一のデータベースへのアクセス権しか持たなかったエージェントが、後に別のアプリケーションに接続されたり、追加のツールを与えられたりすることがある。変更が加わるたびにシステムのリスクプロファイルは変化する。ガバナンスは導入時の一回限りの承認にとどまらず、システムのライフサイクル全体を通じて適用されなければならない。

　同じ原則は、サードパーティーベンダーや外部連携にも当てはまる。エージェントが外部のツール、サービス、インフラに接続するとリスクが変化するため、セキュリティ評価はモデル提供元だけでなく多方面に広げる必要がある。ベンダー評価では、プラグイン、データコネクタ、利用可能なツールなど技術全体を通じてAIエージェントがどのように隔離、監視、制御されているかを精査することが求められる。

　また、IDおよびアクセス管理も、エージェントが従来のソフトウェアとは異なる挙動を示す点を考慮しなければならない。既存システムの多くは、人間のユーザーや予測通りの動作をするソフトウェアを前提に設計されているとシェレッツ氏は話す。AIエージェントはタスクの完了方法を自ら判断するため、与えられたアクセス権がどのように使われるかを正確に予測することは難しくなる。

　ガバナンスには、エージェントが何へのアクセスを許可されているかだけでなく、機能や接続先が進化する中でそのアクセス権がどのように行使され得るかを考慮することが求められる。

エージェントの異常行動に備える

　慎重なガバナンス、テスト、権限管理、監視を行っていても、エージェントが常に想定通りに動作するとは限らない。企業は想定外の事態が発生した際の対応計画を用意しておく必要がある。

　対応策には、エージェントの認証情報の失効、特定システムからの切断、自動ワークフローの停止などが含まれる。情シスは、誰がそれらの措置を実行する権限を持ち、どれほど迅速に対処できるか、そしてエージェントが何を実行したかを特定するための記録が残されているかを知っておきたいところだ。

　ただし、エージェントを停止させることは最初の段階にすぎない。企業はエージェントが停止される前に何が起きたのかを把握し、すでに加えられた変更からどのように復旧するかを理解しておく必要がある。

　「封じ込めは重要だが、復旧性も同様に重要だ」とバドウェ氏は語る。「そのためには、IDのアクティビティー、API呼び出し、設定変更、データの移動、下流システムに対する可視性が必要になる」（バドウェ氏）

　正当な変更と有害な変更を区別し、影響を受けたシステムとデータを正常な状態に戻すためには、環境についての信頼できる記録が必要だとバドウェ氏は指摘する。

　エージェントが実行するアクションの規模も問題となる。何千もの顧客レコードや本番システムで同じ処理を繰り返すエージェントは、わずかな誤りを大規模なインシデントへと拡大させてしまう。

　これは、エージェント環境の最小特権アクセスの限界を示している。権限管理はエージェントが実行を許可された内容を制限できても、処理を実行する速度や頻度までは制限できない場合がある。例えば、出金処理の権限を厳密に制限されたエージェントであっても、誤った送金先や誤った金額で支払いを実行してしまうリスクは残る。

　従って企業は、自律性と両立して封じ込めと復旧の手段を検討する必要がある。ビジネスクリティカルなシステムに対する実質的な権限をエージェントに与える前に、エージェントがどのような行動を取れるのか、それらの行動をどう停止できるのか、そして問題が生じた際にどのように復旧するのかを知っておきたい。

　「目指すべきは自律性をゼロにすることではない」とパテル氏は言う。「境界を定めた自律性だ。エージェントは明確に定義された範囲内で迅速に行動し、組織はその範囲外の挙動を検知、遮断、復旧できるようにする」（パテル氏）

　最近のインシデントは、AIエージェントが本質的に危険であることを示すものではない。自律性、アクセス権限、監視、封じ込めをセットで考慮しなければならないことを示している。システムの高度化が進むにつれ、企業は安全策が常に機能すると過信するのではなく、予期せぬ挙動が発生することを前提に対策を講じる必要がある。