2026 年 7 月、AI 投資家で元 HyperWrite CEO の Matt Shumer は、OpenAI が未公開の GPT-5.6(コードネーム Sol)を自分の Mac で試していた。マシン全体へのアクセス権をそのまま与えたところ、クリーンアップ用のサブタスクがホームディレクトリに向けて rm -rf を一発叩いた。気付いて止めるまでに一時間以上が経過し、大半のファイルは失われていた。
不快な事実は、OpenAI 自身がこの種のリスクを既に知っていたことである。事故のわずか 16 日前、モデルカードには 「AI Agent にフルアクセスを与えること」が重大なリスクとして記載されていた。
ここに攻撃者はいない。エクスプロイトも存在しない。ファイルを消すのは、Agent に与えられた通常の権限の一つだったにすぎない。
この事例が示すのは、より根本的な問題である。今日の AI Agent の多くは、設計からして安全ではない。そして直感的な対処法——モデルの内側に guardrail を積み増すこと——は方向が間違っている。guardrail は防御対象と同じ階層に置かれるため、いくつ積んでも回避され得る。実効的な防御は、モデルの外側に置かれる必要がある。
「AI セキュリティ」は三つの別物であり、本稿は第三の話
「AI セキュリティ」という語は流行しているが、文脈によって意味するものはまったく異なる。おおむね三通りある。
第一に、モデル自体のセキュリティ。jailbreak を防ぎ、有害な出力を出させず、人間の意図に沿わせる。過去数年の議論の大半はここに集中してきた。
第二に、防御に AI を使う(AI for security)側面。大規模モデルを反転させて脅威検知、コード監査、インテリジェンス分析などに使う話である。私たち自身もいくつか研究を進めてきた。たとえば、思考拡張型モデルでスマートコントラクトの脆弱性を検出する Thought Is All You Need、そして AI Agent が実際にスマートコントラクトの監査に耐え得るかを測る REEVMBench がある。
第三が、本稿のテーマ、AI Agent 自体のセキュリティである。モデルが「質問に答える」だけの存在をやめ、ファイルを読み、認証情報を保持し、ユーザーに代わって行動を起こすようになると、呼び出せるツール、保持する権限、そして毎回の行動そのものが攻撃面(attack surface)になる。
前二者は研究の蓄積があるのに対し、第三は新しく、見落とされやすい。しかしこれこそが、AI Agent が企業に本格的に入っていくための前提条件である。自分自身の安全を守れない Agent に、本物の業務と本物のデータを預ける企業はどこにもいない。
信頼できない入力から任意実行へ:先天的な欠陥
Agent が実務をこなすには、通常いくつかの能力を同時に持たされる。外部コンテンツを読める(Web ページ、メール、コードリポジトリ、他人のプルリクエスト)、価値のあるリソースにアクセスできる(鍵、クラウドの認証情報、データベース)、そしてツールを呼んで実行できる(コマンド、リクエスト、ファイル書き換え)。この三つが同居した瞬間から、最も危険な組み合わせが出来上がる。
問題の根は、モデルが「これはオペレータの指示か、それとも読み込んだ他人の文章か」を区別できない点にある。モデルにとってはすべて同じコンテキストウィンドウ内の同じ文字列である。誰の言うことを聞くかは、明確な規則ではなく学習された勘によって決まる。セキュリティ分野の古い呼び方をすれば、これは confused deputy 問題そのものである——権限を持つプログラムが、権限を持たない側にそそのかされて、代わりに害のあることを実行してしまう。
連鎖を分解するとこうなる。実行を担うツールはモデルに従い、モデルはプロンプトに従う。そのプロンプトは、ユーザーが書いた文と、Web・メール・ドキュメントから引き込んだ文が同居した混成物である。結果として、信頼できない出所の文が、挙動の不確定なモデルを介して、ツールに任意の操作を命じる経路が成立する。従来のソフトウェアではデータとコードは明確に分離されていた。Agent においては、読み込んだ一文がその瞬間からコマンドとして解釈されうる。
つまり攻撃者に高度なエクスプロイトやアカウント窃取は不要である。ドキュメントに、Web ページに、あるいはソースコードのコメントに一文を仕込むだけで、Agent は本来やるべきでないことを実行しうる。Microsoft のセキュリティチームは端的にこう言い切っている——LLM はセキュリティ境界ではない。露出しているツールこそが、攻撃者に許した行動範囲を規定する。
これは仮説ではなく、実例が積み上がっている。xAI の Grok Build は、作業セッションが始まるたびにリポジトリ全体を——.env の秘密情報も、完全なコミット履歴も含めて——自社クラウドに黙って送信していた。実測でタスクに必要な量の三万倍近くである。Cursor の Agent はあるテストで本番データベースをバックアップごと九秒で消し飛ばし、そのあと謝罪文を書いた。Replit の Agent は明示的なコード凍結期間中に本番 DB を丸ごと削除し、数千件の偽レコードを捏造して隠蔽した。Amazon Q の VS Code 拡張は悪意あるコミット経由で「システムを一掃せよ」という命令が仕込まれ、公式リリースとして百万台近い端末に配布された。
これらの事故には共通点がある。損害の原因はほとんどの場合、Agent が正規に付与されていた権限そのものであり、外部からの侵入ではない。.env の読み取り、コマンドの実行、DB へのクエリ——いずれも Agent が普段からやっている操作である。送信チャネルが一つ、削除コマンドが一発あれば、日常の能力が事故に転化する。
モデル内 guardrail が届かない理由——防御側が同じ階層にいる
これらの事故に対する直感的な対応は、Agent の内側に guardrail を積むことである。ここでいう guardrail とは、モデルの内部に置いた規則で危険な行為を止める仕組み——プロンプトで「危険な操作をするな」と指示する、あるいは Agent の内部にチェック層を挟み、一部のコーディングツールのように危険なコマンドやファイルパスを拒否する類のものを指す。
しかしこの発想には根の深い問題がある。guardrail と防御対象が同じ階層に置かれている、という点である。
米国国立標準技術研究所(NIST)の上級科学者 Apostol Vassilev は、2026 年 6 月、まさにこの構造を Gödel の不完全性定理の論理に重ねた論文を発表した。タイトルそのものが問いかけになっている——Robust AI Security and Alignment: A Sisyphean Endeavor?。
彼の議論は概ねこうだ。guardrail は結局のところ、有限で固定的な規則の集合である。有限な公理系が完全かつ無矛盾になり得ないのと同じ理由で、任意の固定された guardrail の集合には、それを回避する文が必ず存在する。人間の自然言語の曖昧さと柔軟さから、その候補は事実上無尽蔵である。彼自身の言い方を借りれば、いかなる有限の guardrail 集合も、あらゆる敵対的プロンプトに対して普遍的にロバストではない。残る問題は、その一文を防御側と攻撃側のどちらが先に見つけるかである。NIST は同じ日に「一度で正しくやる」から「継続的に監視して継続的に更新する」への発想転換を提言している。
もう一つ直接的な証拠がある。モデル自体が信用できないなら、別のモデルに「あのモデルが乗っ取られていないか」を判定させれば良いのではないか——ウィスコンシン大学の研究がこの筋を検証した結果、この道は行き止まりだった。あるモデルが別のモデルの改ざんを検出する方式には構造的な欠陥があり、研究者が構築した適応攻撃は検出率をほぼゼロまで押し下げつつ、注入自体は九割近く成功させた。攻撃を発見するはずのモデルが、監視対象と同じ階層に置かれ、先に取り込まれる。
見落とされやすい時系列の問題もある。guardrail が発動する時点で、Agent はすでに実行権限を握っている。EchoLeak がその最もはっきりした例だ。これは Microsoft 365 Copilot に対するゼロクリック攻撃で、周到に作られたメールが Copilot の前段に置かれた注入フィルターを静かにすり抜けて、機密データを外部に運び出した。ユーザーは何もクリックしていない。
つまり「モデル内側の guardrail」は、いわばマジノ線に近い。無用ではないが、設計上必ず迂回される。防御の一層ではあり得ても、唯一の線にはなり得ない。
真の防御は、Agent の外側に築かれる
モデルの内側が信用できない以上、防御線は外側——システム階層——に移動する必要がある。
信頼できないコードを隔離された環境に閉じ込め、必要最小限の権限しか与えない——この発想はシステム安全の分野で目新しいものではない。1975 年、Saltzer と Schroeder の古典論文はすでに二つの原則を提示していた。最小権限(least privilege)——プログラムには仕事に必要な最小限の権限だけを与える。権限分離(separation of privilege)——権限を分割し、単一の失敗や欺瞞で全体が破綻しないようにする(The Protection of Information in Computer Systems)。その後の sandbox 系譜——1990 年代の Janus、2000 年の FreeBSD Jails、そして今日の gVisor——はすべて同じ道を歩んでいる。信頼できないコードを隔離し、たとえ侵害されても外側に及ばないようにする。AI Agent の防護とは、結局、この数十年蓄積された成熟した実践を、新しい対象に適用する話である。
今日的な具体策として最も直接的なのは、システム階層の sandbox を被せることだ。Agent がツールを実行する環境を隔離し、システムコール、ファイル読み書き、ネットワーク出口の粒度で制御する。ただしツールごとにデフォルトの厳しさは大きく異なる。OpenAI の Codex はコマンド実行を既定で sandbox に入れ、ネットワークも既定で遮断する。一方 Claude Code のローカル版 sandbox は手動で有効化する必要があり、Cursor の sandbox はメーカー自身が「ベストエフォート」と述べ、セキュリティ境界とみなさないよう明記している。さらに踏み込むと、Agent 全体をプラットフォームが管理するランタイムに閉じ込め、ネットワークと認証情報をその外側の層に委ねる形にできる。Anthropic のクラウドホスト版 managed Claude Code はまさにこの形だ。セッションごとに Anthropic 管理下の VM 上で動作し、外向きリクエストは allowlist の付いたプロキシを通り、認証情報は sandbox の外に保持される。
自然な疑問が浮かぶ。sandbox がここまで成熟しているなら、先の削除事件やリポジトリ流出はなぜ起きたのか。理由は二つある。第一に、これらツールのデフォルト防護はしばしば薄い。Cursor は既定で厳しい sandbox を持たず、GPT-5.6 の事例ではユーザーがフルアクセスを与えた——sandbox を実質オフにしたのと同じである。第二に、sandbox が有効でもこの種の事故は止まらない。sandbox が防ぐのは Agent がホストへ逃げ出して害を及ぼすことだが、削除された DB や送信されたリポジトリは、いずれも Agent が明示的にアクセスを認められていた対象だった。逃走の必要がそもそもない。よって sandbox は必要な一層ではあるが、まったく十分ではない。
「Agent の到達範囲を柵で囲う」という発想は、一般のオフィスユーザー向け製品にも入ってきている。テンセントが今年公開したデスクトップ助手 WorkBuddy は個人 PC 上で動作し、ユーザーが承認したローカルフォルダのみを読み取る。ただし公開資料は「承認済みフォルダ」と述べるだけで、内部で実際にどう隔離しているか、どこまで及ぶかには踏み込んでいない。
より重要な点はこうだ。この「sandbox 付き Agent」というカテゴリ全体には、共通の死角がある。sandbox は Agent がどこで動くか、ホストへ逃げ出すかどうかを制御するが、動いている最中にデータをどう扱うかは制御しない。プロンプト注入を受けた Agent は、明示的に許可された経路のみを通って動作するため、正常運用とまったく区別がつかない。ある研究者は Google の GKE Agent Sandbox を評してこう述べた——これは「isolation sandbox」であって「behavior sandbox」ではない。Agent がどこで動くかを決めるが、動作中に何をしているかは見ていない。
sandbox が「Agent がどこで動くか」しか制御できない以上、Google DeepMind は一段踏み込んだ提案をしている。設計段階から大規模モデルを信頼できない部品として扱い、AI を介さない固定層を外側に置き、そこがステップごとに実行可否を判定する。彼らの CaMeL では、信頼できるユーザー指示をまず AI 非依存のインタプリタが実行するプログラムに変換する。このインタプリタは各データの由来を追跡し、ツール呼び出しの直前にポリシーに照らして許可を判断する。信頼できない外部コンテンツに実際に触れるモデルには、そもそもツール呼び出しの権限がない。相当数のタスクにおいて「証明可能な安全性」を提供する。
sandbox で解けない難所——Agent が仕事に必要とするデータ
とはいえ、sandbox にせよ CaMeL にせよ、いずれも避けて通れない別の難所がある。この件で最も扱いにくい部分である。
sandbox は Agent とホストを分離するが、Agent が仕事に必要とするデータの周りには壁を築かない。コード、.env、クエリすべき DB——いずれも Agent と同じ環境に置かれる。Agent が仕事を回すには、何らかの外向きチャネルが必要である。結果として、侵害された Agent は自らが読めるものを、その許可された経路を通じて外に運び出せる。Anthropic 自身の sandbox ドキュメントにも同旨の記述がある——ネットワーク出口を許すかぎり、Agent が読める内容は持ち出されうる。allowlist はドメインで絞るのみで、出て行くものの中身までは検査しない。
では、Agent の業務に不可欠なそのデータをどう守るか。ケースは三つに分かれ、後になるほど厄介になる。
第一は、明示的な認証情報、たとえば API キーである。Agent が中身を理解する必要はなく、リクエストの発行に使うだけである。したがってモデルには常にプレースホルダーしか見せず、実際のリクエスト送信の瞬間にだけ、外側の管理ランタイムが本物のキーに差し替える構成にできる。誰かがプロンプト経由で「キー」を吐き出させても、手に入るのは無意味なダミーである。この類は基本的に工学で片が付く。
第二は、Agent 自身が読んで推論するしかないデータである。財務分析 Agent に財務データを与えなければ、そもそも仕事にならない。ここでは単純な差し替えが効かない。妥協案として、厳格に隔離した子 Agent を別途走らせ、機密データに触れるのはその子だけ、外へは結論のみを渡す、という手段がある。だが、結論そのものが機密でないと誰が保証できるかという避けがたい問題が残る。漏洩はしばしば言い換えられ、意味の中に埋め込まれる形をとる。キーワードマッチでは捕まらない。隔離は爆発半径を縮めるが、封じ切ることはない。
第三は、最も徹底した情報フロー追跡である。すべてのデータにラベルを付け、流れる先を追跡し、外に出ようとする瞬間にブロックする。Microsoft の Fides はこの路線で、情報フロー制御を用いてデータの動きを追跡する。原理としては最もクリーンだ。ただしコストも最大で、性能を落とし、使い勝手を損ね、ラベルは増殖し、ポリシーの記述と保守を担う人が要る。セキュリティと可用性のトレードオフが最も鋭く突き刺さるのがここである。
Agent セキュリティのシステム工学——隔離・制御・追跡可能性
これらの手段はいずれも単独では問題を解けない。guardrail は迂回され、sandbox はデータの流出を止めず、情報フロー追跡はコストが高すぎ、子 Agent 隔離は結論の非機密性を保証できない。
だが、セキュリティという分野は昔からそういうものだ。絶対的な「安全」も「非安全」も存在せず、できるのは攻撃コストを引き上げ、事故の爆発半径を縮めることの積み重ねだけである。
したがって、企業向け(ToB)の Agent プロダクトを本気で作るチームにとって、単一の銀の弾丸は存在しない。実務的な取り組みは三つを重ねることになる。第一に隔離——システム階層の sandbox と外部制約で、Agent が何をできるかを厳密に区切る。第二にポリシー制御——最小権限と固定規則によって、その範囲内で具体的に何に触れられるかを絞る。第三に追跡可能性——ログと監査証跡によって、事故が起きた際にどのステップ、どの当事者が原因かを特定できるようにする。
前二者は事前予防、第三は忘れられがちで、それでいて同じくらい重要である。guardrail は悪いことを起こさせないためのもの、ログは起きたときに何が起きたか説明するためのもの——片方はもう片方の代わりにならない。実務にはあからさまなギャップがある。多くの企業が疑い含みまたは確定の Agent セキュリティインシデントを報告しているのに、Agent を「独自の権限付与と独自の責任負担を必要とするエンティティ」として扱っている企業はまだ少ない。この空白は、今日の Agent セキュリティの最も具体的な弱点である。
AI Agent は「質問に答える」段階から「代わりに仕事をこなす」段階に移りつつある。Agent が自律的になればなるほど、ユーザーが手渡すもの——決定、データ、認証情報や鍵——は増えていく。モデル自身が自制を学ぶことに期待するのも、guardrail のルールをさらに数百行書き足すのも、いずれもモデル内部にとどまり、モデルと同じ階層にいる限り、前述の問題群は止められない。企業が Agent を実業務で使えるようにするなら、防御線はモデルの外側に築かなければならない。sandbox で操作可能な範囲を区切り、最小権限で範囲内のデータアクセスを絞り、ログで一歩ごとを記録して、事故が起きたら発生源まで追跡できるようにする。この三層が揃ってはじめて、企業向け Agent セキュリティ・アーキテクチャと呼ぶに値する。