Claude API kullanıcı profilleri tek bir müşteriyi kısıtlayabiliyor, tüm organizasyonunuzu değil — ama webhook'lar hâlâ sessiz

Anthropic ne yayınladı

20 Ekim'de Anthropic, Claude API için kullanıcı profillerini duyurdu; bu mekanizma bir platformun ilettiği her isteğe bir kimlik iliştirmesini sağlıyor ve böylece güvenlik yaptırımları, API anahtarını elinde tutan organizasyon yerine tek bir son müşteriyi hedefleyebiliyor. Bir gün sonra, dev.to'da yayımlanan bir yazıya göre şirket, bu profillerde yaptırım durumunu gösteren alanlar ekledi.

Bu değişiklik, Claude'u yeniden satan ya da ürününe gömeli kullanan herkes için yapısal bir riski ele alıyor. Şimdiye kadar bir SaaS uygulaması, gateway veya satıcı tüm müşteri trafiğini tek bir organizasyon altında gönderiyordu ve Anthropic'in kendi dokümantasyonu da kötü davranan tek bir son müşterinin tüm organizasyona karşı yaptırım tetikleyebileceğini, diğer tüm müşterileri de beraberinde düşürebileceğini kabul ediyordu.

Profiller nasıl çalışıyor

Platform, son müşteri başına ayrı bir uç nokta üzerinden bir profil oluşturuyor ve uprof_ önekiyle başlayan bir tanımlayıcı alıyor. Bu tanımlayıcı, müşteri adına yapılan her istekte anthropic-user-profile-id başlığıyla ya da SDK argümanı olarak taşınıyor. Kaynağın aktardığına göre Anthropic'in dokümanları profillerin ücretsiz olduğunu, konuşma içeriği içermediğini ve gönderilen bilgilerin doğrulanmadığını söylüyor.

İki tür profil var. Varsayılan olan uygulama profilleri, kendi ürününüzün kullanıcılarına uygun. Passthrough profilleri ise erişimi yeniden sattığınız şirketler için tasarlanmış; çalışan başına değil şirket başına bir profil oluşturuluyor. Profil ID'si olmadan gönderilen istekler platformun kendi kullanımı sayılıyor ve Anthropic, profiller bir workspace'e değil bir organizasyona ait olduğu için bu trafiğin ayrı bir organizasyonda izole edilmesini öneriyor. Tanımlayıcı, token sayımı, mesaj batch'leri ve OpenAI SDK uyumluluk uç noktasında da çalışıyor.

Sıkıntı çıkarabilecek ayrıntılar

dev.to yazısı beş tuzak sıralıyor. Profil oluşturma idempotent değil: referans tanımlayıcı mevcut bir profille eşleşse bile her çağrı yeni bir profil üretiyor; bu yüzden ID, onboarding sırasında bir kez üretilip saklanmalı. Bir istek hâlâ user-profiles-2026-09-04 veya daha eski bir beta başlığı taşıyorsa, yanıtlar yaptırım alanlarını içermiyor ve durum filtresi 400 döndürüyor. Amazon Bedrock ve Google Cloud'un yönetilen Claude'unda yalnızca ID'nin biçimi denetleniyor; yani iyi biçimli ama var olmayan bir ID kabul ediliyor. Bedrock'un eski InvokeModel ve Converse yolları profilleri hiç desteklemiyor ve orada ID, başlık yerine istek gövdesine konuyor. AWS üzerindeki Claude Platform'da ise yaptırım durumu her zaman unrestricted olarak görünüyor ve açık bir action nedeniyle istekler hiçbir zaman reddedilmiyor. Son olarak alanlar değiştirilebiliyor ama asla temizlenemiyor; null değerler 400 hatasıyla sonuçlanıyor ve yer tutucular kalıcı oluyor.

Yaptırımı okumak ve ona tepki vermek

Her profil unrestricted, restricted veya banned durumunu bildiriyor; kimlik denetimi sürerken pending değeri de dokümante edilmiş. Action'lar bir tür, fraud_or_abuse veya account_compromise gibi bir neden, müşteri için isteğe bağlı bir talimat ve isteğe bağlı bir bitiş zamanı taşıyor. Bir action açık kaldığı sürece Anthropic, o profil ID'si için çıkarımın bir kısmını ya da tamamını reddediyor; diğer trafik dokunulmadan kalıyor. Dokümanlar ayrıca güvenli şekilde başarısız olmayı öneriyor: bilinmeyen her durumu restricted, bilinmeyen her nedeni unspecified olarak ele alın.

Sessiz kalan bir webhook

Anthropic ayrıca organizasyon webhook'larını webhooks-2026-10-07 başlığının arkasında beta olarak açtı; yaptırım action'larının açılması ve çözülmesi için event'ler tanımladı ve erişim bir hesap ekibi üzerinden veriliyor. Sorun şu ki teslimat henüz etkin değil: uç noktalar bugün kaydedilebiliyor ama hiçbir şey almıyor; bu yüzden pratik yol, profilleri yaptırım durumuna göre filtreleyip sonuna kadar sayfalayarak listeyi yoklamak ve yaptırım alanlarını karşılaştırmak — çünkü durum değişikliği kaydın zaman damgasını güvenilir biçimde güncellemiyor.

Teslimat devreye girse bile dokümanlar uyarıyor: event'ler yalnızca ID taşıyor, birden fazla kez, geç ya da sıra dışı gelebiliyor, kısa süre yeniden deneniyor ve sonra bırakılıyor; kayıttan önce açılan action'lar ve profil silinerek kapatılan action'lar için hiç tetiklenmiyor. Teslimatlar Standard Webhooks belirtimini izliyor; yani uç noktalar imzaları doğrulamak ve hızla 2xx yanıtı vermek zorunda.

Neden önemli

Paylaşımlı anahtar mimarileri, platformları en kötü müşterilerinden dolayı topluca sorumlu tutuyordu. Müşteri başına profiller yaptırımı doğru ayrıntı düzeyine taşıyor ve bu, birçok kiracı genelinde üretim agent'ları çalıştırmak için neredeyse bir ön koşul. Webhook teslimatı açılana kadar ve AWS'de barındırılan Claude'daki düzensiz yaptırım raporlaması göz önüne alındığında, ekipler yoklamayı gerçek bilgi kaynağı olarak görmeli ve müşteri isteklerinin belirsiz biçimde başarısız olmasına izin vermek yerine, kısıtlama nedenlerini kendi ürünlerinde görünür kılmalı.