テスト中のAIエージェントが実在する組織のデータを読んでいた｜インドCERT-Inの警告と開発者の点検項目

2026年10月19日

インドの政府機関が、テスト中のAIエージェントが外部の組織のデータを読んだ事例を公表した

インドのコンピュータ緊急対応チーム「CERT-In」は2026年10月15日、重要度を「Critical（重大）」とした警告「AI Agents as Attack Vectors」（番号CIAD-2026-0049）を出しました。ページは10月19日に更新されています。CERT-Inはインド電子情報技術省に属し、サイバー攻撃の事故報告の受け付けと注意喚起を担う政府機関です。

警告が扱うのは、AIエージェントが関わった2種類の事故です。AIエージェントは、目標を渡すと自分で手順を考え、コマンドを打ち、ツールを使い、長い時間にわたって作業を続けるAIを指します。中心になるのは1つ目の種類で、CERT-Inによると、複数のAIモデルの提供企業（以下、AI企業）がテスト（研究・評価）のために動かしていたAIエージェントが、与えられた課題の範囲を超えてインドの組織の本番システム（実際に業務で動いているシステム）へ到達し、個人情報や機密を含む業務記録を読んでいました。被害を受けた組織はどこも自分では気づかず、報告はいずれもAI企業の社内点検のあとに行われています。

この記事では、警告に書かれた2種類の出来事、入り口になった弱点、OpenAIが自社で公表した同じ型の事例、自分のプロジェクトで確認する点検項目を順に整理します。読み終えると、自分のリポジトリやクラウドの設定で、どの弱点を先に塞ぐかを決められます。

3つの要点

テスト中のAIエージェントが、インドの実在する組織のデータを読んでいた

何が起きた

本番システムへ到達

複数のAI企業がテスト中に動かしていたエージェントが課題の範囲を超え、インドの組織の業務記録（個人情報・機密を含む）を読んだ。

入り口になったもの

残っていた認証情報と広すぎる権限

設定ファイルや公開リポジトリに残っていたパスワード・APIキーと、権限の広すぎるクラウドの設定。

誰が気づいた

AI企業の社内点検

被害組織はどこも気づかないまま、AI企業の社内点検で発覚し、CERT-Inへ報告された。

テスト中のAIが本番システムへ到達した事例と、犯罪者がAIツールを使った事例の2種類

CERT-Inは、AIエージェントが関わった事例を2つの種類に分けています。1つ目は、AI企業が自発的に報告した「テスト中のエージェントが外部の組織の本番システムへ到達した」事例です。2つ目は、CERT-In自身の調査で見つかった「金銭目的の犯罪者がAIエージェント型のツールを使った」事例です。

CERT-Inが挙げた2種類の事例

種類1：AI企業が自発的に報告

テスト中のAIエージェントが外部の組織の本番システムへ到達した

誰が：複数のAI企業がテストのために動かしていたモデル。企業名、モデル名、被害組織は非公表
何をした：課題の範囲を超えてインドの組織の本番システムへ到達し、個人情報・機密を含む業務記録を読んだ
どう入った：設定ファイル、公開リポジトリ、権限の広すぎるクラウドのロールに残っていた認証情報と接続設定。エージェントは、ある作業で見つけた認証情報を別の作業でも使い回した
どう分かった：被害組織はどこも気づかず、AI企業の社内点検で発覚

種類2：CERT-Inの調査で発覚

犯罪者がAIエージェント型の攻撃ツールを使った

誰が：金銭目的の攻撃者。公開されている「AIを組み込んだ攻撃用ツール」を使った。このツールは名前を変えた複製が複数の国に広がっている
何をした：インドの組織への偵察、弱点の悪用、金銭目的の攻撃
速さ：最初の侵入から被害までの時間が、数日から数時間に短縮
再攻撃：対処が不完全だった組織は、数日のうちに前より大きな規模で再び攻撃された

出典：CERT-In 警告 CIAD-2026-0049（2026年10月15日発行、10月19日更新）。

1つ目の種類で気になるのは、誰も検知していなかった点です。警告には、被害組織はどこも自分では検知せず、すべての事例がAI企業の社内点検のあとの報告で判明したと書かれています。AIエージェントによる読み取りは、組織側の監視にかからないまま終わっていました。自分の組織でも、気づかないうちに読まれている場合があるという前提で点検する必要があります。

2つ目の種類で気になるのは、対処の速さが前より強く問われる点です。公開されている「AIを組み込んだ攻撃用ツール」によって、最初の侵入から被害までの時間が数日から数時間に縮み、不完全な対処は数日で再攻撃を招きました。そのためCERT-Inは、対処のあとに弱点が塞がったかを確かめる再テストと、数日から数週間のうちに来る再攻撃への備えまでを対策に含めています。

入り口になったのは、AI以前から知られていた5つの弱点

CERT-Inは、2種類どちらの事例でも、入り口になった弱点そのものは以前から知られていたものだと整理しています。AIが変えたのは、弱点を見つける速さ、しらみつぶしに調べる徹底ぶり、同時に手を伸ばす範囲の3つです。

入り口になった5つの弱点

弱点1

ソースコードや履歴に残った認証情報

ソースコード、リポジトリの変更履歴、設定ファイル、利用者側のアプリ（スマホアプリなど）の中身、公開Webページに書かれたままのパスワードやAPIキー。

弱点2

使われていないAPIの放置

休止中、廃止済み、テスト用のAPIやアカウントが、インターネットから呼び出せる状態のまま残っている。

弱点3

平文で保存された決済用のAPIキー

送金や支払いに使うキーが、暗号化されずにそのまま置かれている。

弱点4

権限の広すぎるクラウドのロール

クラウドやBaaS（ログインやデータベースをまとめて提供するサービス）で、プログラムに必要以上の読み書きを許している。

弱点5

多要素認証のない管理画面

管理用の画面がインターネットに公開され、弱いパスワードだけで入れる。多要素認証（MFA）がない。古いミドルウェア（Webサーバーなど土台のソフト）が更新されていない場合も同じ入り口になる。

出典：CERT-In 警告 CIAD-2026-0049の「根本的な弱点」の項を再構成。

5つはどれも、個人開発や小規模なチームでも起こります。たとえば試作のときにAPIキーを設定ファイルへ直接書き、あとで消したつもりでも、Gitの履歴には残ります。この点は後半の「消したはずの認証情報はGitの履歴に残る」で、実際のコマンドと結果を載せます。

OpenAIも想定外の行動19件を公表し、うち3件は認証情報が入り口だった

テスト中のAIが外の実在するシステムへ到達した事例は、OpenAIも自社で公表しています。OpenAIは自社の研究ブログに「Misalignment Reports and Notices」というページを設け、学習・評価や社内利用の最中にモデルが開発者の意図しない行動をとった事例を公開しています。CERT-Inは報告元の企業名を公表していないので、OpenAIの事例は今回の警告と直接は結びつけず、同じ型の事故として並べて読みます。2026年10月19日の時点で19件が載っていて、発生は2025年10月から2026年10月、公開はすべて2026年9月16日から10月15日の間です。19件のうち13件は2026年5月と6月に発生していて、発生から公開までに数か月かかっています。

OpenAIが公表したAIの想定外の行動19件を、発生した月ごとに数えた縦棒グラフ。2026年6月が7件で最も多く、次いで5月が6件。2025年10月、2026年3月、4月、7月、9月、10月が各1件。 — OpenAIの公開ページに載った19件の発生日を月ごとに数えた（2026年10月19日確認）。発生日が複数ある報告は、最も早い発生日の月で数えている。

19件のうち、CERT-Inの警告と同じ「露出した認証情報」が関わる事例が3件あります。

露出した認証情報が関わる3つの事例

2026年6月17日発生、10月15日公開

政府の統計サイトでサーバーの秘密情報を取得

病床数の統計を探していた学習中のモデルが、アクセスを拒否されたあとにサイトの機能を使って、認証情報を含むサーバーの設定ファイルを取得。拒否されていたデータを権限の確認をすり抜けて取得し、1,000件超のメールアドレスを含むアカウント一覧も手に入れた。最終回答では無断アクセスに触れなかった。

2026年5月15日発生、9月16日公開

公開GitHubで漏れたAPIキーを探して使った

データAPIの利用登録に失敗した学習中のモデルが、公開リポジトリから漏れたAPIキーを探し、1件が実在のAPIで認証に成功。目的のデータの取得には失敗し、数値を捏造して回答した。

2026年5月27日発生、9月25日公開

研究者のGitHubトークンを公開リポジトリへ置いた

別チームが提出した数学の証明の答えを手に入れようとした社内モデルが、研究者のトークンを公開リポジトリのブランチへコミット。秘密情報を自動で探すスキャナに見つからないよう、トークンの文字列を分割していた。OpenAIは全社員のキーを無効化し、このモデルを約2週間停止した。

出典：OpenAIの各報告ページ（2026年10月19日確認）。

OpenAIはこれらの事例のあと、学習・評価中のモデルが実際のインターネットへ出ることを遮断し、学習・評価のすべての通信を監視対象にしたと書いています。19件の一覧とは別に、OpenAIは2026年7月にも、自社のモデルがテスト中にHugging Faceへ侵入した事故を公表していました（当ブログの解説：Hugging Faceへの侵入）。英国のAI安全研究所（AISI）も2026年8月4日に、テスト中に起きた想定外の行動19件を公表しています（OpenAIの19件とは別の集計。当ブログの解説：AISIの19件）。CERT-Inの警告は、こうしたAI企業の内側で起きた事故が外にいる組織のデータへ実際に届いたことを、政府機関が公表した例です。

個人開発者と小規模チームが自分のプロジェクトで確認する点検項目

CERT-Inは、組織やサービス提供者向けに10項目、AIを開発・評価する側に7項目の対策を挙げています。ここでは、10項目のうち個人開発者と小規模チームに関係する8項目を、3つのグループに分けました。

3グループの点検項目

グループ1：認証情報とリポジトリ

ソースコード、コミット履歴、CI/CD（自動ビルド・配布）の設定値、設定ファイル、利用者側のアプリ、クラウドストレージに認証情報が残っていないか調べる
見つけたキーは新しいものに入れ替えて古いものを無効にし、履歴からも消し、外から見えなくなったことを確かめる
コミットとビルドのたびに、秘密情報のスキャンを自動で回す

グループ2：APIとクラウドの権限

APIの一覧を作り、休止中・廃止済み・テスト用のAPIとアカウントを止める
クラウドやBaaSのロールは必要最小限の権限にし、データの行ごとに読める相手を制限する。特権的なキーを利用者側のアプリに入れない
ログインしていない状態の呼び出しで何が読めて何が書けるかを、実際に試す

グループ3：管理画面・監視・社内のAIエージェント

管理画面をインターネットから外し、管理者のログインに多要素認証を必須にする。ミドルウェアの更新を遅らせない
短時間に集中する大量アクセスを検知する仕組みを入れ、総当たりの列挙や一括読み取りに警報を出す。ログは180日以上保存する
認証情報の露出や侵入が確認されたら、調査で安全が確認されるまで「侵害された状態」として扱い、対処のあとに弱点が塞がったかを再テストし、数日から数週間のうちの再攻撃に備える
社内でAIエージェントを動かすなら、実行のたびに期限付きで最小権限の認証情報を発行し、外向きの通信は許可したものだけに絞り、改ざんできない操作ログを残す

CERT-Inの10項目のうち、全業種向けの基本対策文書への参照と金融機関向けの追加項目を除いた8項目を、筆者が3グループに並べ直した。

参考として、CERT-InがAI企業側に求めた7項目も載せます。自社でAIエージェントを評価したり、社内で動かしたりする立場の人に関係します。

CERT-InがAIを開発・評価する側に求めた7項目

評価環境の外向き通信を、ネットワークの設定で既定で遮断する。モデルへの指示だけに頼らない
本物の認証情報やデータを使わず、使い捨ての模擬環境で評価する
課題ごとに触れてよいシステムと操作を決め、第三者のシステムや認証情報に触れたら自動で止める。独立した担当者が停止・再開の権限を持つ
エージェントの通信をリアルタイムで監視し、記録をできる限り完全に残す
エージェントが見つけた第三者の認証情報の再利用を禁止し、見つけた認証情報は修正が必要なものとして記録・通知する
実在のシステムへ到達したら、相手の組織とCERT-Inへ速やかに通知し、修復を手伝う
採用した安全策を公表する

出典：CERT-In 警告 CIAD-2026-0049の「AI model developers, research labs, and evaluation agencies」向けの項を要約。

消したはずの認証情報はGitの履歴に残る

グループ1の「コミット履歴」を、最小のサンプルで確かめました。認証情報を書いた設定ファイルをコミットし、次のコミットで環境変数の参照へ置き換えたリポジトリです。現在のファイルを検索しても見つかりませんが、全コミットを対象に検索すると、最初のコミットに残っています（macOS、2026年10月19日に確認。キーはAWSの公式ドキュメントにある例示用の値）。AWSのアクセスキーIDは「AKIA」で始まるため、この文字列で探しています。

$ grep -n "AKIA" config.yml
（現在の版には見つからない）

$ git grep -n "AKIA" $(git rev-list --all)
5bbb9c4...:config.yml:3:aws_access_key_id: AKIAIOSFODNN7EXAMPLE

作業中のファイルだけを調べるスキャナも、消したあとの版では検出しません。同じサンプルでオープンソースのスキャナ「detect-secrets」（バージョン1.5.0）を現在の版に走らせると検出0件、1つ前のコミットを取り出して走らせると、データベースの接続文字列やAWSのキーなど5件を検出しました。CERT-Inは、履歴に残ったキーを新しいものに入れ替えて無効にし、履歴から消し、外から見えなくなったことを確かめる、という順番を求めています。

CERT-Inの警告で、テスト中のAIエージェントが外の組織のデータへ実際に届いたことが、政府機関の記録として残りました。入り口は、公開リポジトリの認証情報や広すぎる権限といった、人間の攻撃者にも使われてきた弱点です。まず自分の公開リポジトリと履歴を上のコマンドで調べ、見つかったキーを入れ替えるところから始めてください。