GitHub’ın iç AI harness’ı Microsoft Foundry’ye açılıyor

GitHub’ın Copilot servislerini yönetmek için içeride geliştirdiği AI harness yakında Microsoft Foundry kullanıcılarına açılıyor. Duyuru GitHub Universe’te yapıldı. Microsoft Copilot harness adlı katman agent isteklerini birden fazla model arasında yönlendiriyor ve tamamen Microsoft’un yönetiminde çalışıyor.

Microsoft Foundry nedir, ne işe yarar?

Microsoft Foundry, Microsoft’un Azure üzerinde çalışan yapay zekâ uygulama ve agent geliştirme platformudur. Ekipler burada farklı sağlayıcıların modellerini seçiyor, agent’ları kurum verisine ve tool’lara bağlıyor, deployment ile izleme işlerini tek yerden yürütüyor. Daha önce Azure AI Foundry ve Azure AI Studio adlarıyla biliniyordu. Benzer işi gören alternatifler arasında AWS tarafında Amazon Bedrock, Google tarafında Vertex AI var.

Harness katmanı neden asıl mesele

Bir agent’ın davranışını çoğu zaman model değil, etrafındaki katman belirliyor. Hangi tool çağrılacak, hangi veriye erişilecek, saatler süren bir görev nerede kaldı: bunların hepsi harness’ın işi. Kaynak bu katmanı, modellerin kurum verisine nasıl bağlandığını kontrol eden bir middleware olarak tarif ediyor.

GitHub bu katmanı kendi Copilot ürünleri için kurdu. Şimdi aynı katman Microsoft Foundry müşterilerine yönetilen hizmet olarak açılıyor. Kendi agent orkestrasyonunu yazmayı düşünen platform ekipleri için ortaya bir “satın al” seçeneği çıkıyor.

Microsoft Foundry’de yönetilen harness ne getiriyor

Duyurudaki somut iddialar şunlar:

• Agent istekleri birden fazla model arasında yönlendirilebiliyor. Tek model sağlayıcısına bağlı kalmamak için kullanışlı bir özellik.
• Hizmet tamamen Microsoft’un yönetiminde. Harness’ın kendisini güncellemek ve korumak sizin işiniz olmaktan çıkıyor.
• Hedef, tool kullanan ve uzun süren görevleri tamamlayan agent’lar.

Kaynak, güvenlik konusunda bilinçli bir çekince koyuyor: müşterilerin harness’ın güvenliğiyle uğraşmaması gerektiğini “teorik olarak” söylüyor. Bu ayrım önemli. Yönetilen harness, agent’a verdiğiniz yetkilerin kapsamını sizin yerinize daraltmaz. Agent’ın okuyabildiği repository’ler, çağırabildiği API’ler ve taşıdığı token’lar yine sizin kararınız.

Lock-in modelden hyperscaler’a taşınıyor

Nadella bu yıl kurumları model şirketlerine aşırı bağımlılık konusunda uyardı. Ama model katmanındaki bağımlılıktan kaçarken harness katmanında tek bir hyperscaler’a bağlanmak da bir lock-in türü. Kaynak da aynı noktayı vurguluyor.

Çıkış maliyeti burada birikir. Agent tanımlarınız, tool bağlantılarınız, yetki eşlemeleriniz ve log formatınız harness’a göre şekillenir. Model değiştirmek bir yapılandırma satırı olabilir; harness değiştirmek ise bir taşıma projesi.

Aynı hafta çıkan duyurular alternatif yolları da gösteriyor:

• Akamai Inference, 12 açık modeli OpenAI-compatible API’ler üzerinden sunuyor. Inference (çıkarım) tarafını açık modellere taşımak isteyen ekipler için bir seçenek.
• Akamai Agent Sandbox, agent’ları izole çalıştırmayı hedefliyor.
• Monte Carlo’nun Bayes aracı agent observability (gözlemlenebilirlik) için geliyor ve döngüye giren agent’lara müdahale edebildiğini söylüyor.
• Rasa’nın CTO’su kuralları prompt yerine kodda tutmayı savunuyor.

Bunlar birbirinin yerine geçmiyor. Ama harness’ı tek bir sağlayıcıdan almak zorunda olmadığınızı gösteriyorlar.

Değerlendirmeye başlamadan önce

Hizmetin genel kullanıma açılış tarihi ve fiyatı kaynakta yok. Bu süreyi hazırlık için kullanabilirsiniz:

1. Agent tanımlarını repository’de tutun. Prompt’lar, tool listeleri ve kurallar sürüm kontrolünde olsun; harness’a özgü yapılandırmayı ayrı ve ince bir katmanda bırakın.
2. Model çağrılarını tek bir arayüz arkasında toplayın. OpenAI-compatible bir arayüz kullanıyorsanız Foundry ile açık model servisleri arasında geçiş daha ucuz olur.
3. Log’ların dışarı akışını sorun. Hangi agent hangi tool’u ne zaman çağırdı, hangi görev takıldı; bu veriyi kendi observability yığınınıza aktaramıyorsanız harness’tan çıkış zorlaşır.
4. Yetki envanteri çıkarın. Agent’ın erişeceği her veri kaynağı için en dar yetkiyi tanımlayın, uzun ömürlü token yerine kısa ömürlü kimlik bilgisi tercih edin.

Binance olayı agent yetkileri için uyarı

Aynı bülten bir olayı daha aktarıyor. Binance’te tek bir DevOps mühendisinin ele geçirilen dizüstü bilgisayarı, 6,3 milyar dolarlık kripto hırsızlığının ilk giriş noktası olarak görünüyor. Binance saldırıyı “karmaşık” olarak tanımladı ve ek ihlal noktalarından söz etti.

Bağlantı şu: agent’lar ve harness’lar CI/CD sistemlerine, bulut hesaplarına ve repository’lere erişen geniş yetkili kimlik bilgileri taşıyacak. Bu kimlik bilgileri bir mühendis makinesinden ya da bir agent yapılandırmasından sızarsa etki alanı bir insan hesabından daha geniş olabilir. Foundry pilotuna başlamadan önce agent’ların kullanacağı service account’ları ayrı tanımlayın ve insan hesaplarıyla paylaşmayın.