ソートリーダー
自律型AIシステムがもたらすセキュリティ上の影響：攻撃側の厳密な検証という視点
Unite.AI を Google の優先ソースに追加
知能から権限へ
人工知能は、質問への回答やコンテンツの生成にとどまらない領域へと進みつつあります。AIシステムはますます、指示を解釈し、計画を立て、ツールを選び、人間の継続的な指示なしにタスクを実行できるようになっています。
この違いは重要です。
行動を提案するAIシステムと、その行動を実行する権限を与えられたAIシステムは異なります。その違いは、必ずしも知能や高度さにあるわけではありません。違いを生むのは権限です。
自律型システムは、最先端の大規模言語モデルに限られません。特化型の機械学習システム、ロボティクス、自動運転車、ソフトウェアエージェントのほか、定められた運用条件の範囲内で独自に判断したり行動したりする技術の組み合わせも含まれます。
自律型システムがもたらす潜在的な利益は大きいものです。科学的発見、産業運営、医療、ソフトウェア開発、サイバーセキュリティを支援できます。一方で、意図しない結果を招いたり、機密情報を漏えいさせたり、運用者の意図を超える行動を開始したりする可能性もあります。
自律型システムの設計におけるセキュリティ上の課題では、Mohammad HamadとSebastian Steinhorstが、自律型インシデント対応、リスク評価、アクセス制御、データの信頼性、自律型システム間の相互作用に関わるセキュリティ上の課題を検討しています。サイバーフィジカルシステムを主な対象とする彼らの研究は、機械が独自に行動するシステムのセキュリティ確保が、今日のLLMエージェントにとどまらない課題であることを示しています。
自律性がもたらす広範な影響については、身体的危害の可能性も含め、真剣に検討する必要があります。ただし、証拠は慎重に解釈しなければなりません。たとえば、自動運転車に関する事故を、自律型サイバーセキュリティエージェントに影響するものと同じ仕組みによるものだと、ただちに判断することはできません。自律性の度合い、運用条件、人間の関与、因果関係を示す証拠が重要です。
同様に、自律型AIが危害をもたらす可能性を示す証拠があっても、それだけでガバナンスが必然的に後れを取っているとは言えません。また、自律型システムは本質的にセキュリティ確保が難しいと決めつけるべきでもありません。
核心となる問いは、AIが複雑な作業を実行できるかどうかではありません。自律型システムを統制するアーキテクチャ、セキュリティ、組織の枠組みによって、委任された権限に適切な境界を設け、その境界が守られていることを検証可能な証拠で示せるかどうかです。
サイバーセキュリティは、この問いを考えるうえで特に有用な視点をもたらします。セキュリティの専門家は何十年にもわたり、信頼、権限、アクセス、システムの振る舞いに関する前提を問い直してきたからです。
機械の速度で進む攻防のいたちごっこ
サイバーセキュリティは、長らく攻防のいたちごっこと表現されてきました。
攻撃者が弱点を見つけ、防御側が対策を導入し、双方がそれに適応します。技術、戦術、運用環境の変化に伴い、このサイクルは続いていきます。
自律型AIが、この攻防の根本的なルールを変えるとは限りません。変わる可能性があるのは、誰が、あるいは何が攻防を担うのか、どれほど速く行動するのか、そして人間が継続的に介入しなくてもどれだけの作業を進められるのかです。
自律型の攻撃セキュリティシステムは、外部に公開されたサービスを特定し、脆弱性を調査し、攻撃経路の候補を作成して、その経路が悪用可能かどうかを検証することがあります。防御システムも同様の能力を使って脅威を調査し、弱点を特定し、修正が有効かどうかを検証できます。
このような二重用途の可能性は、自律型AIがセキュリティにもたらす影響を理解するうえで中心的な要素です。
AnthropicのProject Glasswingは、AIを活用した脆弱性発見の事例です。Anthropicは、2026年5月の研究アップデートで、脆弱性の発見において大きな成果を報告するとともに、検証、開示、パッチ適用に伴う運用上の課題を強調しました。
この違いは重要です。脆弱性を発見することは、それが悪用可能だと確認すること、修正すること、あるいは影響を受けるシステムの安全性を実証することと同じではありません。
発見される脆弱性が増えれば状況の把握が進む一方で、それらの解決を担う人々やプロセスにかかる負担も増大します。
セキュリティ上の結果は、その後の対応によって決まります。
攻撃者と防御側の双方が作業の一部を自動化できる場合、重要な問いは、どちらが最も高性能なモデルを持つかだけではありません。防御側が発見を効果的な修正につなげ、その結果を独立して検証できるかどうかです。
AIが攻撃的なタスクを実行できるからといって、従来の侵入テストが時代遅れになるわけではありません。侵入テストの対象範囲には、指示を解釈し、ツールを呼び出し、権限を組み合わせ、複数の段階を経て目標を追求するシステムも含める必要があります。
目標はこれまでと変わりません。弱点を見つけ、その重要性を明らかにし、修正し、対策が機能することを証明することです。
アーキテクチャ上の継ぎ目：セキュリティ境界が交わる場所
自律型システムに潜む、より見えにくいリスクの一つは、個別には正当に許可されたコンポーネント同士が連携し、意図しない結果を生み出す場合に生じる。
私は、こうした相互作用が起きる接点を「アーキテクチャ上の継ぎ目」と呼んでいる。
一般的な例を考えてみよう。ある組織がNTFSのアクセス許可を使ってファイルへのアクセスを制限している。一方、別のクラウド共有サービスでは、許可されたユーザーがその情報を外部と共有できる。
それぞれのシステムは、独自のルールに従って動作するかもしれない。しかし両者が連携すると、組織が意図したセキュリティ境界に反する情報共有が起こり得る。
これはポリシーが相互に矛盾する可能性を示す例であり、特定のファイル共有製品に脆弱性があると主張するものではない。
問題は、個々の制御に欠陥があることではないかもしれない。ワークフロー全体にわたって意図したセキュリティポリシーを適用できていないことが原因である可能性がある。
自律型AIでも、モデル、アプリケーション、ID、ツール、リポジトリ、外部サービスを接続する際に、同様の状況が起こり得る。
エージェントには、文書の読み取り、リポジトリの作成、ファイルのアップロードが許可されている場合がある。しかし、それは機密情報を露出させるような形で、これらの操作を組み合わせる権限まで与えられていることを必ずしも意味しない。
こうした相互作用を検討すべき実践的な理由は、研究によって示されている。
AgentDojoでは、研究者が、ツールを使うAIエージェントに対するプロンプトインジェクション攻撃を、現実的な97件のタスクと629件のセキュリティテストケースで評価した。その結果、信頼できないツール出力に仕込まれた悪意ある指示によって、一部のセキュリティ特性が損なわれ得ることが示された。ただし、攻撃やエージェントが一様に成功したわけではない。
この研究から、本番環境でこうした攻撃がどれほどの頻度で成功するかは分からない。一方で、ツールと接続されたシステムの挙動を理解するには、モデルの応答だけを評価するのでは不十分であることが示されている。
関連するリスクは、「権限のロンダリング」と表現されることもある。許可されたツールや仲介者を経由することで、ある操作は正当なものに見えるが、組み合わさった挙動は意図された権限の境界に反している、というものだ。
複数のエージェントが連携する場合、誰が参加できるのか、どのように情報をやり取りするのか、どの操作が許可されるのかを定める明確なルールが必要になる。
アーキテクチャ全体にわたる責任の所在も明確にしなければならない。
モデルプロバイダー、プラットフォーム運用者、エージェント開発者、導入組織は、それぞれシステムの異なる部分を管理している場合がある。実効性のある共同責任モデルでは、各境界を誰が管理するのか、誰が例外を承認できるのか、誰が実行状況を監視するのか、問題が発生した際に誰が対応するのかを明らかにする。
自律性によって責任がなくなるわけではない。責任の所在を把握する重要性が増すのである。
攻撃的厳密性：既知の前提を検証する
ここで、「攻撃的厳密性」と私が呼ぶ概念について説明したい。
攻撃的厳密性とは、セキュリティ上の前提を問い直す、敵対的テスト、批判的な検討、証拠に基づく検証を規律正しく行うアプローチである。アーキテクチャ設計、文書化された制御、あるいは想定上の保護だけに頼らず、現実的な条件下でシステムがどのように振る舞うかを評価する。
その基盤となる手法は確立されている。侵入テスト、脅威モデリング、レッドチーム演習、セキュリティ検証は、長年にわたり防御側の前提を問い直してきた。
攻撃的厳密性は、こうした手法を次の中心的な問いのもとに結び付ける。
意図されたセキュリティ境界が保たれていることを、どのような証拠で示せるのか？
組織は、機密情報を制限するポリシー、禁止された要求を拒否するよう設定されたモデル、限られた権限で動作するエージェントを備えているかもしれない。
これらは有意義な保護策である。しかし、それらが存在するだけでは、敵対的な状況下でシステム全体が安全に動作することの証明にはならない。
モデルが悪意ある指示を拒否しても、許可されたツールが意図しない操作を認めてしまうことがある。ポリシー自体に問題がないように見えても、システム間の相互作用によって、予期しない迂回経路が生じる場合がある。
私はこれを「ガードレール幻想」と呼ぶことがある。ガードレールが存在することを、それが防ごうとしている境界をシステムが越えられない証拠だと思い込むことだ。
ガードレールは有用である。それでも、その有効性は実証する必要がある。
侵害の疑いを調査する権限を与えられた自律型エージェントを考えてみよう。このエージェントはログを取得し、ユーザーの活動を調べ、封じ込め策を提案できる。
許可を得たセキュリティテストで、攻撃者役のテスターが、エージェントが読み込むことを想定されている情報に、誤解を招く指示を仕込む。
その指示にエージェントが従ったかどうかを確認するだけで、テストを終えてはならない。
エージェントが許可されていない操作を試みたか、独立した制御によってその実行が阻止されたか、その試みが記録されたか、システムが適切に復旧したかを検証すべきである。
攻撃的な厳密性は、次の5つの活動を結び付けます。
- 前提を定める：アーキテクチャが実現すべきセキュリティ特性を特定する。
- 前提に疑問を投げかける：現実的な攻撃経路、細工された入力、正当な機能の組み合わせを検証する。
- 証拠を収集する：システムが何を試み、何が実行され、どの制御が機能したのかを明らかにする。
- 弱点を修正する：失敗の原因となったモデル、ワークフロー、権限、アーキテクチャ、または運用プロセスに対処する。
- 修正を検証する：該当する攻撃経路を再テストし、意図したセキュリティ特性が確実に実現されていることを確認する。
これは、モデルの応答をテストすることと、システム全体のセキュリティをテストすることの違いです。
また、最初の足掛かりを得た後に何が起きるかも調べる必要があります。攻撃者は、環境内ですでに利用できる機能を悪用して、認証情報の収集、権限昇格、永続化、またはラテラルムーブメントを試みる可能性があります。
ツールが正当なものであっても、その使い方がすべて正当とは限りません。
攻撃的な厳密性の目的は、自律システムが安全でないと決めつけることではありません。テストを通じて、システムのセキュリティ境界がどこまで機能するかを明らかにすることです。
条件付き自律性：知能と権限を切り分ける
アーキテクチャ上の対応策の一つは、AIシステムが実行できることと、実行を許可されていることを区別することです。
私はこのアプローチを「条件付き自律性」と呼んでいます。
条件付き自律性とは、適切な自立度が、タスク、動作環境、起こり得る影響、不確実性、そして行動を正当化するために利用可能な証拠によって異なるという考え方です。
公開情報を要約するエージェントに必要な監督の水準は、アカウントの無効化、ファイアウォールルールの変更、本番環境のインフラ変更を許可されたエージェントと同じとは限りません。
後者には、明示的な交戦規定、独立して適用される権限管理、より厳格な承認、そして重大な影響を伴う行動に対する人間の承認が必要となる場合があります。
エージェントが、目的の達成に広範なアクセスが役立つと判断したというだけで、こうした境界を広げてはなりません。
エージェントは、追加の権限を得ることなく、許可されたタスクの実行方法を再検討できます。
LLMアプリケーション向けOWASPトップ10では、LLM06:2025 過剰なエージェンシーのカテゴリでこの問題を取り上げています。OWASPは、過剰な機能、権限、自律性をリスクの要因として挙げ、機能を制限するとともに、認可を独立して適用することを推奨しています。
条件付き自律性は、運用上のリスクに応じてこれらの原則を適用します。
情報へのアクセスは、タスクに必要な範囲に限定すべきです。ツールの権限は、承認された操作に限って付与する必要があります。実行回数の上限、レート制限、承認要件、停止条件によって、実行を制約できます。
こうした安全対策は、自律型の攻撃テストにおいて特に重要です。
テストエージェントは、許可された目的を追求する過程で、正当に認証情報や機密情報を発見することがあります。しかし、認証情報を発見したからといって、モデルがその平文の値を受け取る必要があるわけではありません。
セキュリティハーネスを使えば、機密性の高い認証情報をモデルから切り離し、独立して適用される認可を通じてその利用を仲介できます。たとえば、認証情報ブローカーが、不要な形でモデルに秘密情報を開示することなく、承認済みのサービスに直接その情報を渡すことができます。
これは、最小権限の原則と職務分掌の原則を適用するものです。
また、Bring Your Own Model (BYOM)、あるいはBring Your Own LLM (BYO-LLM)のアーキテクチャについて、興味深い問いも提起します。
基盤となるモデルを明日別のものに置き換えた場合、どのセキュリティ保証が維持されるでしょうか。
タスクの認可、認証情報の分離、スコープの制限、ログ記録、ポリシーの適用は、モデルの振る舞いだけに依存するのではなく、周辺のハーネスが担っている場合があります。
だからといって、ハーネスが自動的に安全になるわけでも、モデルを相互に置き換えられるわけでもありません。モデルによって指示の解釈やツールの呼び出し方が異なり、障害の発生パターンも異なる可能性があります。
有意義な評価では、不変であることを意図した制御と、モデルの変更に伴って変化する振る舞いの両方をテストする必要があります。
おそらく、最も長く維持されるセキュリティ特性の一部は、知能を担うコンポーネントが進化しても独立して適用し続けられるものです。
AIがAIに働きかけるとき：検証の課題
次のようなセキュリティ運用ワークフローを想定してください。
このインシデントを調査し、証拠を収集し、影響を受けたIDを特定し、封じ込め策を提案し、承認済みの措置を実行して、その結果を検証してください。
調査エージェントがテレメトリを分析する。別のエージェントが封じ込め策を提案する。承認を受けた実行エージェントが変更を加える。検証エージェントが結果を評価する。
これはクローズドループ型の自律的なインシデント対応を示すものであり、業界全体で起きたと記録された失敗ではない。
最初のエージェントが、あるIDが侵害されたと誤って特定したとする。2番目のエージェントがその判断を受け入れ、アカウントを無効化する。3番目のエージェントがアカウントの無効化を確認し、成功したと報告する。
選択された操作は完了した。
しかし、最初の判断は正しかったのか。その操作は承認されていたのか。封じ込めは実際の脅威に対処できていたのか。不必要な混乱を招かなかったか。
検証とは、エージェントが自ら選択した操作を完了したことだけを確認するものではない。
また、検証を別のAIエージェントに任せれば、結果が自動的に独立したものになるわけでもない。
異なるエージェントが、同じ不正確なテレメトリ、侵害された情報、あるいは誤った前提に依存している可能性がある。エージェント同士の一致だけでは、根底にある事実を独立して立証したことにはならない。
自律的な操作がもたらす影響が大きいほど、意思決定を行うシステムから独立した検証がいっそう必要となる。
この独立性は、別の情報源から得た証拠、決定論的なポリシーチェック、制約された実行環境、人間によるレビュー、あるいは複数の安全策の組み合わせによって確保できる。
適切な管理策は、誤りがもたらす影響に見合ったものであるべきだ。
影響が小さく、元に戻せる操作は、自動検証に適している場合がある。一方、影響が大きい操作や元に戻すのが難しい操作には、より強固な承認、独立した確認、明示的な人間の承認が必要となる場合がある。
関連するセキュリティ特性を見分けるには、次の4つの問いが役立つ。
- システムは意図されたタスクを正しく解釈したか。
- その操作は委任された権限の範囲内だったか。
- 実行は許可された境界内にとどまったか。
- その結果は、意図されたセキュリティ目標を満たしたか。
これらの問いには関連があるが、互いに置き換えられるものではない。
エージェントは、承認された操作を実行しても、意図しない結果を招くことがある。また、承認されていない操作によって、一見すると有益な結果を生むこともある。
いずれも、自動的にセキュリティ上の成功と見なすべきではない。
自律型システムの能力が高まるにつれて、課題は複雑なワークフローを完了できるようにすることだけではなくなる。システムの行動が引き続き承認され、適切かつ正確であることを示す十分な証拠を確立する必要がある。
そのためには、いつ停止し、エスカレーションし、操作を取り消し、あるいは範囲が限定され明確に理解されたリスクを受け入れるべきかを把握することも必要だ。
信頼は証拠に基づくべきである
自律型AIがもたらすセキュリティ上の影響は、悪い面ばかりではない。
自律型システムは、防御側が脆弱性を発見し、脅威を調査し、そうでなければ多大な人的労力を要する検証作業を行ううえで役立つ。
より優れたモデル、強固な外部統制、成熟した運用慣行によって、権限の委任に伴うリスクの一部を低減できる可能性がある。
したがって、自律型AIは本質的に安全でない、あるいはガバナンスはその発展に追いつけないと結論づけるのは時期尚早だ。
自律型AIには根本的に新しいセキュリティ原則が必要だという考え方に対しては、重大な反論もある。
過剰な権限、信頼できない入力、脆弱な承認、不統一なポリシー適用、不十分な検証といった根本的な問題の多くは、何十年にもわたって研究されてきた。
確立された管理策も、正しく導入・テストすれば、すでに実用的な解決策となり得る。
自律性によって、その適用の速度、規模、複雑さは変わる可能性がある。しかし、それらの管理策が自動的に無効になるわけではない。
証拠を踏まえると、より有益な問いが浮かび上がる。自律型システムが委任された権限を行使しても信頼できるのは、どのような条件のもとでか。そして、その条件が満たされていることを、どう示すのか。
その答えは、モデルの能力だけからは得られない。
アーキテクチャ上の境界、明確に割り当てられた責任、独立して適用される承認、適切な監督、そして現実的な条件下で安全策が機能することを示す証拠が必要だ。
また、一貫性を保ちながら進化する、セキュリティとリスクに関するビジョンも必要となる。
新しいモデルが登場するたびに、セキュリティの基本原則を変える必要はない。しかし、能力、運用環境、委任される権限が進化するなかで、それらの原則がどう適用されるかという前提には、継続的に疑問を投げかけなければならない。
これが「攻撃的な厳密性」の目的である。
AIシステムが失敗することを証明するのではなく、どこで失敗し得るのかを突き止め、その結果を明らかにし、そうした失敗を防止または封じ込めることを目的とした制御策を検証するためである。
おそらく、より持続的な優位性は、単により高性能なモデルを選ぶことではなく、信頼、権限、検証の境界を損なうことなくモデルを変更できるアーキテクチャを構築することにある。
いたちごっこは続いている。双方に自律型のプレイヤーが存在する状況が、ますます増えていく可能性がある。
重要なのは、ほかのあらゆるものを自動化しようとする競争の中で、弱点を見つけ、修正し、その成果を証明する能力を失わないようにすることだ。
信頼は証拠に基づくべきだ。
著者注：この記事に記した見解や解釈は私自身のものであり、雇用主の公式な立場、方針、製品機能を必ずしも反映するものではありません。
