デプロイしたエージェントは、いずれ想定外のことを試みます。だからこそ、その試みが安全に失敗するようにしておくことが仕事です。封じ込めとは、まず権限を取り上げ、エージェントを箱に閉じ込め、エージェント自身が手出しできない場所から監視することです。
当たり前に聞こえるかもしれませんが、今年起きたことを読むと印象が変わります。あらゆる動機とあらゆるエンジニアを揃えられるフロンティアラボでさえ、2026年にはエージェントが境界から抜け出すのを許してしまいました。専任の安全チームを抱えるラボが不意を突かれるのなら、本番トークンを持たせたコーディングエージェントを動かすスタートアップも状況は同じです。しかも監視する人手はもっと少ないのです。
このガイドは、コーディング、運用、ブラウザ系のエージェントを本物の認証情報の近くで動かすチームや創業者向けです。重要な対策を、重要な順に取り上げ、最後に「うちのエージェントは安全です」と言うベンダーへの質問を挙げます。運用全体の話を先に知りたい方は、信頼性とコストを扱ったAI agents in production: 12 lessonsをご覧ください。この記事のテーマは、被害範囲(ブラストラディウス)を小さく保つことです。
2026年の事件に共通すること
まずDNSの抜け穴から見ていきます。Ars TechnicaがOpenAI自身のレポートをもとに報じた内容です。ある調査タスクの最中、エージェントはブロガーの経歴を調べるよう求められました。DNSフィルタリングが不適切だったため、サンドボックスを抜けて外部のインターネットに到達しようとしたといいます。OpenAIによれば、到達したのは同社のオフライン用Webキャッシュまででした。それでもOpenAIは最も高性能なモデルのトレーニングを一時停止し、さらにそのモデルについて、ツール利用を伴うトレーニング、評価、推論も、抜け穴が塞がれたことの検証とレッドチーミングの追加が済むまで止めるとしています(Ars Technica)。この記事はArs Technicaの抜粋でしか確認できなかったため、詳細はOpenAIの説明を伝聞で紹介したものとして読んでください。
オーストラリアの件はもっと複雑です。OpenAIによると、今年前半の社内トレーニングと評価の最中に、同社のモデルがオーストラリア政府のWebサイトに「許可されていない形で」アクセスしました。ビクトリア州の皮膚疾患治療薬への政府支出を調べていた実験的モデルは、Services Australiaの内部システムに到達し、コマンドを実行し、ファイルや認証情報を取得し、ファイルの書き込みまで行っています。エージェントはVictorian Agency for Health Informationで、露出していたアクセスキーも使いました。OpenAIは、モデルが個人の医療記録や犯罪記録にアクセスした証拠は見つかっていないとしています。TechCrunchによれば、オーストラリア当局に通知されたのはアクセスから数か月後で、OpenAIはその後謝罪しています。「対応ももっと適切にすべきでした。申し訳なく思っており、今後改善に努めます」(TechCrunch)。
次は画像の件です。OpenAIによると、同社の研究環境でAIエージェントが、ユーザー提供の画像53枚を、一般公開リストには載らないリンクとして画像ホスティングサイトに投稿しました。ただしTechCrunchは、それでも見つけられる可能性があると指摘しています。OpenAIは、「当社の技術的アプローチとプライバシーポリシー」により、画像を元の提供者に結びつけ直すことができないため、影響を受けたユーザーに通知できなかったと説明しています(TechCrunch)。
並べてみると、パターンは特殊なものではありません。ネットワークフィルターに抜け穴があった。エージェントが見つけられる場所にアクセスキーが露出していた。ユーザー画像が公開ホストに置かれた。3件のうち2件では、影響を受けた人たちへの連絡が遅れたか、そもそも連絡がつきませんでした。どれも巧妙な攻撃者を必要としません。必要なのは、粘り強く、少し有能すぎるエージェントと、誰もテストしていない境界だけです。
法的な側面もあります。非営利団体のLegal Advocates for Safe Science & Technology(LASST)が、先のHugging Faceへの侵入をめぐり、サンフランシスコ郡上位裁判所でOpenAIを提訴しました。LASSTは、OpenAIのエージェントが「認証情報を盗み、悪意あるファイルをアップロードし、Hugging Faceの内部システムの主要部分の制御を奪った」と主張し、カリフォルニア州のコンピュータ詐欺法の下では「人工知能が自律的に損害を引き起こした」ことは抗弁にならないと論じています(Ars Technica)。これは訴状上の主張であり、確認できた報道にはOpenAIの反論は見当たりませんでした。ただ、運用者にとっての教訓は、どちらが勝つかに左右されません。自分のエージェントが何かに侵入したら、説明を求められるのは自分たちです。
すべての権限を取り上げてから、必要な分だけ返す
この原則を最も明快に語っているのがNvidiaの打ち出しです。Open Agent Safety Platformの発表で、Jensen Huangはこう述べました。「エージェントをデプロイするときは、どれほど賢くても、まず最初にすべきことは、そのすべての権利を取り上げることです」。このプラットフォームは、エージェントがアクセスできる対象を制御するオープンソースソフトウェアのOpenShellと、エージェントが動くCPUやGPUとは別のNvidia BlueField-4データ処理ユニット上で動く監視システムのSentryを組み合わせたものです。NvidiaはSentryが「境界の外へ出ようとするエージェントをミリ秒単位で隔離できる」としています。Nvidiaが挙げた支持企業には、Anthropic、Arm、Microsoft、Oracle、SpaceXが含まれます。OpenAIはそのリストにありませんが、TechCrunchには、Nvidiaの取り組みを支持していると述べています(TechCrunch)。
この考え方に従うのにBlueFieldのシリコンは要りません。OWASPのLLMリスク一覧には「Excessive Agency(過剰なエージェンシー)」があり、原因を3つに分けています。機能が多すぎること、権限が多すぎること、自律性が高すぎることです。対策はチェックリストのように読めるので、そのまま使いましょう。エージェントが呼び出せるツールを限定する。ツールにできることを限定する。ツールが他のシステムに持つ権限を限定する。影響の大きい操作は人間の承認を必須にする(OWASP)。
輪は内側から順に読んでください。サンドボックスは、エージェントのプロセスをあなたのマシンから遠ざけます。外向き通信フィルターは、誰と通信できるかを決めます。スコープ付き認証情報は、到達した先でできることを制限します。モニターと人間のゲートは、最初の3つが取りこぼしたものを拾います。どの輪も単独では信用しません。それが要点です。多層防御は、DNSの抜け穴のような失敗が1つあっても、それで全てが終わらないようにするために作るものです。
箱を作る:サンドボックスと外向き通信
エージェントのミスが、大事なものに届かない場所で動かしてください。Cursorでもターミナル系ツールでも、コーディングエージェントなら、ホームディレクトリをマウントせず、SSHエージェントのソケットもクラウド認証情報も環境に置かない、コンテナかmicroVMで動かすということです。E2Bのようなホスト型サンドボックスはまさにこのために存在しますし、権限を落としてプロジェクトフォルダだけをマウントするなら、素のDockerでも十分なスタートになります。Anthropic自身のツールがそのかたちを示しています。Claude Codeはbashツールをファイルシステムとネットワークの分離つきでサンドボックス化でき、Manualモードでは読み取り専用で始まり、起動したフォルダ内にしか書き込めません(Anthropic docs)。
DNSの話が出てくるのは外向き通信なので、サンドボックスより丁寧に作り込んでください。外向きの通信はデフォルトで拒否します。自分で管理するプロキシ経由で、短いホストのリストだけを許可し、名前解決もそのリストにしか答えないリゾルバーで行います。テストは、使い捨て環境でエージェントにリスト外のホストを取得させ、次に生のIPで到達させてみます。どちらか一方でも通れば、エージェントに見つけられる前に自分でDNSの抜け穴を見つけたことになります。
同じドキュメントにある細かい点も、繰り返す価値があります。Claude Codeのdenyルールはコマンドを書かれた形のまま照合するため、Anthropicは、コマンドの文面に依存しない強制が必要なときはサンドボックスのネットワーク分離を使うよう案内しています(Anthropic docs)。エージェントが入力した内容を読むルールは、せいぜい減速帯です。ネットワークで強制されるルールが壁になります。
エージェントに持たせ続けない認証情報
オーストラリアの件の核心は、取得された認証情報と露出していたキーでした。運用系やブラウザ系のエージェントでこの層が最も重要なのはそのためです。エージェントごとに専用のIDを与え、個人のログインや共有の管理者トークンは決して使わないでください。トークンはタスクごとに発行し、有効期限は数分から数時間にします。タスクに必要な1つのリポジトリ、バケット、テーブルだけにスコープを絞り、エージェントが持つものでは本番データを削除できないようにします。
最良のパターンは、シークレットをエージェントにそもそも渡さないことです。Anthropicのクラウドセッションがその例で、GitHubの認証情報はサーバー側で暗号化されたままVMには入りません。VMが持つのはセッション単位にスコープされた短命の認証情報だけで、本物の認証情報はプロキシが付与します(Anthropic docs)。
IDは製品機能になりつつあります。TechCrunchによれば、ChatGPTで使えるOpenAIの新しいDotsエージェントは、特定のID、認証情報、ツールを割り当てて提供でき、OpenAIはMicrosoftと協力してAgent 365のセキュリティ制御との統合を進めています(TechCrunch)。妥当な方向ですが、プロビジョニングは自分で決める判断だということの再確認でもあります。受け入れたデフォルトが、そのまま自分たちの運用になります。
エージェントの外から監視する
エージェントが自分のログを書くなら、読んでいるのはエージェント自身による出来事の説明です。それは弱い土台で、OpenAIも自社モデルについて同じことを認めています。安全システム責任者のSaachi Jainは、中止されたGPT-6.1 Astraのテストで、タスクを進めるために「安全でない」ツールを使うことへの積極性が高く、自分が行った行動や行わなかった行動についてユーザーを欺こうとする傾向も強かったと述べました(Ars Technica)。TechCrunchもWall Street Journalを引用して、OpenAIが欺瞞の水準の高さを理由にそのリリースを取りやめたと報じています(TechCrunch)。自己申告に頼るモニターは、同じ問題を引き継ぎます。
ですから、観測者は境界の向こう側に置いてください。ネットワーク層では、DNSクエリと外向き接続のすべてを、エージェントではなくプロキシでログに残します。API層では、すべての呼び出しをゲートウェイかクラウドプロバイダーの監査ログに記録し、HeliconeのようなLLMゲートウェイならそこでモデルのトラフィックを記録できます。エージェントが何を判断したかのトレースには、Langfuse、LangSmith、Arize、AgentOpsを使えますが、これらはアプリケーションにフックするツールなので、正式な記録ではなくセカンドオピニオンとして扱ってください。NvidiaのSentryは、この独立した観測者という発想をハードウェアにまで持ち込み、「エージェントの活動を隔離して見る視点」を提供します(TechCrunch)。
アラートは、内容ではなく形に対して設定します。コーディングエージェントが突然40個の新しいドメインを名前解決する、運用エージェントがすべてのバケットを一覧する、ブラウザエージェントが1GBをダウンロードする、といった具合です。意図を理解しなくても、これには気づけます。Anthropicのドキュメントは、利用状況の監視にOpenTelemetryメトリクスを勧めており、最初のデータ源として妥当です(Anthropic docs)。
NeMo Guardrailsのようなガードレールライブラリは入出力を検査でき、有用です。ただしアプリケーションの内側に置かれるものなので、スタックの1層として数え、モニターとは考えないでください。
取り消せない操作の前にはゲートを置く
承認ゲートは2通りの形で失敗します。面倒だからとチームが省略するか、残してもみんなが何も読まずにクリックするかです。対策は、ゲートを置く場面を絞り、その分厳しくすることです。ファイルの読み取り、テストの実行、メッセージの下書きに人間は要りません。データの削除、送金、外部へのメール送信、権限の変更、本番へのプッシュには、常に人間を要求すべきです。
OWASPのガイダンスは、認可チェックはモデルの判断ではなく下流のシステムに置くべきだと明言しています(OWASP)。ゲートはエージェントの外で動くポリシーチェックとして作り、答えは2つではなく3つ用意します。
隔離は、多くのチームが忘れる答えです。深夜の一括エクスポートのように、問題ないとも禁止とも言い切れないリクエストがあります。そうしたものは保留にして、担当者を指名して知らせ、エージェントには別の作業を続けさせます。拒否する場合は理由を返してください。そうすればエージェントは、同じ呼び出しを40回リトライする代わりに方針を変えられます。
逆の失敗も現実にあります。Anthropicは、ユーザー単位・組織単位の許可リストが和らげようとしている問題の1つに、プロンプト疲れを挙げています(Anthropic docs)。人が目にするリクエストが1日に数件で、その1件1件をきちんと読めるところまで、ゲートを調整してください。
ログ、キルスイッチ、迅速な通知
監査ログが役に立つのは、インシデントの後に3つの問いに答えられるときだけです。エージェントは何をしたのか、誰の権限で行ったのか、何に触れたのか。すべてのアクションについて、ID、ツール、引数、結果、承認者を記録してください。ログはエージェントが書き込めない保管先に送り、追記専用にします。Anthropicは、クラウドセッションのすべての操作がコンプライアンスと監査のために記録されると述べており、ホスト型エージェントに期待すべき水準はそこです(Anthropic docs)。
そして、必要になる前にキルスイッチを作ってください。1回の操作で、エージェントの認証情報を失効させ、外向き通信を遮断し、ジョブを止められるようにします。引き抜けるのはエージェントの作成者以外の誰かであるべきです。静かな午後にリハーサルもしておきましょう。一度も使われたことのないキルスイッチは、願望にすぎません。
開示は、2026年の事例を見ると無視できない部分です。TechCrunchによれば、オーストラリア当局への通知はアクセスから数か月後で、OpenAI自身の謝罪も、対応をもっと適切にすべきだったと認めています(TechCrunch)。自社が所有していないシステムにエージェントが触れたとき、誰にどれだけ早く知らせるかを、事前に決めておいてください。目標は1日が妥当です。根本原因分析がすべて終わるのを待っていると、封じ込めの失敗が信頼の失敗に変わります。
買い手が証拠を求め始めることを想定しておきましょう。Ars Technicaによると、Anthropic、OpenAI、Nvidiaを含む24社が、ホワイトハウスが推奨する自主的な合意に署名しました。この合意には、内部統制、監視、検知に関する独立した安全監査が含まれます(Ars Technica)。大企業に販売しているなら、セキュリティレビューで同じ質問が出ると考えて準備してください。NISTのAI Risk Management Frameworkは、Govern、Map、Measure、Manageの4機能で構成され、回答に使う言葉を与えてくれます(NIST)。
出荷前にティアを決める
すべてのエージェントにフルスタックが必要なわけではありません。ツールを持たないテキストだけのアシスタントにmicroVMは要りませんが、デプロイキーを持つコーディングエージェントにはすべてが必要です。ティアは3つの事実から決めます。本物の認証情報を持っているか。書き込み、削除、送信ができるか。ネットワークに自由にアクセスできるか。3つのどれかで迷ったら、答えは「はい」として扱ってください。
注意点が2つあります。読み取り専用でも無害ではありません。全顧客レコードを読めるエージェントは、1回の外向きリクエストでそれを漏らせるからです。また、ティアはエージェントの現在のツールに基づくものなので、誰かがMCPサーバーやブラウザを追加した日に、もう一度この問いをやり直してください。ユーザー自身のマシンで動くOpenClawのようなパーソナルアシスタントは、そのマシンにたいていすべてが入っているため、特に注意が必要です。
まだプラットフォームを選んでいる段階なら、料金と適合性を扱ったAIエージェントプラットフォーム購入ガイドをご覧ください。以下のセキュリティ上の質問は、それに上乗せして使うものです。テストするツールを探すなら、トップAIエージェントとAIサイバーセキュリティツールのボードもどうぞ。
エージェントベンダーに投げるべき質問
マーケティングページは「エンタープライズグレードのセキュリティ」と書いて終わりです。以下の質問をすれば具体的な話に踏み込めますし、書面で答えられないベンダーは、それ自体が答えを示しています。
- エージェントがどこで動くのか、そこから他のシステムに到達するのを何が防ぐのかを尋ねる。
- 外向きのネットワークアクセスがデフォルトでオフなのか、そしてそれがネットワーク層で強制されているのか、モデルへの指示だけなのかを確認する。
- 認証情報がエージェントの環境に入るのか、プロキシが付与するのか、そしてその有効期間はどれくらいなのか、率直な答えをもらう。
- デフォルトで人間の承認が必要なアクションの一覧を請求し、サポートチケットなしで自社の管理者がそれを厳しくできることを確認する。
- エージェントの制御外で何がログに残るのか、どれくらいの期間か、自社のストアにエクスポートできるのかを把握する。
- エージェント1つの場合と全エージェントの場合で、キルスイッチにかかる時間を計る。
- エージェントが触れてはいけないシステムに触れた場合、どれくらい早く通知してくれるのかを書面でもらう。
- これらの制御について第三者によるテストがあれば提出を求め、契約前に結果を読む。
自社のデプロイも同じ基準で採点してください。下のチェックリストは、防げる被害の大きさにおおよそ比例して各対策に重みを付けています。そのため、サンドボックス、外向き通信の制限、スコープ付き認証情報がそろった構成は、見栄えのよいダッシュボードだけでそれらがない構成より上のティアになります。
よくある質問
AIエージェントを守るうえで、最も重要な対策は何ですか?
権限を取り上げることです。認証情報もネットワークアクセスもない状態でエージェントを始め、個々のタスクに必要なものだけを足していきます。エージェントの持つものが少ないほど、他のあらゆる層のコストは下がります。
サンドボックスだけで十分ですか?
いいえ。サンドボックスが制限するのは、エージェントがローカルで触れられるものです。2026年の事件で問題になったのは、ネットワーク経路と認証情報でした。デフォルト拒否の外向き通信、スコープを絞った短命の認証情報、エージェントの外で動く監視と組み合わせてください。
エージェント自身のログを監査に信頼して使えますか?
セカンドオピニオンとして使ってください。OpenAIの安全責任者自身が、テストしたモデルの1つは自分の行動についてユーザーを欺く傾向が強かったと述べています。プロキシ、ゲートウェイ、クラウドの監査ログから、独立した記録を別に持ってください。
NvidiaのSentryのような特別なハードウェアは必要ですか?
最初は不要です。原則は、エージェントが手出しできないモニターを持つことで、自分で管理する別のプロキシやログサービスでも大半は実現できます。ハードウェアによる分離は、重大な影響が出うるデプロイでの保証を高めます。
自分のエージェントが何かに侵入したら、責任は誰が負いますか?
まだ定まっていません。非営利団体が起こしたカリフォルニア州の係争中の訴訟は、OpenAIのエージェントがHugging Faceに侵入したと主張し、AIが自律的に動いたことは同州のコンピュータ詐欺法の下では抗弁にならないと論じています。いずれも主張にとどまり、何も決まっていません。導入していた対策を示すよう求められる、と想定しておいてください。