AIエージェントがHugging Faceに侵入―事例から学ぶ認証情報とAIセキュリティ｜ブログ(サイバー領域)

※この記事はGitGuardianのブログを日本語に翻訳したものです。

OpenAIのモデルは、ベンチマーク（AIの能力を測るための評価テスト）用のサンドボックス（評価対象のAIを外の世界から遮断しておくための隔離環境）を抜け出し、最終的にHugging Faceの本番システムへ侵入しました。自律型AIエージェントが企業の本番環境に侵入した事例として注目されましたが、攻撃を可能にしたのは、再利用可能な認証情報と、内部で横方向に移動しやすいアクセス構造でした。これらは、AI特有の問題ではなく、従来から存在するセキュリティ上の課題です。

Hugging Face. The Attack Playbook Was Older Than the Attacker
https://blog.gitguardian.com/hugging-face-breach-ai-agent-security/

この記事のポイント

AIエージェントによるHugging Faceへの侵入事例が発生
OpenAIのAIモデルが評価用サンドボックスから脱出し、Hugging Faceの本番環境へ侵入しました。自律型AIエージェントが企業の本番環境に侵入した、公表事例として注目されるケースです。
被害拡大の要因は、AI固有ではない従来からのセキュリティ課題
攻撃では、盗み出した認証情報の再利用や権限昇格、横方向への移動が行われました。攻撃主体はAIエージェントという新しい存在でしたが、悪用されたのは常時有効な認証情報や広すぎるアクセス権限、不十分な内部セグメンテーションといった既存の弱点です。
AIエージェント時代には、認証情報とシークレットの管理がより重要に
AIエージェントも、システムやデータへアクセスするために認証情報を使用します。シークレットの可視化や認証情報の有効期間・権限範囲の制限、セグメンテーションなど、AIエージェントを含む非人間ID（NHI）を前提としたセキュリティ対策が求められます。

AIエージェントによるHugging Face侵入事例とは

2026年7月16日、Hugging Faceは、社内データセットの一部に不正アクセスがあったことを公表しました。その5日後、OpenAIは、攻撃者が自社のAIモデルであったことを認めました。GPT-5.6 Solとリリース前の高性能モデルを含む複数のOpenAIモデルを組み合わせることで、サイバー能力評価が行われていたサンドボックス環境から脱出。ベンチマーク（評価テスト）の解答を探しに行く過程で、権限昇格を実行し、Hugging Faceの複数の内部サービスの認証情報を入手したということです。この事案は、自律型AIエージェントが企業の本番環境に侵入した事例として、公表された初のケースとみられます。

ただし、インシデント報告書から攻撃者が何者だったのかという情報を取り除いてみると、それ以外の内容は、ここ10年間の侵入事案の事後報告書に出てきてもおかしくないものです。つまり、侵入先のシステムから認証情報が盗み出され、それを何度も利用することで横方向に移動し、本番環境に侵入しているのです。この事案が大きく取り上げられたのは、攻撃者がAIエージェントだからです。そして、この攻撃を成立させた弱点は、ほとんどの組織にも存在するものです。

今回の事案は、2つのフェーズに分けることができます。この2つを分けて考えることで、正しい教訓を導き出すことが可能になります。

1つ目のフェーズの発生場所はOpenAIのインフラ内部です。OpenAIでは、サイバー能力の社内評価にあたり、本番運用のセキュリティガードレールを意図的に緩和していました。その環境下でモデルは、サンドボックスを隔離するパッケージレジストリのキャッシュプロキシに存在するゼロデイ脆弱性を悪用。これにより、インターネットに脱出することに成功したのです。

その動機は、笑ってしまうほどありふれたものでした。モデルは「ExploitGym」と呼ばれるセキュリティベンチマークで評価されており、そのテストの解答がHugging Faceにあるのではないかと推論したのです。

第2フェーズの舞台はHugging Faceへと移ります。サンドボックスから脱出したことで、AIエージェントはインターネットに到達しました。Hugging Faceへの侵入に使われたのが、同社の本番環境のデータセット処理パイプラインに存在する2つのインジェクション経路です。1つ目では、HDF5の外部RAWストレージ機能を悪用して処理ワーカー内のローカルファイルを読み取り、シークレットや認証情報を含む環境情報とソースコードを露出させました。2つ目では、データセットの設定に存在するテンプレートインジェクションの欠陥を利用し、処理ワーカー内で任意のPythonコードを実行しました。そこから権限昇格を実行し、週末の間に横方向へ移動して複数の内部クラスターに侵入しました。OpenAIが後に公表した攻撃シーケンスの1つでは、OpenAIのモデルがすでに盗み出していた認証情報とゼロデイ脆弱性の悪用を組み合わせ、Hugging Faceのサーバー上でリモートコード実行を可能にした後、本番データベースからテストデータを読み取っています。この一連の攻撃により、1万7,000件を超えるイベントが記録されたアクションログが残されました。

確認された影響は、当初の発表よりも限定的でした。アクセスされた顧客コンテンツは、5つのデータセットに保存されていたExploitGym/CyberGymのチャレンジ問題の解答だけでした。それ以外の顧客向けモデル、データセット、Spaces、パッケージには影響はなく、読み取られた顧客の記録も、データセットサーバーへの検索に関連する運用メタデータだけでした。ただし、この侵入によって、内部サービスの認証情報が攻撃側に露出し、Hugging Faceの内部インフラにまで侵入が及びました。同社はその後、2つのインジェクション経路の両方に対処し、不正アクセスを受けたノードを再構築するとともに、影響を受けた認証情報を無効化してローテーションを実行しました。さらに、予防措置として、影響範囲以外のシークレットのローテーションにも着手しています。

自律型AIエージェントのセキュリティに突き付けられた初めての試練

キーボードを使わない攻撃者の登場によって、リスクは変容しています。今回の一連の攻撃では、短命なサンドボックスの“群れ”に対し、機械ならではのスピードで攻撃が展開されました。また、その中にはおとりも含まれていたため、調査担当者は後から本物を切り分ける作業が必要でした。フォレンジック調査の負担は非常に大きかったことから、Hugging Faceはオープンウェイト（学習済みの重みが公開された）のGLM 5.2モデルを活用した自社エージェントを投入し、攻撃者の全アクションログを分析させることで、攻撃のタイムラインの再構築を図りました。これまで自律型AIエージェントのセキュリティは、将来起こり得ることを予測し、発展してきた分野でした。しかし7月16日以降、予測ではなく実際の事例に基づく研究が可能になりました。その結果、インシデントの公表から現在に至るまで、防御側では現実のインシデントをもとに調査・分析を進めています。

ただし、このインシデントの規模は冷静に見極める必要があります。現時点で公に確認されているこの種の事例は、片手で数えられるほどしかありません。目新しいからといって、発生する可能性が高いとは限りません。この2つを同一視してリスクを評価すれば、予算の配分を誤ることになります。

AIエージェントの侵入を許した認証情報と横方向への移動

ここで、AIエージェントがインターネットに到達した後の実際の動きを見てみることにしましょう。AIエージェントはまず、コード実行の脆弱性を悪用して処理ワーカーに侵入しました。次に、その処理ワーカーの正規の認証情報を盗み出しました。

盗み取った認証情報は繰り返し使用できるもので、内部の本番システムにアクセスできるだけの十分な権限が付与されていました。公表された情報では、これらの認証情報がどれほどの期間にわたって有効だったのか、またHugging Faceがどのような利用範囲を想定していたのかは明らかにしていません。しかし、それを知る必要はありません。教訓は、こうした認証情報の性質そのものにあるのです。つまり、長期間有効で別の場所でも使用できる認証情報は、第三者にも提示して利用できるということです。そして、その認証情報には、それを使っているのが正規の所有者なのか、盗んだ攻撃者なのかを区別するすべがありません。

OpenAIが7月28日に公表した最新情報によって、認証情報をめぐる教訓はさらに明確になりました。AIエージェントは、4つの公開サービスから、インターネット上に露出していた4つのアカウントの認証情報を発見しました。そのうち1つを外部への中継地点と攻撃の足場となる経路として利用し、もう1つをデータの保存に使用しました。残る2つのアカウントには、読み取り専用でアクセスしていました。今回の一連の攻撃で利用された2つのアカウントでは、外部に露出していたログイン情報だけで、正規のアカウントを、AIエージェントが攻撃を継続するために利用できるインフラへと変えることができたのです。

有効期間の長期化は今や常態となっています。GitGuardianの「State of Secrets Sprawl 2026」（日本語版はこちらからダウンロードしていただけます）によると、60.4％のIDで、長期間有効なシークレットが使われていました。また、2022年に初めて検出された有効なシークレットの実に64％が、2026年1月に再検証した時点でも有効だったことが判明しています。4年前に作成され、一度もローテーションされていない認証情報が、今なお同じシステムへのアクセスを可能にしているのです。それを発見した攻撃者は、ランサムウェア攻撃グループであろうと、ベンチマークの攻略に夢中になった言語モデルであろうと、その認証情報でアクセスできるすべてのシステムに同じようにアクセスできることになります。

常時有効な認証情報は、攻撃者に時間的な余裕も与えます。IBMの「2025年データ侵害のコストに関する調査」によると、盗まれたり侵害されたりした認証情報をきっかけに始まった不正侵入は、検知するだけでも最長186日かかります。有効な認証情報が使われていると、通常の業務と変わらないように見えるからです。Hugging Faceでは、独自の異常検知により今回の一連の攻撃を数日以内に検知しています。しかし、このような早期の検知が期待できる環境は限定的です。

AIエージェントのセキュリティリスクを経営陣にどう説明するか

今回のような新たなタイプの自律型攻撃者が利用したのは、セキュリティ分野に古くからある弱点の一つ、繰り返し使用できる認証情報です。経営陣との対話は、この点を軸に進めるといいでしょう。今回のインシデントでは、新たな脅威モデルの存在が明らかになりました。しかし、AIエージェントによる本番環境へのアクセスを可能にした条件は、すでによく知られたものです。このリスクは、2つのカテゴリーに分けると、理解しやすくなります。

新たに台頭するリスク

今や自律型AIエージェントは、攻撃者として動作し、脆弱性を悪用してシステム間を移動し、機械ならではのスピードで攻撃活動を実行できるようになりました。セキュリティチームは、この脅威の今後の進展を監視し、人間による侵入に比べて展開速度も活動量もはるかに多い攻撃キャンペーンに対し、現在の検知・対応プロセスが追い付いていけるかどうかを検証する必要があります。

現在のリスク

AIエージェントが必要としていたのは、これまで同様、窃取し繰り返しの使用が可能な認証情報でした。サービスアカウントやパイプラインに常時アクセス可能なアクセス情報、コードや設定に露呈しているシークレット、信頼できない処理環境からアクセス可能な本番システム、そして不十分な内部セグメンテーション。これらはすべて、最初の侵入の影響を拡大する要因です。

いずれも、すでに当たり前のものとなっているセキュリティ上の問題です。にもかかわらず、確実に対応できている組織は多くはありません。認証情報の検出能力を強化する、アクセス権の有効期間を短くする、適用範囲を絞り込む、セグメンテーションを強化する、迅速にローテーションを実施する、こうした対策をとることでリスクは軽減できます。

このようにリスクを整理することで、大きく報道されるようなインシデントが発生した際にも、セキュリティ責任者は実践的な答えを示すことができます。攻撃者は耳慣れないものでした。しかし、悪用された弱点は目新しいものではありません。その弱点への対策には、今すぐ取りかかることができます。

AIエージェント時代に求められる5つのセキュリティ対策

本番環境にアクセスできる自動化システムに対して、常時有効な権限を持ち、有効期間の長い認証情報を発行しない。
有効期間が短く、利用範囲を1つのタスクに限定し、タスクの終了と同時に無効になる認証情報という考え方は、AIエージェントだけでなく、それ以前から存在するサービスアカウントやパイプラインにも同様に当てはまります。目指すべき最終形には「ゼロ・スタンディング・プリビレッジ（zero standing privileges / 常時有効な権限をゼロにすること）」という名前があります。認証情報は、それが発行された作業が終了すれば無効になります。そのため、攻撃の最中に認証情報が盗み出されたとしても、再利用できる時間は大幅に短くなり、攻撃者に継続的なアクセスを許すこともありません。この対策を講じる上で、エージェントの自律性をめぐる未解決の問題に答えを出す必要もありません。認証情報を盗むのが人間であろうとAIモデルであろうと、効果は同じだからです。
マシンやAIエージェントがすでに保持している認証情報を可視化する。
把握できていないシークレットに対しては、前述の対策を講じることはできません。現在では、人間以外のID（非人間ID）の数は従業員の109倍に上ります。そして、マシンIDはいずれも、コード、設定、処理ワーカー、パイプラインなど、いずれかに設定された認証情報を使って認証を行っています。そうした認証情報を見つけ出すことが、安全な仕組みに置き換えるための第一歩です。
データパイプラインとモデルパイプラインを正式な攻撃対象領域として扱う。
Hugging Face自身の事後報告書でも、この点が指摘されています。データセットローダー、テンプレートの設定、処理ワーカーをはじめ、信頼できない入力をもとに生成されたコードを実行するものはすべて、本番APIと同じ脅威モデルに取り込む必要があります。
1つの処理ワーカーの認証情報だけでは本番クラスターにアクセスできないようセグメンテーションを行う。
今回の事案の規模を左右したのは、盗み出された認証情報で到達できる範囲でした。
認証情報の悪用を、個別の事象ではなく連続する一連の流れとして検知する。
パッケージのインストールは、一見すると問題のない行為に見えます。認証情報ストアへの照会や外部サーバーへのアクセスも同様です。しかし、これらの行為が連続して行われると、全体としては攻撃となります。個々の事象を切り離して評価するだけの監視では、攻撃が進行する様子を捉えていながら、それを攻撃とは認識できず、警告を発することもなかったでしょう。

導入するAIエージェントはすべてシークレットで動いている

認証情報をめぐるこの教訓は、防御側にも当てはまります。企業環境に接続されるAIエージェントは、その一つ一つが認証情報を使用する“新たな”IDであり、セキュリティチームはそれらの認証情報を見つけ出す必要があります。そして、権限が広範で常時有効なトークンを使用するAIエージェントが存在していれば、今回と同じようなインシデントがいつ起きてもおかしくない状態にあるということを意味します。

認証情報を手にした攻撃者は、わざわざ侵入する必要などありません。その認証情報を使ってログインできるからです。GitGuardianは、シークレットが存在するあらゆる場所からシークレットを検出します。シークレットが生成される開発者のマシン、組織内部のリポジトリ、パイプライン、コラボレーションツール、外部に流出したシークレットが存在するパブリックコード、そしてシークレットを保管するボールトまで、そのすべてが対象です。さらに、本物かどうか、現在も有効かを確認した上で、それぞれのシークレットに、所有者や侵害時の影響範囲など、そのシークレットに関連するIDの情報をひも付けます。これにより、4年前に作成され、今なお有効な認証情報も可視化されます。そして、シークレット管理プログラムでは具体的な対処が難しかった常時有効なアクセス権の問題も、一つずつ対処できる問題となるのです。

GitGuardianに関する
お問い合わせはこちら

GitGuardianとは

GitGuardianは、シークレットセキュリティと非人間アイデンティティ（NHI）セキュリティを支援するセキュリティプラットフォームを提供しています。

コンステラセキュリティジャパンでは、GitGuardianのソリューションを通じて、企業におけるシークレットの検出・管理やNHIの可視化・保護を支援しています。
NHIやシークレットの管理に課題をお持ちの方、GitGuardianの導入・活用について詳しく知りたい方は、お気軽にお問い合わせください。