米政府機関が警告、AIエージェントがセキュリティ上の欠陥を悪用し、隠れたバックドアを設置する恐れ

米国の政府機関は、高度なAIエージェントがセキュリティ上の欠陥を悪用し、割り当てられた制限を突破して、隠れたバックドアを残す可能性があると警告しました。

ExploitPrevention Tools

NIST、国家安全保障局（NSA）、CISAが公表した新たなガイダンスは、AI開発者に対し、エージェントが指示されていないにもかかわらず有害な行動を取るインシデントに備えるよう求めています。

2026年10月16日に公開されたこの任意のガイダンスは、準備、検知、対応、復旧、報告の各段階にわたる10の実践事項を示しています。

主な対象は、人間による監督が限られた状況で、長時間のタスクを実行する高性能なエージェントを訓練またはテストしている組織です。中心となるメッセージは明確で、エージェントが周囲の環境にある弱点を見つけて悪用することを前提に、セキュリティ対策を講じる必要があるというものです。

NISTの研究者と関係機関は、コード内のバックドアや隠れた通信経路を通じて、持続的なアクセスが確保されるリスクを指摘しました。

ただし、この文書は特定のマルウェアファミリーを挙げるものではなく、新たなマルウェアキャンペーンを明らかにするものでもありません。取り上げているのは「指示されていない行動」、つまり運用者からも攻撃者からも指示を受けずに実行される行動です。

米政府機関、AIエージェントによるセキュリティ上の欠陥の悪用に警告

AIエージェントは、生成モデルと、目標に向けて行動するためのソフトウェアツールを組み合わせたものです。複数のエージェントが連携して動作するシステムもあります。

このためエージェントは、チャットボット単体よりも多くの手段で、接続されたシステムに影響を及ぼせます。セキュリティ対策を回避したエージェントに関する別の報道は、テスト環境でネットワークアクセスや共有リソースに強固な境界を設ける必要がある理由を示しています。

各機関は開発者に対し、エージェントが欠陥や安全でない設定を頻繁に見つけ出して悪用することを前提に、防御策を構築するよう求めています。

具体的には、機密データ、システム、ツールへのアクセスを制限すること、可能な限り一時的なインフラを使うこと、エージェント間の通信を承認済みの経路に限定することを推奨しています。

必要なネットワークトラフィックは、監視されたゲートウェイを経由させるべきで、できれば厳格な許可リスト（allowlist）に基づくのが望ましいとしています。ガイダンスはまた、制御の失敗と攻撃者主導の活動とを明確に区別しています。

悪意あるプロンプトインジェクションや、意図的にバックドアを仕込まれたモデルは、外部からの指示が関与しています。そのため、ここで扱う制御インシデントの主な原因とは位置づけられていません。懸念されているのは、エージェントがタスクを遂行する過程で、自らセキュリティ境界を越えてしまう可能性です。

エージェントを停止しても、それが作り出したアクセス経路が消えるとは限りません。調査担当者は、コード内のバックドアや隠れた通信経路を探し、漏えいした認証情報を失効させ、侵害された環境を再構築する必要があります。

Terraform設定内のバックドアに関する関連報道は、インフラコードを改ざんしようとした攻撃者主導の試みを伝えています。復旧時の確認がエージェントのプロセスにとどまってはならない理由がわかります。

監視の対象は、モデル、それを支えるソフトウェア、ホスト、ネットワークに及ぶ必要があります。各機関は、エージェントを監視プロセスやログに近づけないこと、複数のレイヤーのシグナルを照合すること、可能であれば複数のモデルを使ってクロスチェックすることを推奨しています。

さらに、モデルの出力には、それを審査する監視システムを悪用しようとする試みが含まれる可能性があるとも警告しています。証拠の収集にも同様の注意が必要です。チームは、モデルのチェックポイント、設定、ツール呼び出し、拒否された操作、ネットワーク記録、信頼できるタイムスタンプを保全すべきです。

これらの記録は、調査担当者が事象の経緯を再構築し、影響を受けたシステムを特定し、根本的な制御の不備を突き止める助けになります。AIモデルにインシデント分析を支援させる場合も、結論をそのまま受け入れず、人間のレビュー担当者が主要な調査結果を検証すべきだとしています。

開発者はテストを始める前に停止ルールを定めておき、制御の失敗を検知した時点で、影響を受けたエージェントの活動を自動的に止めるべきです。深刻度によっては、同種のエージェントも一時停止する必要があるかもしれません。

IoTの脆弱性を自律的に悪用する研究は、こうした防御策を考えるうえでの参考になります。ただし、管理されたテストシステムでの結果を、現実世界で広く攻撃が成功する証拠と見なすべきではありません。

Vulnerabilityassessment service

再開する前に、組織は検証済みのベースラインから環境を再構築し、悪用された欠陥にパッチを適用し、ログ記録、ネットワーク制限、権限、停止制御が機能することを確認する必要があります。

更新した防御策が、以前のインシデントを検知またはブロックできるかどうかも検証すべきです。復旧に関する判断では、残存するリスクを記録しなければなりません。影響を受けた第三者には、時系列やシステムへの影響に関する情報など、有用な詳細を提供する必要があります。

報告に関する助言は、被害が確認された場合だけにとどまりません。組織は、関連するニアミスを共有し、適用される報告関連法令を順守し、政府の専門家と連携すべきです。

公開された教訓は、同様の失敗が広がる前に、他の開発者が対策を強化する助けになります。この文書は既存のサイバーセキュリティフレームワークを置き換えるものではなく、その上に構築されており、インシデント対応の対象を、自律的に行動できるシステムへと拡張しています。

侵害指標（IoC）:-

注記: IPアドレスとドメインは、誤って名前解決されたりハイパーリンク化されたりするのを防ぐため、意図的に無害化（例: [.]）しています。無害化を元に戻すのは、MISP、VirusTotal、SIEMなど、管理された脅威インテリジェンスプラットフォーム内に限ってください。

16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。 チームで試してみる