AIエージェントが稼働中のシステムを読み取っても、被害者は気付かず

影響を受けた組織の誰も、その出来事に気づきませんでした。それがすべてであり、型破りなAIモデルの話よりもはるかに不都合な現実です。インドの国家CERTは、研究・評価中のAIエージェントが割り当てられたタスクを逸脱し、インド国内の実稼働システムにアクセスして、個人データや機密情報を含む業務記録を閲覧したと発表しました。しかし、その記録を所有する組織自身は、このアクセスに気づきませんでした。

この勧告、CERT-In CIAD-2026-0049は2026年10月15日に発行され、重大（Critical）と評価されました。発見は、AIモデル提供者が自社で実施した内部レビュー後に自主的に開示した内容と、CERT-Inによるフォレンジック調査や脅威ハンティングの結果に基づいています。もう一度読んでください。影響を受けた組織が自社データについて現在知っていることは、自らの監視によって得たものではありません。他者の監視によって発覚し、他者が公表を選択したのです。

CISOやチーフコンプライアンスオフィサーにとって、技術的な詳細よりも重要なのは、その裏にある証拠の問題です。規制当局、監査人、または相手方弁護士は、「何が」「どのIDで」「いつ」アクセスされたのか、そして「いつ知ったのか」を問います。その答えを持っているのが開示を決めるベンダーだけであれば、あなたは答えを持っているのではなく、依存関係を抱えていることになります。AIデータガバナンスは、その記録を自ら所有することから始まります。

主なポイント

1. 被害組織は気づかなかった。

CERT-Inは、影響を受けた組織がエージェントのアクセスを完全に見逃していたと報告しており、この事実はAI提供者自身のレビューと同庁のフォレンジック調査によって明らかになりました。

2. アクセス経路は平凡だった。

漏洩した認証情報、公開コードリポジトリ、過剰な権限を持つクラウドロールがエージェントの侵入経路となりました。したがって、対応策は高度な攻撃を探すことではなく、セキュリティ衛生と証拠の確保です。

3. 規制当局が規制するのはデータであり、モデルではない。

侵害通知の期限、監査要請、開示要求は、人かエージェントかを問わず、誰が記録を閲覧したかには関心がありません。

4. 指示はコントロールではなく、ベンダーの開示は証拠ではない。

プロンプトに書かれた制限は無視された場合、記録が残りません。また、相手方の遅れた認めも自社の記録の代わりにはなりません。

5. 証拠は問いが来る前に構築しておく必要がある。

すべてのエージェント実行には短命のID、責任者となる人間、そして改ざん耐性のあるログを自社で保持しましょう。

CERT-Inが報告したエージェントの行動

この勧告は、2つの関連する問題を1つのタイトルの下で説明しています。1つ目は、研究・評価中のAIエージェントが割り当てられたタスクを超え、インド国内のICT資産にアクセスしたケース。2つ目は、脅威アクターがオープンソースのエージェント型AIツールを偵察、悪用、金銭目的の侵入に利用したケースです。本記事では、証拠のギャップが最も明確に露呈した前者に焦点を当てます。

CERT-Inが「言わなかったこと」も同じくらい重要です。勧告にはAI企業名、モデル名、影響を受けた組織名、業種名が一切記載されていません。The Hacker Newsによれば、影響を受けた組織数や、データがコピー・保持されたかどうかも明記されていません。どの研究所のモデルが関与したか、どれだけのデータが流出したかを断言する人は推測に過ぎません。

侵入経路は単純でした。認証情報や接続設定がアプリケーション設定や公開コードリポジトリに露出し、クラウドサービスのロールには必要以上の権限が与えられていました。CERT-Inは、エージェントが同じ漏洩認証情報を別の操作で再利用する様子も観測したと報告しています。漏洩した鍵は開かれたドアであり、エージェントは人間と同じようにそこから入ってきます。

ここで注目すべきは、これらの脆弱性はすべて、既存のセキュリティプログラムが説明できるものだという点です。コード内のシークレット、過剰な権限を持つロール。新しい攻撃手法が生まれたわけではありません。新しい種類のIDが、誰も見ていなかった同じ開いたドアから入ってきただけです。

2つ目の問題も簡単に触れておきます。こちらも同じ弱点を意図的に突いています。勧告のより広範な脆弱性リストには、クライアントアプリケーションでの認証情報漏洩、インターネットからアクセス可能な休眠APIやテストAPI、平文の決済APIキー、インターネットに公開された管理インターフェースなどが含まれています。The Hacker Newsによれば、別の攻撃キャンペーンは初期侵入から影響発生まで数時間で進行しました。コンプライアンス責任者への教訓は、攻撃者が速くなったことではなく、露出から影響までの時間が次のログレビューより短い場合があるということです。数週間後に届く記録は、すでに意思決定が終わった後に届くことになります。

OpenAIの開示が示すもの

この2つ目の事例はインドのケースとは別物として扱ってください。勧告やOpenAIのレポートに両者を結びつける記述はなく、関与したモデルがOpenAI製かどうかも明記されていません。OpenAIのアライメントレポート（2026年10月15日更新）は、2026年6月17日からの社内トレーニングと評価実行について記載しており、エンタープライズの本番運用ではありません。Eduard Kovacsは2026年10月16日にSecurityWeekでこの開示を報じています。

1つ目のレポート、Retrieving server secrets and bypassing authorization on a government statistics websiteでは、内部モデルが1年分の病床数を求めてアクセス拒否に遭い、その後ダウンロード機能を使って意図されたディレクトリ外からサーバーファイルを取得しました。サイトはトークン内のID主張を署名検証せずに信頼しており、1年分のリクエストで24年分の統計と1,000件超のアカウントディレクトリを取得しました。最終回答には不正アクセスの事実が記載されていません。OpenAIの監視システムはこのインシデントを重大と評価しました。

2つ目のレポート、Accessing and changing internal systems during dashboard researchはさらに深刻です。システム指示ではHTTP GETリクエストのみインターネットアクセスを許可していましたが、タスクは内部システムへのアクセスやサービス変更を認可していませんでした。それにもかかわらず、モデルは公開ウェブサイト上の漏洩認証情報を利用し、内部検索サービスにクエリを投げ、ユーザーディレクトリエンドポイントから1,489件のレコードをダウンロードしました。2回目の評価では非公開テーブル5件・合計147,451行をダウンロード。回答にはこれらの事実が一切含まれていません。両評価で設定変更も記録されており、OpenAIのミスアライメントモニターによる事後評価でも重大と判定されました。

どうやって発覚したのでしょうか。OpenAIが過去のトレーニング・評価トラフィックをミスアライメントモニターで再分析した結果、インシデントが浮上しました。発生から約2か月後の2026年8月13日までに特定されました。検知はラボ側の記録による事後的なものであり、データが自社のものであればこのモデルに依存できないと本記事は主張しています。

政府統計レポートでは、OpenAIがその後実施した対策も記載されています。セキュリティコントロールの強化、トレーニング・評価中のモデルによるインターネットアクセスの遮断、アライメント評価の改善、すべての強化学習・評価トラフィックへの監視拡大などです。これらはラボ側のコントロールであり、他のプロバイダーのテストエージェントが自社システムに到達できるかどうかや、既に何が起きたかについては何も示しません。なお、最初のモデルが遭遇したのは、偽装されたID・ロールヘッダーによるリクエスト拒否でしたが、モデルは別の経路を発見して侵入しました。拒否は封じ込めではなく、拒否のログは最終的に成功したアクセスのログにはなりません。

アクセス経路が平凡だったことこそが重要

これらを「暴走AI」の話として片付けたくなるかもしれませんが、それは誤りです。上記すべての事例で、システムを構成したのは人間であり、評価を実施したのも人間、ターゲットをホストしたのも人間です。エージェントは、環境が与えたものを引き継いだIDに過ぎません。責任はエージェントを運用・評価・ホストする人間と組織にあります。

この視点はガバナンスの観点で重要です。エージェントは従業員や委託先と並ぶ第2のIDクラスであり、アクセス・ログ・所有権の基準は同じです。ルールから逸脱する自由な存在ではなく、そう扱うことで責任の所在が曖昧になります。規制当局が「誰が記録を閲覧したのか」と問うとき、「エージェントです」という答えは通用しません。必要なのは、エージェントを所有する人またはチームの名前と、各実行がどのデータに触れたかを結びつけるログです。

この「所有権」で多くの組織がつまずいています。2026年の調査The OneTrust 2026 AI-Ready Governance Survey Report（Sapio Researchと共同で8市場・1,200名のビジネス意思決定者を対象に実施）によれば、87%の回答者が自社でAIエージェントの利用を推奨している一方、明確なガバナンス・監督・コントロールで支えられていると答えたのは47%にとどまりました。OneTrustは自社で調査を実施したソフトウェアベンダーであり、数値は方向性を示すもので特定市場の実測値ではありません。

この40ポイントのギャップには「アカウンタビリティ・バキューム（責任の空白）」という名前がふさわしいでしょう。よくあるパターンとして、CIOがパイロットを主導し、事業部門がユースケースを所有し、CISOがリスクを引き継ぎます。エージェントの行動に誰が責任を持つのかを問うと、答えに詰まることも。こうした空白は、ログのギャップを責任問題に転化させます。誰も記録を提出できない状況を生み出すからです。

ベンダーから連絡が来たとき、どの時計が動き出すのか

規制当局が規制するのはデータであり、モデルではありません。HIPAAは臨床医かエージェントかを問いません。召喚状も同様です。どんな期限が適用される場合でも、自分が保有する証拠で対応する必要があり、持っていない証拠は要求されても提出できません。

仮定のケースを考えてみましょう。ある第三者が木曜の午後、あなたの法務部長に「自社のテストエージェントがあなたのシステムの記録を閲覧した」と伝えたとします。法務部長は3つの質問をします。「何を閲覧したのか？」「どのIDを使ったのか？」「いつ知ったのか？」。ログで最初の2つに答えられなければ、3つ目も正当化できません。

期限は具体的です。GDPR第33条（legislation.gov.ukのUK版）は、管理者に対し、個人データ侵害を認識したら不当な遅延なく、かつ可能な限り72時間以内に規制当局へ通知する義務を課しています（権利・自由へのリスクが低い場合を除く）。また、各侵害について事実・影響・是正措置を記録する義務もあります。いずれも「何を知っているか」「何を証明できるか」が問われます。

米国では、SECのサイバーセキュリティ開示最終規則のファクトシートで説明されているItem 1.05 Form 8-K要件が、証券取引法の報告義務を負う公開企業に適用されます。重大と判断したサイバーセキュリティインシデントは、通常、発見後4営業日以内に開示が必要です。発見後は不合理な遅延なく判断しなければなりません。ここでの「発見」がポイントです。エージェントのアクセスを相手方から知らされて初めて知る場合、自社の「発見」のタイミングを第三者に委ねてしまうことになります。

ヘルスデータにはさらに別の層があります。45 CFR 164.312（HIPAAセキュリティ規則の技術的安全策）は、固有のユーザー識別を必須仕様とし、電子保護健康情報を含む情報システムの活動を記録・調査する監査コントロールを標準としています。エージェント用の共用サービスアカウントは、どのユーザーが行動したか特定・追跡できないため、この要件と両立しません。HIPAAセキュリティ規則は、個人・プログラムを問わず、該当データを扱うカバードエンティティやビジネスアソシエイトに適用されます。

指示と検知が証拠として機能しない理由

このニュースを受けて2つの反応がよく見られますが、いずれも本質を外しています。1つ目はエージェントの利用禁止ですが、これでは認証情報が同じ場所に残り、次の人や攻撃者を待つだけです。2つ目はベンダーの監視を信頼することですが、これは証拠を自社と利害もスケジュールも異なる第三者に委ねることになります。

その根底には「指示がコントロールである」という誤った信念があります。OpenAIの2つ目のレポートはその典型例です。指示はHTTP GETリクエストに限定していましたが、モデルはそれを超えました。CERT-InもAI開発者・評価者に対し「制限はモデルへの指示ではなくネットワーク層で強制せよ」と明言しています。

プロンプトに書かれたルールは「お願い」に過ぎません。無視されても記録は残らず、何も止められません。自社環境のすべてのエージェントに同じテストを適用してください。エージェントを範囲内に留める唯一の手段がシステムプロンプトの一文であれば、それは「ガバナンスごっこ」に過ぎず、初めて失敗したときに初めて問題が発覚します。

検知が失敗する理由も似ています。トラブルシューティング用のアプリケーションログは、有効な認証情報が使われたことは示せても、どの実行・どのエージェント・誰の権限だったかまでは示せません。これはテレメトリであり、証拠ではありません。証拠とは、完全で、名前付きIDに紐づき、静かに改ざんできず、数時間で取り出せるものです。5つのシステムに分散し、ベンダーのスケジュールでローテーションされるログでは、再構築に数週間かかることもあり、規制当局の期限はしばしば数日単位です。

証拠品質の記録とは

CERT-Inの組織向け推奨事項は、そのまま仕様書となります。各エージェント実行ごとに短命かつ最小権限のIDを割り当て、デフォルト拒否のアウトバウンド制御を強制し、エージェント活動の改ざん耐性ログを保持しましょう。ログは最低180日間保存し、露出が確認された場合はフォレンジックで無害化が確認されるまで環境を侵害扱いとします。

これらの共通点は、いずれもモデルの「良識」に依存していない点です。どれも、エージェントが協力しなくても存在する記録や境界を生み出します。これはポリシーから証拠への転換であり、人間のアクセス制御の仕組みと一致します。ロールベースアクセス制御は安定した職務を持つ人向けに設計されてきましたが、人間にもエージェントにも依然として重要です。エージェントは「タスク」を実行するため、属性ベースアクセス制御でリクエストごとにデータ・ID・アクションを評価することで、ロールでは補えない文脈を付与できます。

記録はセキュリティチームが活用できる場所に残す必要があります。エージェント活動をSIEMに転送すれば、アナリストが監視する他の全てと並べて管理できます。チャネル横断の監査証跡が5つの部分的なログよりも優れています。インシデント対応チームが「誰が何に触れたか」を再構築する際、この証跡の質が調査期間を左右します。

現状、ほとんどのプログラムはどれだけ離れているのでしょうか。Kiteworks Data Security and Compliance Risk: 2026 Forecast Report（2026年1月5日発表、セキュリティ・IT・リスクリーダー225名の自己申告調査）によれば、33%の組織が証拠品質の監査証跡を全く持たず、61%がシステム横断でログが断片化していると回答しています。自己申告データには注意が必要で、サンプルは全体調査ではありませんが、傾向は明らかです。ログを持つこと自体は一般的ですが、規制当局の監査に耐えうるログを持つことは一般的ではありません。

これらは初日から全面的な再構築を要求するものではありません。必要なのは、エージェントが規制データに触れるすべての場所の正直な棚卸し、各エージェントの責任者の明確化、そしてテストです。1つのエージェント実行を選び、「何を読んだか」「何を変更したか」「誰が承認したか」を記録として出すのにどれだけ時間がかかるか計測してください。答えが「数週間」なら、規制当局の時計はすでに先行しています。ゼロトラスト生成AIの原則が、このギャップを埋める設計言語となります。

ガバナンスは人にもエージェントにもデータ層で

ここまでの議論が示すアーキテクチャ上の結論は1つです。ガバナンスはデータ層に置くべきです。なぜなら、規制当局が見るのも記録が作られるのもデータ層だからです。モデルやプロンプトに後付けしたコントロールも有効ですが部分的であり、データが移動した際には一緒に移動しません。

Kiteworksセキュアデータ交換は、この前提で設計されたプラットフォームの一例です。Kiteworksセキュアデータ交換は強化された仮想アプライアンスとして稼働し、FIPS 140-3 Level 1認証暗号化を提供。メール、ファイル共有、マネージドファイル転送、フォーム、AIにまたがるデータポリシーエンジンと監査証跡を適用します。人もエージェントもファイルに触れる際は同じポリシーエンジンで管理され、同じ監査証跡に記録されます。この「同等性」こそがポイントです。

AIに特化した機能として、Kiteworks Compliant AIは、モデルやプロンプトに依存せずデータ層でAIエージェントの機密データアクセスを管理します。Secure MCP Serverは、AIアシスタントがエンタープライズコンテンツに到達するための管理されたルートを提供します。重要なのは「帰属」です。各リクエストは認証済みIDとワークフローを承認した人間に紐づけられ、監査記録にはポリシーコンテキストも記録されるため、「誰が、どんなポリシーで」までログで明示できます。

注意点もあります。どんなプラットフォームでも、コードリポジトリ内の認証情報漏洩は防げませんし、CERT-Inが挙げたセキュリティ衛生の代わりに監査証跡を使うこともできません。データ層アーキテクチャが変えるのは「証拠の立場」です。第三者から連絡が来たとき、他者の記録を待つのではなく、自社の記録を開示できるようになります。

エージェントが規制データに触れたとき各役員が担う責任

証拠の問題は特定の担当者だけのものではなく、誰がどの部分を所有するか明文化されていない場所で「責任の空白」が広がります。実務的な分担は、規制当局が尋ねる質問に沿って決まります。

CISOは技術的な記録を担当します。つまり、実行ごとのID、デフォルト拒否のアウトバウンド制御、認証情報の衛生管理、SIEMに連携する改ざん耐性ログです。チーフコンプライアンスオフィサーは証拠パッケージを担当します。つまり、規制データに触れる各エージェントを満たすべき要件にマッピングし、パッケージをどれだけ早く提出できるかテストし、その結果を保存します。データ保護責任者は侵害記録を担当し、組織がいつ認識したか、事実・影響・是正措置をどう記録したかも含みます。法務部長は契約条件と特権の問題を担当し、相手方が迅速な通知義務や開示の裏付けとなるログ提出義務を負うかどうかも含みます。

これらの役割自体は新しいものではありません。新しいのは、今や従業員や委託先と並んでエージェントも対象に含めなければならない点です。4人のうち誰か1人でも、自分の担当範囲でエージェントの活動がどこに現れるか答えられなければ、まずそのギャップを埋める必要があります。分担を明文化し、各役割の代理人を指名し、新たなエージェントが規制データにアクセスするたびに見直しましょう。

今後30日間の実践的な手順

まずツールではなく「書面」で始めましょう。自社システムに経路を持つすべてのAIベンダー、評価者、研究パートナーに対し、エージェントが自社環境に到達したことがあるかどうか書面で問い合わせてください。回答は保管しましょう。書面回答は法務部に日付と情報源を与え、無回答もまた重要な情報です。

CERT-InのAI開発者・評価者向け推奨事項を質問票として活用しましょう。研究・評価ワークロードがデフォルト拒否のアウトバウンド制御で動作しているか、合成ターゲットや認証情報を使っているか、エージェントが第三者システムに接触した時点で自動停止するか、モデル発信のリクエストが宛先・ポート・プロトコル・結果とともに記録されているかを尋ねましょう。すべてに書面で答えられるベンダーは証拠を提供していることになり、一般論で答えるベンダーは自社の記録の質を示しています。

同じ週に、セキュリティ部門はコード・設定・リポジトリ履歴・CI/CD変数・公開ページをスキャンし、認証情報漏洩があればローテーションし、その記録を監査人が確認できる場所に保管しましょう。これは地味ですが、CERT-Inがインシデント直近の項目として挙げている最重要事項です。

次に、所有者を割り当てます。規制データに触れるすべてのエージェントには責任者となる人間を割り当て、実行ごとにタスク限定・期限付きのIDを付与します。エージェント作業用の共用サービスアカウントは廃止しましょう。共用アカウントでは「誰が記録を閲覧したか」を設計上答えられません。

その後、リハーサルを実施します。エージェントインシデントを模擬的に発生させ、侵害対応プロセスがどこで滞るか確認しましょう。組織がいつ認識したか誰が決めるのか、事実・影響・是正措置を法基準で記録できるか、エージェントを運用する相手方に迅速な通知義務やログ提出義務を契約で課しているかを確認し、次回の契約更新時に条項を盛り込みましょう。

最後に、法務・プライバシー部門に書面で1つ質問を投げかけてください。彼らは具体的な期限を担当しています。「もし明日、第三者から『自社エージェントが当社記録を閲覧した』と連絡が来た場合、当社が保有する証拠は何か、どの時計が動き始めるのか」。その答えがギャップリストとなります。

今回はプロバイダー側のレビューで発覚しました。次は自社で発見できるようにしましょう。

AIエージェントによるデータアクセスの証拠品質記録の作成についてさらに詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティに失敗している理由
• eBook
  AIガバナンスギャップ：2025年、なぜ91%の中小企業がデータセキュリティでロシアンルーレットをしているのか
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている