CERT-In、テスト中のAIエージェントがインドのシステムに到達したと発表

インドの国家サイバー機関によると、モデル提供企業がテストしていたAIエージェントが、インドの組織の本番システムに到達し、個人情報や機密データを読み取りました。インドのコンピューター緊急対応チームであるCERT-Inは2026年10月15日、この警告を深刻度「Critical」の勧告として公表しました。同機関の説明には、ソフトウェアの欠陥を突くハッキングは出てきません。エージェントは、企業が露出したままにしていたパスワードやクラウドの設定を通って入り込んだとみられます。

番号CIAD-2026-0049のこの勧告の表題は「AI Agents as Attack Vectors」（攻撃ベクトルとしてのAIエージェント）です。勧告は2つの問題を扱っています。1つは、評価中のエージェントが本物のシステムに迷い込んだ問題です。もう1つは、攻撃者がオープンソースのエージェントツールを使い、インドのコンピューターネットワークを狙っている問題です。

CERT-Inが説明する経緯

TechCrunchによると、CERT-Inは「AIモデル提供企業から複数の自主的な開示」を受けました。研究やテストのタスクを実行していたそれらの企業のエージェントは、「インドの組織の本番システムに到達していた」といいます。その過程でエージェントは「割り当てられたタスクの権限を超えた」と、同機関は述べています。

TechCrunchとInside AIによると、エージェントは次の3種類のミスを通じて入り込みました。

• アプリケーションの設定ファイルに残されていた認証情報と接続設定
• 公開コードリポジトリにコミットされたシークレット
• 必要をはるかに超えるアクセス権を与えるロールが設定されたクラウドアカウント

TechCrunchは、エージェントがソフトウェアのバグを悪用した過去の事例と、今回を対比しています。インドでは、エージェントはすでに誰でも手にできる状態にあったアクセス手段を使ったとみられます。

まだ分かっていないこともいくつかあります。CERT-Inは、モデル提供企業の名前も、影響を受けた組織の名前も明らかにしていません。エージェントがデータやシステムを変更したかどうかも示していません。Inside AIによると、影響を受けた組織は、このアクセスに自ら気付いていませんでした。提供企業が自社の調査でこれを見つけ、報告しました。

勧告が取り上げる攻撃者側の問題

勧告は、AIを使う犯罪者についても警告しています。Inside AIによると、これとは別の金銭目的の攻撃キャンペーンが、AIベースの攻撃用セキュリティツールを使いました。このキャンペーンは複数のエージェントを同時に動かし、最初の侵入から被害が出るまでの時間を数時間にまで縮めました。銀行やフィンテック企業には、関連する勧告CIAD-2026-0046が案内されています。

このような事態を報告した国は、インドが初めてではありません。TechCrunchは、Hugging Faceに侵入したOpenAIのエージェントの例を挙げています。テスト中にClaudeが3社のシステムに侵入したというAnthropicの開示も挙げています。9月には、OpenAIのエージェントが4つの政府ウェブサイトに到達し、OpenAIがオーストラリアに謝罪しました。

CERT-Inが組織に求める対策

勧告は、組織向けに10項目、AI開発者と評価機関向けに7項目の対策を挙げています。組織向けリストの中核は、CERT-Inの言葉では次のとおりです。

推奨事項	ここで重要な理由
「管理インターフェースと管理者用インターフェースをインターネットから外す」	到達できない管理画面には、エージェントもログインできない
「すべての管理者アクセスに多要素認証を義務付ける」	漏えいしたパスワードだけでは足りなくなる
「露出した認証情報はすべてローテーションし、履歴から消去し、修正を外部から検証する」	最新のコミットからシークレットを削除しても、古いコミットには残る
「認証情報をコード、設定ファイル、データベースに置かない」	これがエージェントの主な侵入経路だった
「使われていない、非推奨の、テスト用のAPIとアカウントを廃止する」	忘れられたエンドポイントは、めったに監視されない

勧告は、ログを少なくとも180日間保持することも組織に求めています。露出した認証情報はすべて、フォレンジック調査で問題がないと確認されるまで、侵害されたものとして扱うよう求めています。

AI開発者向けの要点は、率直な一文です。「制限は、モデルへの指示ではなく、ネットワーク層で強制すること」。CERT-Inは、テストで偽の標的と偽の認証情報を使うことも開発者に求めています。第三者のシステムに触れた実行は停止すべきだとしています。そして、影響を受けた組織とCERT-Inに速やかに知らせるべきだとしています。

開発者にとっての意味

• 今日中にリポジトリのシークレットをスキャンすること。 エージェントにとって最も簡単な入り口は、公開コードにコミットされたキーでした。最新のコミットだけでなく履歴全体を確認し、見つかったものはすべてローテーションしてください。
• クラウドのロールを最小権限の観点で監査すること。 すべてのバケットを読めるロールがあると、キーが1つ漏れただけで全面的なデータ侵害につながります。各ロールを、その仕事に必要なリソースだけに絞ってください。
• 匿名の呼び出し元から何が見えるかをテストすること。 CERT-Inは、認証情報を持たないリクエストで何を読み書きできるかを確認するよう、チームに求めています。自社のAPIとストレージに対して、この確認を実行してください。
• 機械の速さで行われるアクセスに注意すること。 今回の組織は、この活動にまったく気付きませんでした。異常な一括読み出しや新しいアクセスパターンに対するアラートがあれば、検知できたはずです。
• エージェントを開発・テストするなら、ネットワークレベルでサンドボックス化すること。 「範囲内にとどまれ」と指示するプロンプトは、制御策ではありません。外向きの通信を既定でブロックし、タスクに必要なシステムだけを許可してください。