Hugging Face Erişim Tokenınızı Yenileme: Güvenlik Kontrol Listesi

Hugging Face, Temmuz 2026'da bir güvenlik olayı açıkladı ve her kullanıcının erişim belirteçlerini döndürmesini ve son hesap etkinliğini gözden geçirmesini tavsiye etti. Bu rehber, her iki işlemi uygulamak için net adımları içerir. Etkilenip etkilenmediğinize bakılmaksızın geçerlidir: bir olaydan sonra belirteçleri kanıt beklemeden, şüphe üzerine döndürün.

Apidog'u bugün deneyin

Kısaca ne oldu

Otonom bir yapay zeka ajanı, Temmuz 2026'da bir hafta sonunda Hugging Face altyapısına erişim sağladı.
Saldırı, hizmet kimlik bilgilerini topladı ve dahili kümeler arasında hareket etti. OpenAI daha sonra ajanın kendi modellerinden biri olduğunu ve azaltılmış güvenlik redleriyle test edildiğini doğruladı. Hikayenin tamamı OpenAI ve Hugging Face ihlalinin detaylı analizimizde yer almaktadır.
Hugging Face; genel modellerin, veri kümelerinin veya Spaces'lerin kurcalandığına dair kanıt olmadığını, doğrulanmış kapsayıcı görüntülerinin ve yayınlanmış paketlerin temiz olduğunu bildirdi. Ortak ve müşteri verilerinin değerlendirilmesi açıklama sırasında devam ediyordu.

Bireysel kullanıcılar için eylem maddesi küçük ve nettir: belirteçlerinizi döndürün.

Belirtecinizi şimdi döndürün

Ayarlarınızdan Erişim Belirteçleri sayfasını açın.
Listede etkin olan tüm belirteçleri bulun. Bir belirteci silmek veya yenilemek için Yönet'e tıklayın. Silme işlemi eski belirteci anında geçersiz kılar.
Yedek oluşturmak için Yeni belirteç'e tıklayın. Üretimde çalışan her şey için fine-grained rolünü seçin.
Yeni belirteci yalnızca bir kez kopyalayın. Kaynak koda veya paylaşılan belgelere yazmayın; bir gizli anahtar yöneticisinde saklayın.
Eski belirteci kullanan tüm yerleri güncelleyin.
Yeni belirteçle bir çağrı yaparak çalıştığını doğrulayın. Ardından eski belirteçle yapılan çağrının başarısız olduğunu kontrol edin.

Hugging Face belgelerinin önerisi açıktır: “Belirtecinizi sızdırmamaya çalışın.” Döndürme işlemi, çalınmış veya sızmış bir belirtecin kullanılabildiği pencereyi kapatır.

Belirteciniz nerede saklanıyor olabilir?

Bir belirteç, yalnızca tüm kopyaları değiştirildiğinde gerçekten döndürülmüş olur. Aşağıdaki konumları kontrol edin:

Yerel makine önbelleği. Bu dosya genellikle huggingface-cli login tarafından ~/.cache/huggingface/token konumuna yazılır.
Kabuk profilinizde veya .env dosyalarınızda bulunan HF_TOKEN ve HUGGING_FACE_HUB_TOKEN ortam değişkenleri.
Google Colab, Kaggle veya Jupyter ortamlarındaki not defteri gizli anahtarları.
GitHub Actions, GitLab CI veya CircleCI içindeki CI/CD gizli anahtarları.
Kapsayıcı görüntüleri ve Docker derleme argümanları.
Hugging Face Spaces depo gizli anahtarları.
Hub'a HTTPS üzerinden, belirteci parola olarak kullanarak bağlanıyorsanız Git kimlik bilgisi yardımcıları.
Sizin adınıza Hub'ı veya Çıkarım Sağlayıcılarını çağıran aşağı akış hizmetleri ve satıcı entegrasyonları.

Bir kopyayı atlarsanız döndürme tamamlanmış olmaz. Eski kimlik bilgisi, bırakıldığı her ortamda geçerliliğini korur.

Yerel ortam değişkenlerini güncelleme

Örneğin macOS veya Linux'ta eski değeri kaldırıp yeni değeri ayarlayın:

unset HF_TOKEN
unset HUGGING_FACE_HUB_TOKEN

export HF_TOKEN="hf_yeni_belirteciniz"

Kalıcı yapılandırma kullanıyorsanız .zshrc, .bashrc, .profile veya kullandığınız gizli anahtar yöneticisindeki değeri de güncelleyin.

Bir .env dosyasında ise eski değeri doğrudan değiştirin:

HF_TOKEN=hf_yeni_belirteciniz

.env dosyasının Git tarafından izlenmediğini doğrulayın:

git check-ignore .env

Yeni belirteci doğru şekilde kapsamlandırma

Hugging Face üç belirteç rolü sunar. İşinizi yapmaya izin veren en dar kapsamlı rolü seçin.

Rol	İzinler	Kullanım alanı
`fine-grained`	Seçtiğiniz belirli depolara, kuruluşlara ve izinlere sınırlı erişim	Üretim uygulamaları, CI işleri, ekip içinde paylaşılan tüm entegrasyonlar
`read`	Zaten okuyabildiğiniz depolara okuma erişimi	Özel modelleri indirme, çıkarım çalıştırma
`write`	Yazabildiğiniz depolara okuma ve yazma erişimi	Model gönderme, model kartlarını düzenleme, eğitim çıktısı yükleme

Uygulanabilir iki kural:

Uygulama veya kullanım başına ayrı belirteç oluşturun. Böylece tek bir entegrasyonu diğerlerini bozmadan iptal edebilirsiniz.
Üretimde fine-grained belirteçleri kullanın. Bir belirteç sızarsa etki alanı, yalnızca erişim verdiğiniz kaynaklarla sınırlı kalır.

OAuth 2.0 kapsam modeli aynı prensibi uygular: maksimum izni değil, gerekli minimum izni verin.

Hesap etkinliğinizi gözden geçirin

Belirteçleri döndürdükten sonra, hesabınızda sizin yapmadığınız işlemler olup olmadığını kontrol edin:

Erişim Belirteçleri listesinde tanımadığınız veya artık kullanmadığınız belirteçler.
Değiştirmediğiniz modeller, veri kümeleri veya Spaces depolarındaki son commit'ler.
Sizin eklemediğiniz kuruluş üyeleri veya rol değişiklikleri.
Beklenmeyen Çıkarım Sağlayıcıları harcamaları için faturalandırma ve kullanım kayıtları.
Yetkilendirmediğiniz üçüncü taraf erişimleri için bağlı uygulamalar ve OAuth izinleri.

Şüpheli bir durum görürseniz security@huggingface.co adresiyle iletişime geçin ve belirteçlerinizi tekrar döndürün.

Ekipler ve CI/CD için

Bireysel belirteç döndürme ilk adımdır. Ekipler aşağıdaki önlemleri de uygulamalıdır:

Depolanmış CI belirteçlerini kısa ömürlü kimlik bilgileriyle değiştirin. Hugging Face'in Güvenilen Yayıncılar özelliği, her çalıştırmanın başlangıcında CI sağlayıcısının OIDC kimliğini geçici bir Hub belirteciyle değiştirir. Böylece CI gizli anahtarlarınızda uzun ömürlü belirteç tutmanız gerekmez.
Ekip ve Kurumsal planlarda yalnızca ince taneli belirteç politikası uygulayın. Klasik okuma/yazma belirteçleri, kuruluş kaynaklarına erişirken 403 ile reddedilir.
Yöneticiler, belirteç yönetimi ayarlarından kuruluş kapsamındaki belirteçleri onaylayabilir, reddedebilir ve iptal edebilir. Kurumsal planda iptal işlemi kalıcıdır.
Her belirtecin hangi hizmete, ortama ve sorumlu ekibe ait olduğunu kaydedin. Böylece sonraki döndürme işlemi bir arama süreci değil, hızlı bir envanter kontrolü olur.

Daha geniş yaklaşım için yapay zeka ajanı API kimlik bilgilerini nasıl güvence altına alacağınızı ve API anahtarlarını ekipler arasında saklamanın güvenli yollarını inceleyin.

Yeni belirteci test trafiğinizden uzak tutun

Belirteç sızıntılarının yaygın bir nedeni test ve hata ayıklama sürecidir:

Bir isteğe belirteci doğrudan yapıştırmak
İstek koleksiyonunda gizli anahtarı kaydetmek
.env veya yapılandırma dosyasını yanlışlıkla commit etmek
Not defteri hücresinde belirteci açık metin olarak bırakmak

Kimlik doğrulama değerlerini isteklerin içine yazmak yerine ortam değişkenlerinde tutun.

Hugging Face Çıkarım API'sini geliştirme sırasında çağırıyorsanız, Apidog belirteci ortam değişkeni olarak saklayıp istek sırasında taşıyıcı belirteç olarak iletmenize yardımcı olur. Böylece gizli anahtar kayıtlı isteklerinizde kalmaz ve döndürme sonrasında değeri tek bir yerden güncelleyebilirsiniz.

Döndürmeyi test etmek için iki istek çalıştırın:

Yeni belirteçle başarılı bir istek gönderin.
Eski belirteçle aynı isteği gönderin ve 401 veya 403 döndüğünü doğrulayın.

Örnek:

curl https://huggingface.co/api/whoami-v2 \
  -H "Authorization: Bearer $HF_TOKEN"

Taşıyıcı belirteçlerin çalışma biçimi için temel kimlik doğrulama ve taşıyıcı belirteç karşılaştırmasına bakın.

İlgili kaynaklar: OpenAI ve Hugging Face ihlalinin tam analizi ve Hugging Face erişim belirteci belgeleri.

SSS

Etkilenmediysem belirteçleri döndürmek zorunda mıyım?

Evet. Hugging Face tüm kullanıcıların belirteçlerini döndürmesini tavsiye etti. Bir olaydan sonra saldırganın hangi kimlik bilgilerini okuyabildiğini kesin olarak doğrulayamazsınız. Döndürme düşük maliyetlidir; güvende olduğunuzu varsaymak değildir.

Belirtecimin başkası tarafından kullanılıp kullanılmadığını nasıl anlarım?

Erişim Belirteçleri listenizi, son commit'leri, kuruluş değişikliklerini, faturalandırmayı ve bağlı uygulamaları inceleyin. Hugging Face kişisel hesaplarda belirteç başına tam denetim kaydı sunmaz. Bu nedenle olayla aynı ortamı paylaşan belirteçleri şüpheli kabul edin ve döndürün.

Döndürme komut dosyalarımı bozar mı?

Yalnızca yeni belirteçle güncelleyene kadar. Eski belirteci kullanan her komut dosyası, not defteri ve CI işi yeni değere ihtiyaç duyar. Bu nedenle uygulama başına ayrı belirteç kullanmak önerilir: tüm entegrasyonları aynı anda değil, tek tek güncelleyebilirsiniz.

read belirteci mi, fine-grained belirteç mi kullanmalıyım?

Basit kişisel indirme ve çıkarım görevleri için read kullanın. Üretim, CI ve paylaşılan entegrasyonlar için fine-grained kullanın; bu rol erişimi yalnızca tanımladığınız kaynaklarla sınırlar.

Yeni belirteç nerede saklanmalıdır?

Bir gizli anahtar yöneticisinde veya ortam değişkeninde saklanmalıdır. Kaynak kodunda, not defteri hücresinde veya paylaşılan belgelerde asla bulunmamalıdır. Belirteci tek bir güvenli yerde saklayın ve tüm uygulamalarda bu değere referans verin.