OpenCode, 17 Ekim 2026'da Console ürününde bir güvenlik ihlali yaşandığını ve bazı kullanıcıların kaydettiği OpenAI, Anthropic ve Google API anahtarlarının açığa çıkmış olabileceğini duyurdu. OpenCode Console ihlali, Fireworks AI'ın kendi güvenlik olayını açıklamasından yalnızca günler sonra geldi. İkisi birlikte rahatsız edici bir gerçeği hatırlatıyor: AI sağlayıcı anahtarlarınızı saklayan her platform, başkasının sizin hesabınızdan harcama yapabileceği bir kapı. Ekibiniz bir coding agent'a, LLM gateway'ine ya da evaluation aracına API anahtarı yapıştırdıysa harekete geçmenin zamanı bu hafta.

OpenCode Console ihlalinde ne oldu?

Safeguard ve DEV Community'nin aktardığı X paylaşımına göre OpenCode, ihlalin OpenCode Console kullanıcılarının %1,4'ünü etkileyen “büyük ölçekli bir distillation saldırısı” ile bağlantılı olduğunu söyledi. Etkilenenler, harici sağlayıcı bağlamış kullanıcıların bir alt kümesi ve kendilerine e-posta ile bildirim yapıldı. Şirket, olayın hâlâ sürdüğünü, bu yüzden daha fazla ayrıntı paylaşamadığını ama Anthropic, OpenAI ve Google ile birlikte çalıştığını belirtti.

Safeguard'ın aktardığı müşteri e-postasında ise saldırganların, OpenCode'un devreden çıkarmakta olduğu eski (legacy) bir sisteme yetkisiz erişim sağladığı ve workspace'lerde kayıtlı üçüncü taraf sağlayıcı anahtarlarının açığa çıkmış olabileceği yazıyor. Kullanıcılardan anahtarları ilgili sağlayıcının panelinden iptal edip yenilemeleri, bu anahtarları kullanan uygulamaları güncellemeleri ve son kullanım kayıtlarını beklenmedik hareketlere karşı incelemeleri istendi.

Kapsamı anlamak için birkaç ayrıntı önemli:

  • Console anahtarları OpenCode sunucularında duruyordu. Console, ekip üyelerinin sağlayıcı anahtarını hiç görmeden modelleri kullanabilmesi için tasarlanmış; yani anahtar merkezi olarak OpenCode'da tutuluyor.
  • CLI'daki yerel anahtarlar farklı bir durum olabilir. DEV Community'deki analizin belirttiği gibi CLI'da /connect ile eklenen anahtarlar kullanıcının kendi makinesinde, ~/.local/share/opencode/auth.json dosyasında saklanıyor. OpenCode bu olayda yerel anahtarlarla ilgili bir açıklama yapmadı.
  • Anthropic harekete geçti. Anthropic, etkilenen Claude API anahtarlarını iptal ettiğini açıkladı. OpenCode, OpenAI ve Google ile de birlikte çalıştığını söylüyor; incelediğimiz haberlerde bu iki şirketin kendi attığı bir adım yer almıyor.

Zarar raporları şimdilik bireysel kullanıcı beyanlarından ibaret ve OpenCode tarafından doğrulanmadı; yine de riskin boyutunu gösteriyor. Dealroom'un derlediği X paylaşımlarında bir kullanıcı OpenAI anahtarından 281, Anthropic anahtarından 168 dolar harcandığını, bir diğeri kaybını 1.700 dolar olarak açıkladı; bir üçüncüsü de erişimi kesmeden önce 700 doları aşan OpenAI kullanımı gördü. Kurucu ortak Dax Raad da kişisel hesaplarının artık saldırı altında olduğunu paylaştı.

Tek seferlik bir olay değil: başkasının anahtarını tutan platformlar

OpenCode büyük bir hedef. Şirketin açıklamasına göre açık kaynak agent'ını her ay 16 milyon geliştirici kullanıyor ve 75'ten fazla sağlayıcının modellerine bağlanabiliyor. Ama asıl ders tek bir firmayla değil, mimariyle ilgili.

Fireworks AI'ın güvenlik bülteni, şirket içi kimlik bilgilerinin yetkisiz kullanımını ve sınırlı sayıda müşteri hesabında evaluation işlerinde kullanılan environment variable'lara erişimi anlatıyor. Dealroom'a göre Fireworks hareketliliği 6 Ekim'de fark etti ve bülteni 9 Ekim'de yayımladı. Bültende her ekibin aklında tutması gereken bir uyarı var: Bir platformdan kayıtlı secret'ı silmek, asıl kimlik bilgisini geçersiz kılmaz. Bunu yalnızca anahtarı üreten sağlayıcı yapabilir.

Bağlam da önemli. Anthropic 12 Ekim'de, yeni savunmalarının distillation yapanların Claude'dan topladığı veriyi yaklaşık %90-99 oranında azalttığını açıkladı ve bu saldırıları genellikle sahte hesap ağları üzerinden yürütülen endüstriyel ölçekli kampanyalar olarak tanımladı. Bizim yorumumuz (doğrulanmış bir bağlantı değil): Sahte hesap açmak zorlaştıkça, üçüncü taraf araçlarda saklanan gerçek müşteri anahtarları daha cazip bir hedef hâline geliyor. Bu tür olayların tekrarlanacağını varsayarak plan yapın.

AI API anahtarları neden doğrudan para harcayan secret'lardır?

Ekiplerin çoğu AI API anahtarını sıradan bir konfigürasyon değeri gibi görüyor: Üret, araca yapıştır, unut. Bu alışkanlık artık pahalı. Ham bir sağlayıcı anahtarı, pratikte bir ödeme aracı ve hesabınızın sağlayıcı nezdindeki itibarı demek. Sızdığında şunları kaybedebilirsiniz:

  • Para: Doğrudan hesabınıza faturalanan kullanım.
  • Erişilebilirlik: Sağlayıcı projeyi kötüye kullanım gerekçesiyle askıya alabilir.
  • Hesabın kendisi: Sağlayıcı yaşananı kullanım koşulları ihlali olarak değerlendirebilir.

Sadece izlemek yetmez. Safeguard'ın da vurguladığı gibi harcama bildirimi size bir eşiğin aşıldığını söyler; hiçbir anahtarı iptal etmez. E-posta uyarısından fazlasına, yani limitlere ve hızlı rotasyona ihtiyacınız var.

Bu hafta yapılması gerekenler

Bu hafta için bir kontrol listesi:

1. Ham anahtarın durduğu her yeri envanterleyin

Sağlayıcı anahtarı tutan her SaaS aracını, coding agent'ı, LLM gateway'ini, evaluation platformunu ve CI pipeline'ını listeleyin. Artık kullanmadığınız araçları da ekleyin; OpenCode'daki anahtarlar zaten emekliye ayrılmakta olan bir sistemde duruyordu.

2. Her araca ayrı anahtar ve harcama limiti

Tek bir anahtarı birden fazla araçta paylaşmayın. Her entegrasyon için ayrı anahtar üretin ve sağlayıcı tarafında bu anahtara harcama limiti tanımlayın. Bir sızıntı olduğunda hangi anahtarı iptal edeceğinizi bilirsiniz, zararın da bir tavanı olur.

3. Rotasyonu doğru sırayla yapın

Önce eski anahtarı silmek kesintiye yol açar. Güvenli sıra şöyle:

  1. Sağlayıcıda yeni anahtarı oluşturun.
  2. Anahtarı kullanan tüm uygulama ve araçlara dağıtın.
  3. Trafiğin yeni anahtarla sorunsuz aktığını doğrulayın.
  4. Eski anahtarı sadece üçüncü taraf araçta değil, sağlayıcıda iptal edin.
  5. Son kullanım ve fatura kayıtlarında tanımadığınız hareketleri kontrol edin.

OpenCode Console'u bağlı sağlayıcılarla kullandıysanız, e-posta gelmiş olsun ya da olmasın bu adımları şimdi uygulayın.

4. Sistemi kapatırken secret'larını da kapatın

Bir aracı ya da servisi emekliye ayırırken anahtarlarını sağlayıcıda iptal etmek, kapatma sürecinin zorunlu bir adımı olmalı. Saldırgan gözünde canlı kimlik bilgisi taşıyan “legacy” bir sistem hâlâ production sistemidir.

Azure'da anahtarsız kimlik doğrulama: Entra ID

En sağlam çözüm, çalınacak bir anahtarın hiç olmaması. Microsoft'un Foundry dokümantasyonu, production iş yükleri için conditional access, managed identity ve en az yetki prensibine dayalı RBAC sağlayan Microsoft Entra ID'yi öneriyor. API anahtarlarının zayıf yanlarını da açıkça sıralıyor: Kaynağa tam erişim veriyorlar, belirli kullanıcı veya işlemlerle sınırlandırılmaları zor ve güvende kalmaları için elle rotasyon gerektiriyorlar.

Managed identity ve kaynak üzerinde en az yetkili bir rol ataması ile uygulamanız, konfigürasyonunda hiçbir secret olmadan modelleri çağırabilir:

from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI

# Azure'da managed identity, lokalde geliştirici oturumu
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
)

client = AzureOpenAI(
    azure_endpoint="https://my-ai-services.openai.azure.com/",
    azure_ad_token_provider=token_provider,
    api_version="2024-10-21",
)

Ardından anahtarla kimlik doğrulamayı kapatın ki sızan bir anahtar işe yaramasın. Bicep'te disableLocalAuth değerini true yapmanız yeterli:

resource aiServices 'Microsoft.CognitiveServices/accounts@2023-05-01' = {
  name: 'my-ai-services'
  location: location
  kind: 'AIServices'
  sku: {
    name: 'S0'
  }
  properties: {
    customSubDomainName: 'my-ai-services'
    disableLocalAuth: true
  }
}

Bunu kaynak kaynak uğraşmak yerine tüm ortamda zorunlu kılmak için “Azure AI Services resources should have key access disabled (disable local authentication)” Azure Policy tanımını subscription ya da resource group seviyesinde atayın. İki pratik not:

  • Kesme anında gerçekleşmiyor. Microsoft'a göre değişikliğin yayılması genellikle birkaç dakika sürüyor ama bölgeye, yüke ve gateway önbelleğine bağlı olarak birkaç saati bulabiliyor. Bunu acil durum anahtarı gibi kullanmayın; anahtarları da mutlaka yenileyin.
  • Birçok üçüncü taraf araç hâlâ anahtar istiyor. Coding agent'lar ve gateway'ler çoğu zaman yalnızca ham anahtar kabul ediyor. Bunlar için her araca ayrı, limitli bir anahtar tutun; mümkünse kimlik bilgisini lokalde saklayan ya da kimlik tabanlı doğrulamayı destekleyen araçları tercih edin.

Öne çıkanlar

  • OpenCode 17 Ekim'de Console'da saklanan sağlayıcı anahtarlarının açığa çıkmış olabileceğini duyurdu; etkilenen kullanıcılar anahtarlarını her sağlayıcıda iptal edip yenilemeli.
  • Fireworks AI olayıyla birlikte düşünüldüğünde, anahtarınızı saklayan her platform hem saldırı yüzeyinizi hem fatura riskinizi büyütüyor.
  • Bir araçtaki anahtarı silmek onu geçersiz kılmaz; iptal yalnızca sağlayıcıda yapılabilir.
  • Her araca harcama limitli ayrı bir anahtar verin; rotasyonda önce yeni anahtarı devreye alın, sonra eskisini iptal edin.
  • Azure'da managed identity ile Entra ID'yi tercih edin ve disableLocalAuth ayarını Azure Policy ile zorunlu kılın.
  • Bir sistemi emekliye ayırırken tuttuğu secret'ları da mutlaka iptal edin.