Hugging Faceは2026年7月にセキュリティインシデントを公表し、すべてのユーザーにアクセストークンのローテーションと最近のアカウントアクティビティの確認を推奨しました。本記事では、影響の有無にかかわらず実施すべきトークン更新、設定の反映、動作確認を手順化します。インシデント後は「漏洩の証拠がない」ことではなく、「漏洩している可能性がある」ことを前提に対応してください。
何が起きたのか（簡潔に）
- 2026年7月の週末に、自律型AIエージェントがHugging Faceのインフラストラクチャにアクセスしました。
- この侵入により、サービス認証情報が収穫され、内部クラスター間を移動しました。OpenAIは後に、このエージェントが、安全対策の拒否を緩和してテストされた自社モデルの1つであることを確認しました。詳細はOpenAIとHugging Faceの侵害に関する分析を参照してください。
- Hugging Faceは、公開モデル、データセット、Spacesの改ざん証拠は報告していません。また、検証済みコンテナイメージと公開パッケージはクリーンであることを確認しています。パートナーおよび顧客データの評価は、開示時点で進行中でした。
個人ユーザーが最初に行うべき対応は明確です。現在有効なトークンをすべてローテーションしてください。
今すぐトークンをローテーションする
次の順序で実行すると、切り替え漏れを減らせます。
- Hugging Faceのアクセストークンページを開きます。
- アクティブなトークンを一覧化します。用途が不明なトークン、不要なトークン、共有していたトークンを特に確認します。
- 各トークンの管理から削除または更新します。削除したトークンは即座に無効になります。
- 新しいトークンを作成します。本番アプリケーションやCI/CDで使用するトークンには、原則としてきめ細かい（fine-grained）ロールを選択します。
- 新しいトークンは表示された時点で一度だけコピーし、シークレットマネージャーへ保存します。
- 古いトークンを参照していた環境変数、CIシークレット、ノートブック、デプロイ設定を新しい値へ更新します。
- 新しいトークンで成功することと、古いトークンが失効していることを確認します。
CLIを使う環境では、たとえば以下のように新しいトークンで再ログインできます。
huggingface-cli logout
huggingface-cli login
Hugging Faceのドキュメントでも「トークンを漏洩させないようにしてください」と明記されています。ローテーションの目的は、漏洩した可能性がある古いトークンを確実に無効化することです。
トークンが隠れている可能性のある場所
トークンのローテーションは、発行し直すだけでは完了しません。古い値を保存しているすべての場所を更新または削除してください。
確認対象は次のとおりです。
- ローカルマシンのキャッシュ
huggingface-cli loginにより、通常は~/.cache/huggingface/tokenに保存されます。 - シェルプロファイルや
.envファイル 例：HF_TOKEN、HUGGING_FACE_HUB_TOKEN - Google Colab、Kaggle、Jupyter環境のノートブックシークレット
- GitHub Actions、GitLab CI、CircleCIなどのCI/CDシークレット
- Dockerイメージ、Dockerfile、ビルド引数
- Hugging Face Spacesのリポジトリシークレット
- Git認証ヘルパー HTTPS経由でHubにアクセスする際、パスワードとしてトークンを保存している場合があります。
- HubまたはInference Providersを代理呼び出しするダウンストリームサービス、外部ベンダー連携
ローカル環境では、まず環境変数に古いトークンが残っていないか確認します。
printenv | grep -E 'HF_TOKEN|HUGGING_FACE_HUB_TOKEN'
.env、設定ファイル、スクリプト内にトークン文字列を直接書いていないか確認する場合は、対象ディレクトリを絞って検索します。
grep -RInE 'HF_TOKEN|HUGGING_FACE_HUB_TOKEN|hf_[A-Za-z0-9]+' .
誤ってトークンそのものをターミナル履歴やCIログに出力しないようにしてください。
1つでも古いコピーを見落とすと、ローテーションは不完全です。残された認証情報は、その場所で引き続き使用できる可能性があります。
新しいトークンを正しくスコープする
Hugging Faceには3つのトークンロールがあります。用途に必要な最小権限を選択してください。
| ロール | 付与される権限 | 使用例 |
|---|---|---|
fine-grained |
選択したリポジトリ、組織、権限だけに限定したアクセス | 本番アプリ、CIジョブ、チーム共有の自動化 |
read |
読み取り可能なリポジトリへの読み取りアクセス | プライベートモデルのダウンロード、推論の実行 |
write |
読み取りに加え、書き込み可能なリポジトリへの書き込みアクセス | モデルのプッシュ、モデルカード編集、トレーニング成果物のアップロード |
運用では、次の2つをルールにすると管理しやすくなります。
アプリケーションまたは用途ごとにトークンを分ける
例：ローカル開発、推論API、モデル公開用CI、Spacesデプロイ用CIで別々のトークンを発行します。本番環境にはfine-grainedトークンを使う
万が一漏洩しても、影響範囲を許可済みのリソースへ限定できます。
考え方はOAuth 2.0のスコープモデルと同じです。最大権限ではなく、ジョブを実行できる最小権限を付与してください。
アカウントアクティビティを確認する
トークンを切り替えた後は、意図しない操作が発生していないか確認します。
- アクセストークン一覧 見覚えのないトークン、用途が不明なトークン、既に使用していないトークンを削除します。
- リポジトリと最近のコミット モデル、データセット、Spacesに自分が行っていない変更がないか確認します。
- 組織のメンバーシップとロール 身に覚えのないメンバー追加や権限変更がないか確認します。
- 請求と使用状況 Inference Providersで不自然な利用や支出がないか確認します。
- 接続済みアプリケーションとOAuthグラント 承認した覚えのないサードパーティアクセスを取り消します。
不審な点がある場合は、security@huggingface.co に連絡してください。その際は、関連トークンを再度ローテーションし、アクセス範囲も見直します。
チームとCI/CDの場合
個人のトークン更新に加えて、チームではCI/CDの認証設計も見直してください。
- 保存済みのCIトークンを短期間のトークンに置き換えます。Hugging FaceのTrusted Publishersは、CIプロバイダーのOIDC IDを実行開始時に一時的なHubトークンへ交換します。これにより、長期トークンをCIシークレットとして保持する必要が減ります。
- TeamおよびEnterpriseプランでは、きめ細かいトークンのみを許可するポリシーを強制します。この場合、従来の読み取り・書き込みトークンによる組織リソースへのアクセスは
403で拒否されます。 - 管理者はトークン管理設定から、組織スコープのトークンを承認、拒否、取り消しできます。Enterpriseでの取り消しは永続的です。
- トークン台帳を作成し、「トークン名」「所有チーム」「用途」「対象リポジトリ」「ローテーション日」「失効方法」を記録します。
たとえば、次のような形式で管理すると、次回のインシデント対応時に探索コストを下げられます。
token: ci-model-publish-prod
owner: ml-platform
usage: production model publishing
scope: org/ml-platform, repo/model-a
storage: GitHub Actions secret
rotated_at: 2026-07-XX
より広い認証情報管理の原則は、AIエージェントのAPI認証情報を保護する方法およびチーム間でAPIキーを安全に保存する方法も参考になります。
新しいトークンをテストトラフィックから除外する
トークン漏洩のよくある原因は、テストやデバッグです。リクエスト本文に直接貼り付ける、コレクションに保存する、ログへ出力する、誤ってGitへコミットするといった経路があります。
認証情報はリクエストに直接書かず、環境変数として参照してください。
export HF_TOKEN="新しいトークン"
Pythonでは、環境変数から取得します。
import os
token = os.environ["HF_TOKEN"]
headers = {
"Authorization": f"Bearer {token}",
}
ローテーション後は、次の2段階で確認します。
- 新しいトークンでリクエストを実行し、成功することを確認する
- 古いトークンで同じリクエストを実行し、
401または403になることを確認する
Hugging Face Inference APIを開発中に呼び出す場合、Apidogではトークンを環境変数として保存し、リクエスト時にベアラートークンとして渡せます。これにより、シークレットを保存済みリクエストへ残さず、ローテーション後も環境変数を1か所更新するだけで切り替えられます。基本認証とベアラートークンの比較も参照してください。
関連資料：OpenAIとHugging Faceの侵害に関する完全な詳細分析、Hugging Faceアクセストークンのドキュメント。
よくある質問
影響を受けていない場合でもローテーションする必要がありますか？
はい。Hugging Faceはすべてのユーザーにローテーションを推奨しています。インシデント後に、攻撃者がどの認証情報を読み取ったかを個別に確定できないためです。ローテーションのコストは比較的低く、「安全だろう」と仮定するリスクは高いといえます。
自分のトークンが他人に使われたかどうかは、どう確認できますか？
アクセストークン一覧、最近のコミット、組織の変更、請求、接続済みアプリケーションを確認してください。Hugging Faceは個人アカウントに対してトークン単位の完全な監査証跡を公開していないため、同じ環境に存在したトークンは疑わしいものとして扱い、ローテーションしてください。
ローテーションするとスクリプトは壊れますか？
新しいトークンへ更新するまで、一時的に失敗します。古いトークンを使用しているスクリプト、ノートブック、CIジョブ、デプロイ設定はすべて更新が必要です。用途ごとにトークンを分けていれば、影響範囲を限定しながら順番に切り替えられます。
read と fine-grained のどちらを使うべきですか？
個人的なダウンロードや単純な推論には read を使用できます。本番環境、CI/CD、チーム共有の用途では fine-grained を使用してください。必要なリポジトリや権限だけへアクセスを限定できるためです。
新しいトークンはどこに保存すべきですか？
シークレットマネージャーまたは環境変数に保存してください。ソースコード、ノートブックセル、共有ドキュメント、Dockerfile、Gitリポジトリには保存しないでください。トークン値は1か所で管理し、各アプリケーションから参照する構成にします。
Top comments (0)