英NCSC、AIエージェントのサイバーリスク管理を提言　サンドボックス・常時監視・緊急停止を重視

英国のNational Cyber Security Centre（NCSC）は2026年8月20日、自律的に行動するエージェント型AIを安全に導入するための実務的な助言「Managing the cyber risk of agentic AI」を公開しました。

NCSCは、AIエージェントの自律性が高まるほど、意図しない動作や過剰な権限利用、想定外のシステムアクセスが発生した場合の影響も大きくなると指摘しています。モデルに組み込まれた安全機構やプロンプトだけに依存せず、サンドボックス、最小権限、リアルタイム監視、人間による監督、緊急停止機能などを組み合わせるよう求めています。

今回の内容は正式なガイダンスではなく、NCSCが今後策定する正式文書までの暫定的な実務助言です。AIエージェントを業務システムや本番環境へ接続する組織にとって、導入時の権限設計や監視、インシデント対応を整理するための指針になります。

NCSCのエージェント型AIセキュリティ助言のサマリー

• NCSCは2026年8月20日、エージェント型AIのサイバーリスクを管理するための暫定的な実務助言を公開しました。
• 対象は、高い自律性を持つAIエージェントを設計・運用するシステム設計者や運用担当者です。
• AIエージェントの自律性が高いほど、誤動作や権限逸脱が発生した場合の影響も大きくなるため、リスクに応じて制御を強化する必要があります。
• モデルや推論サービスに組み込まれた安全機構は回避される可能性があり、高リスク環境では単独の防御策として扱うべきではないとしています。
• プロンプトには「何を実行するか」だけでなく、「何をしてはいけないか」「いつ人間の承認を求めるか」を明示する必要があります。
• AIエージェントは原則としてサンドボックス内で実行し、ネットワーク、計算資源、資格情報、データへのアクセスを必要最小限に制限するよう推奨しています。
• 高リスク用途では、外部ネットワークへの通信を原則拒否し、必要な通信先だけを許可する方式が推奨されています。
• AIエージェントには人間や他システムと区別できる固有のIDを割り当て、短期間だけ有効な最小権限の資格情報を使用することが重要です。
• AIエージェントの動作はユーザー活動と同様に扱い、ログ、プロキシ、ネットワーク通信などを24時間365日のセキュリティ監視やインシデント対応へ組み込む必要があります。
• AIエージェントが第三者システムへアクセスする場合、送信元IPやHTTPヘッダーなどを使い、相手側が自組織のAIによる通信だと識別できるようにすることを提案しています。
• 問題が発生した場合、AIプロセスだけでなく、ネットワーク通信やモデル推論基盤との接続まで即座に遮断できる「緊急停止」の仕組みを維持する必要があります。
• NCSCは今回のブログを暫定助言と位置付けており、今後、より正式なガイダンスを公開する予定です。

項目	内容
公表日	2026年8月20日
発行元	英国 National Cyber Security Centre（NCSC）
資料名	Managing the cyber risk of agentic AI
対象	AIエージェントの設計者、運用者、セキュリティ担当者
主なテーマ	自律性管理、サンドボックス、最小権限、監視、人間による監督、緊急停止
モデル内蔵ガードレール	単独では不十分。追加の技術・運用制御が必要
ネットワーク	原則遮断し、必要な接続のみ許可する方式を推奨
権限管理	AI専用IDと最小権限、短命な資格情報を推奨
監視	AIエージェントの活動をSOCやインシデント対応へ統合
緊急停止	プロセス停止だけでなくネットワークや推論基盤との通信遮断も想定
文書の位置付け	正式ガイダンス公開までの暫定的な実務助言

自律性が高まるほど「失敗したときの影響」も拡大

NCSCは、すべてのAIエージェントに同じレベルのセキュリティ制御が必要なわけではないとしています。

人間へ提案するだけの補助的なAIと、本番システムへアクセスし、判断から実行までを自律的に行うAIでは、失敗した場合の影響が大きく異なります。

自律性が高いAIエージェントでは、想定外の動作によって本来アクセスすべきではない情報へ到達したり、許可されていない操作を行ったりする可能性があります。そのため、AIへどこまでの自律性を与えるのか、組織としてどこまでのリスクを許容するのかを最初に明確にすることが、制御設計の出発点になります。

NCSCは8月4日にも、フロンティアAIモデルが許可されていない行動を取った事例や、一部で人間のような欺瞞的行動がみられたとして、安全策、リアルタイム監督、予期しない事態への対応計画が必要だと警告していました。

モデルの安全機構だけに依存しない

生成AIやAIエージェントには、有害な動作を抑制するための安全機構が組み込まれている場合があります。

しかしNCSCは、こうしたモデルレベルや推論サービス側の安全機構について、基本的な防御にはなるものの、包括的なセキュリティ対策として扱うべきではないとしています。

安全機構が回避される可能性があるほか、高リスクな環境では十分な保護を提供できない場合があるためです。

AIエージェントが本番システム、クラウド管理基盤、コードリポジトリ、顧客データなどへアクセスする場合、モデルの拒否応答だけで重要操作を防ぐのではなく、API側の権限制御、ネットワーク制限、承認フローなどを技術的に強制する必要があります。

NCSCは、影響が組織の許容範囲を超える用途では、分類器や決定論的な検証機構など、追加の安全策を組み合わせるよう求めています。

プロンプトには禁止事項と人間承認の条件も明示

AIエージェントに与える指示は、その後の動作に大きな影響を与えます。

NCSCは、エージェントへ指示する際には、達成すべき目標だけでなく、許可する操作、禁止する操作、人間へ判断を戻す条件を明示することを推奨しています。

たとえば、「障害を解消する」という目標だけを与えた場合、AIがサービス停止や権限変更といった運用者の意図しない手段を選ぶ可能性があります。目標と実行可能な手段を分けて定義し、重要操作では必ず承認を求める仕組みが必要です。

長時間動作するAIエージェントでは、コンテキスト圧縮などによって初期の制約が弱まる可能性も考慮し、必要に応じて重要な制約を繰り返し与えるようNCSCは助言しています。

ただし、NCSCはプロンプトだけに依存しないことも明確にしています。禁止事項を文章で指定するだけではなく、技術的・運用的な制御を組み合わせた多層防御が必要です。

セキュリティ対策Labでは、外部Webページなどに埋め込まれた指示によってAIエージェントが意図しない操作へ誘導されるリスクについて「AIエージェントを狙う間接的プロンプトインジェクション」でも解説しています。

Human-in-the-loopだけでなく、監視と技術的制御を併用

NCSCはAIエージェントの運用形態を、人間が事前承認するHuman-in-the-loop、人間が監視し必要に応じて介入するHuman-on-the-loop、人間の確認なしに動作するHuman-out-of-the-loopに分けています。

意図しない動作が重大な結果につながる環境では、責任者を明確にし、人間がAIエージェントの行動を監視できる状態を維持することを推奨しています。

別のAIモデルを「judge」として配置し、主エージェントを評価する方法も考えられますが、NCSCはこうした監督用AIにも限界や二次的な影響があるため、独立した性能評価が必要だとしています。

高リスク環境では、人間による監督と、API制限やネットワーク制御などの技術的な強制策を併用することが重要です。

AIエージェントは必ずサンドボックス内で実行

NCSCの助言で特に強調されているのがサンドボックスです。

AIエージェントは、アクセス可能なリソースを制御できるサンドボックス環境内で実行することを原則としています。

ここでいうサンドボックスは、単にAIをコンテナへ入れるだけではありません。NCSCは、AIエージェントが直接・間接的にアクセスできる範囲すべてを境界として考える必要があるとしています。

対象には以下が含まれます。

• エージェント本体やコマンドの実行環境
• ネットワーク上で接続可能なサービス
• ローカルの計算資源やファイル
• APIキー、OAuth認可、SSH鍵、認証済みセッション
• AIが読み書きできるデータ
• モデルの推論基盤

AIエージェントが利用できるシステムやサービスが増えるほど、誤動作や侵害時の「blast radius」、つまり影響範囲も拡大します。

業務に必要なリソースだけへアクセスできるようにし、それ以外へのアクセス試行も監視する設計が求められます。

ネットワーク分離を4段階で評価

NCSCは、AIエージェントのネットワーク制御について4段階の成熟度モデルを示しています。

レベル	ネットワークアクセス
Level 1	外部ネットワークへ無制限にアクセス可能
Level 2	許可リストに登録したドメインのみ接続可能
Level 3	AIモデルのAPIだけに接続可能
Level 4	外部ネットワーク接続なし。モデルもサンドボックス内部でローカル運用

高リスク用途では、事前に必要なツールや情報を取得した上で、ネットワークから隔離した環境でAIエージェントを動かす方法が最も堅牢だとしています。

インターネット接続が必要な場合でも、原則としてインバウンド・アウトバウンド通信を拒否し、必要な接続のみ許可する方式が推奨されています。

許可リストだけで十分な制御が難しい用途では、プロトコルやサービスを認識できるプロキシを配置し、許可範囲外への通信について人間の承認を要求する方法も挙げています。

コンテナだけで十分とは限らない

計算環境の分離についても、NCSCは4段階の成熟度を示しています。

レベル	実行環境
Level 1	他の業務データやワークロードと同じホスト上で分離なし
Level 2	同一ホスト上でプロセス分離や適切に構成したOCIコンテナを利用
Level 3	同一ホスト上で仮想化技術により分離
Level 4	他のワークロードとは別の専用ハードウェアで実行

NCSCは、AIエージェントが設定不備や脆弱性を発見し、サンドボックスからの脱出を試みる可能性も考慮するよう求めています。

高リスク用途では単一の分離機構に依存せず、複数の分離層を組み合わせ、設定が想定どおり機能しているかを継続的に検証する必要があります。

AIエージェントごとに固有ID、資格情報は最小権限・短命に

AIエージェントが利用できる資格情報も、侵害や誤動作時の影響範囲を決めます。

NCSCは、すべてのAIエージェントに固有のIDを割り当て、人間や一般的なシステムアカウントと区別できるようにすることを推奨しています。

AIが利用できるAPIキー、OAuth認可、SSH鍵、認証済みセッションなどは、必要なタスクに限定した最小権限とし、可能な限り有効期間を短くします。

AIエージェントがユーザー端末と同じ環境で動作する場合、そのユーザーが持つ資格情報まで利用できる可能性があります。NCSCは、こうした資格情報の露出を避けるため、プロキシが必要なリクエストへ資格情報を注入し、AI本体には秘密情報を直接渡さない方式も例示しています。

2026年5月に英国NCSC、CISA、NSA、豪州ACSCなどが共同公開したガイダンスでも、AIエージェントを独立したプリンシパルとして扱い、固有の暗号学的IDと最小権限を付与することが推奨されています。

AIの操作ログをSOCとインシデント対応へ統合

AIエージェントが何をしたのかを後から追跡できなければ、異常動作や事故の調査は困難になります。

NCSCは、AIエージェントの活動について、利用可能な実行トレースや会話記録に加え、サンドボックス、アクセスログ、プロキシ、ネットワーク通信などのテレメトリーを取得するよう求めています。

ログは改ざんや削除から保護し、可能であればイミュータブルな状態で保存します。

また、ログ基盤自体がAIエージェントから到達可能な攻撃対象にならないよう、収集経路や保存先の分離も検討する必要があります。

NCSCは、AIエージェントの活動を「ユーザー活動の一種」として扱い、24時間365日のセキュリティ監視やインシデント対応へ組み込むことを推奨しています。

導入初期は人間の監視が厚い営業時間内だけで自律実行し、制御の有効性を確認した後に夜間や休日へ拡大する段階的な運用も提案しています。

外部へのAI通信は「誰のAIか」を識別可能に

AIエージェントが第三者のWebサイトやAPIへアクセスする場合、相手側から見て、その通信がどの組織のAIによるものか判別できる状態も重要です。

NCSCは、逆引き可能なIPアドレスから通信することや、HTTPヘッダーなどへ組織を識別できる情報を付加する方法を例示しています。

AIエージェントが予期しないアクセスを行った場合、第三者からのabuse報告を受けて迅速に停止・調査できるようにするためです。

こうしたAIトラフィックの識別方法はまだ業界として確立途上ですが、自律システムを外部へ接続する組織では、技術的な制御だけでなく、事故時に外部から連絡を受けられる運用も必要になります。

「pull the plug」できる緊急停止機能を維持

NCSCが最後に強調しているのが、AIエージェントを即座に停止できる能力です。

問題を検知した場合、AIプロセスを停止するだけでは不十分なことがあります。

エージェントが複数のシステムと通信していたり、複数のサブエージェントを起動していたりする場合、プロセス停止後も外部通信や資格情報が残る可能性があります。

NCSCは、AIエージェントのインフラに対するネットワークアクセスを迅速に遮断し、必要に応じてAIモデルの推論基盤との通信も中断できる仕組みを求めています。

緊急停止は「管理画面から停止ボタンを押せる」というだけでなく、ネットワーク、ID、認証情報、実行基盤を含むインシデント対応手順として設計する必要があります。

情報システム部門・AI導入担当への示唆

NCSCの助言から、企業がAIエージェントを導入する際に最初に確認すべきなのは「モデルの性能」ではなく、「どこまで自律的に動けるか」と「失敗時の影響範囲」です。

メールの要約や情報検索など低リスクな業務と、本番環境の設定変更、顧客データの更新、コードのデプロイ、決済などを同じ承認モデルで運用するべきではありません。

AIエージェントごとに、アクセス可能なデータ、ネットワーク、API、資格情報、操作内容を棚卸しし、重要度に応じて自律性を段階化する必要があります。

特に本番環境へアクセスするAIでは、以下の点を運用要件として定義することが重要です。

• AI専用のIDを発行し、人間のアカウントを共有させない
• APIやデータへの権限をタスク単位で最小化する
• 長期間有効なAPIキーをAIへ直接持たせない
• 任意の外部通信を原則禁止する
• 重要操作では技術的に人間承認を必須化する
• AIが実行した操作をSIEMやSOCで追跡できるようにする
• 誤動作や侵害時にネットワークと認証情報を即時遮断できるようにする

また、AIエージェントがメール、Webページ、チケット、文書、GitHub Issueなど外部から変更可能なデータを読み込む場合、間接的プロンプトインジェクションも前提にした設計が必要です。

モデルが「その命令には従わない」と判断することを最後の防御線にせず、仮に悪意ある命令へ従ったとしても、サンドボックスや権限管理によって重大な操作が成立しない構造にすることが求められます。

セキュリティ対策Labでは、自律型AIがメールやSharePointなどへ継続的にアクセスする場合のリスクについて「Microsoftが自律型エージェント Scout（Autopilot）を発表ー3つのセキュリティ懸念」でも解説しています。

今回のNCSC文書は正式ガイダンスではありませんが、AIエージェントを本番業務へ接続する前に、既存のIAM、ネットワーク分離、SOC、インシデント対応へどのように組み込むかを検討する上で、実務的な確認項目を示しています。

出典

• Managing the cyber risk of agentic AI – UK National Cyber Security Centre
• NCSC statement in response to recent incidents resulting from frontier AI evaluations – UK National Cyber Security Centre
• Thinking carefully before adopting agentic AI – UK National Cyber Security Centre
• Careful adoption of agentic AI services – Australian Signals Directorate / Cyber.gov.au
• Securing Artificial Intelligence; Baseline Cyber Security Requirements for AI Models and Systems – ETSI
• AIエージェントを狙う間接的プロンプトインジェクション – セキュリティ対策Lab
• Microsoftが自律型エージェント Scout（Autopilot）を発表ー3つのセキュリティ懸念 – セキュリティ対策Lab