Vercel AI SDK harness katmanı, kodlama agent'ları için yerel abonelik kimlik doğrulaması ekledi

Şirketin blogunda yayımlanan bir changelog yazısına göre Vercel, AI SDK'sının harness katmanına yerel abonelik kimlik doğrulaması ekledi. Harness katmanı, farklı kodlama agent'larını tek bir HarnessAgent arayüzü arkasında çalıştıran soyutlamadır; yeni özellik, agent'ın kendisi abonelik girişini desteklediği yerlerde, bu agent'ların geliştiricinin elinde zaten bulunan abonelikler üzerinden doğrulanmasını sağlıyor.

Vercel'e göre özellik kod değişikliği ya da yeni ayar gerektirmiyor; harness katmanını zaten kullanan uygulamalar bunu otomatik olarak devralıyor.

Kimlik doğrulama modları nasıl davranıyor

Harness katmanı üç kimlik doğrulama modu sunuyor ve her biri yerel abonelikleri farklı şekilde ele alıyor. Direct modunda SDK önce ortamda açık sağlayıcı kimlik bilgilerini arıyor ve hiçbiri bulunmazsa, ana makinede keşfedilen yerel bir aboneliğe geri düşüyor. Varsayılan olan auto modu da aynı deseni izliyor, ancak yalnızca AI Gateway kimlik bilgileri ayarlanmamışsa. ai-gateway modu ise üçünün en katısı: Vercel'e göre bu mod asla yerel abonelikleri okumuyor ve kimlik doğrulamayı gateway üzerinden yönlendiriyor.

Pratik sonucu şu: bir kodlama aracına abonelik, kullanılabilir bir kimlik bilgisine dönüşüyor. Uygulamanın çağırabileceği her agent için ayrı bir API anahtarı oluşturup döndürmek yerine, mevcut plan bu işi görüyor.

Hangi agent'lar kapsanıyor

Vercel, yerel abonelik girişinin geçerli olduğu dokuz harness adaptörü listeliyor: Claude Code, Cline, Codex, Cursor, fx, GitHub Copilot, Grok Build, OpenCode ve Pi. Tek kısıt, altta yatan harness'ın abonelik girişini kendisinin sunması gerekliliği; SDK katmanı, bir agent'da bu yetenek yoksa onu ekleyemiyor. Vercel, ayrıntılar için okuyucuları harness dokümantasyonuna yönlendiriyor.

Kimlik bilgileri ana makinede kalıyor

Kimlik bilgisi yönetimi, SDK'nın API anahtarlarına zaten gösterdiği yaklaşımı yansıtıyor. Abonelik kimlik bilgileri ana makinede kalıyor, çözümleme ana makine sınırında gerçekleşiyor ve OAuth erişim token'ları gerektiğinde orada yenileniyor. Agent süreçleri token yaşam döngülerini kendileri yönetmiyor.

Sandbox içinde yürütme için ise ek bir yalıtım adımı var. Vercel'in açıkladığı gibi, sandbox bunu desteklediğinde harness'a yalnızca yer tutucu kimlik bilgileri veriliyor ve gerçek token, istekler ana makineyi geçerken giden isteklere enjekte ediliyor. Böylece canlı token'lar hiçbir zaman sandbox ortamının içinde bulunmuyor.

Neden önemli

Bu değişiklik, harness katmanının merkezî vaadini güçlendiriyor. HarnessAgent arayüzü, ekiplerin kodlama agent'ları arasında uygulama kodunu yeniden yazmadan geçiş yapabilmesi için var; kimlik doğrulama ise her sağlayıcının kendi anahtar yönetimini getirdiği için bu geçişte sıkça sürtünme noktası oluyordu. Kimlik doğrulamayı aboneliklerin üstlenmesiyle, bir agent'ı değiştirmek bir entegrasyon projesinden çok yapılandırma tercihine yaklaşıyor; bu da agent'ları kıyaslamak ya da aynı uygulamada birleştirmek maliyetini düşürüyor.

Güvenlik tasarımı da agent'ları sandbox altyapısında çalıştıranlar için dikkat çekici. Gerçek token'ları ana makinede tutup yalnızca istek sınırında enjekte etmek, sandbox içindeki bir süreç ele geçirilirse ya da ortamını sızdırırsa etki alanını daraltıyor.

Daha geniş bakışla, bu özellik agent araçlarının nereye gittiğinin sinyalini veriyor. Kodlama agent'larının sayısı arttıkça, agent'ların nasıl çağrıldığını, doğrulandığını ve sandbox'landığını standart hale getiren katmanlar, onları üretime taşımanın kontrol noktasına dönüşüyor ve Vercel, AI SDK harness katmanını bu soyutlama olarak konumlandırıyor.