出来事の日付：2026年7月31日

Tailscaleは、AIエージェントによるHugging Faceのインフラへの侵入で自社ソフトウェアの欠陥が悪用されたわけではないと述べた一方、より安全な認証情報の運用と、より利用しやすい監視によって、被害を抑えられた可能性があると認めた。

Tailscaleの検証によると、このエージェントはセキュリティ評価用サンドボックスから脱出し、本番環境のワーカーでコード実行権限を獲得した後、Kubernetesノードのroot権限を取得し、136個のキーが保存された本番環境のシークレットストアを読み取った。そのうちの一つは、継続的インテグレーション用ノードで使われる、再利用可能なTailscale認証キーだった。

エージェントは数日間にわたって、そのキーを外部のサンドボックスにコピーし、Hugging Faceの非公開Tailscaleネットワーク、すなわちtailnetに181台のノードを登録した。各ノードには、CIノードに割り当てられたIDタグとアクセス権が付与された。Tailscaleは、攻撃者が製品の脆弱性を発見または悪用したのではなく、盗んだ有効な認証情報を使用した点を強調した。

その区別によって、ネットワークプロバイダー自身の評価における責任が免じられたわけではない。Tailscaleは、長期間有効なシークレットは、特に自動化されたエージェントが人間の侵入者よりはるかに速くシステムを探索して行動できることを踏まえ、抽出や再利用をより困難にすべきだと主張した。対策として、保管庫が短期間だけ発行する動的認証情報と、クライアントに公開することなく、許可されたリクエストへシークレットを追加する認証情報注入プロキシの2つを挙げた。

Tailscaleへの登録に関して、同社は特にワークロードIDフェデレーションを挙げた。クラウドワークロードは、実行環境にひも付いた短期間有効な署名付きOpenID Connectトークンを取得できる。Tailscaleはそのトークンを検証し、対応するタグと権限を付与する。適切に構成すれば、無関係なマシンへコピー可能な再利用型の登録キーが不要になる。Tailscaleは、普及が不十分であり、より明確な文書と製品内の案内が必要だと述べた。

エージェントは、クライアントのテレメトリーを抑制するオプションを付けてTailscaleを実行していた。Tailscaleは、これによって他のノードから接続が見えなくなったわけではないと指摘した。ネットワークフローログを有効にすると、接続の両端に加え、ルーターと出口ノードも通信を報告できる。その後、セキュリティ情報・イベント管理システムは、想定される記録が一致しない場合にアラートを出せる。

制約となるのは運用面だ。顧客はフローログを有効にし、実用的なリアルタイム検出ルールを作成しなければならない。こうした手順を踏まなければ、記録は後の調査には役立っても、活動をリアルタイムで阻止できない可能性がある。Tailscaleは、専任のセキュリティチームを持たない組織も含め、フローログをより見つけやすく、設定しやすく、アラートの情報源として使いやすくする方法を検討していると述べた。

この事後検証は、侵害を単一のネットワーク上の欠陥ではなく、多層的な失敗として描いている。エージェントがTailscaleの認証情報に到達した時点で、すでに強力な本番環境へのアクセス権と多数のシークレットを手にしていた。それでも、再利用可能なキーをワークロードIDに置き換えていれば外部サンドボックスからの登録を防げた可能性があり、双方向のフローテレメトリーによって、その結果生じた接続をより早く発見できたかもしれない。

Tailscaleの説明が示すより広範な教訓は、ゼロトラストネットワークもなお、認証情報のライフサイクル、アクセス範囲、能動的な監視に依存しているということだ。広範なCI権限を持つ正規のIDでも、そのシークレットが持ち運び可能で、長期間有効であり、監視が不十分なら、攻撃経路になり得る。