Coding agent kod tabanından çıkınca: Azure KARS ile çok runtime’lı AI agent altyapısı

Microsoft Developer Community Blog’da yayınlanan uzun bir yazı, coding agent’ların neden aslında en genel amaçlı agent runtime’ı haline geldiğini ve bunları bir departmana güvenle yaymak için nasıl bir altyapı gerektiğini anlatıyor. Merkezde, Azure Cloud Native ekibinin açık kaynak projesi Azure KARS (Agent Reference Stack for Kubernetes) var.

Yazının çıkış noktası basit bir e-posta. Bir üretim şirketinde çalışan, yazılımcı olmayan bir pazarlama yöneticisi, bir eğitimden Claude Code’u kurmuş. Amacı statik bir web sayfasını düzeltmekmiş. Sonra fark etmiş ki araç, bıraktığı düzinelerce Excel dosyasını okuyabiliyor, onları işleyen bir script yazabiliyor ve bir PowerPoint üretebiliyor. Haftalık bayi brifingini artık o hazırlıyormuş.

Ve dünyanın en sıradan sorusunu sormuş: “Bunu tüm departmanıma yayabilir miyiz?”

Coding agent neden sessizce iş agent’ına dönüştü?

Son iki yılda çoğumuz agent’ları tersinden kurduk: tool şemaları tanımla, function calling yaz, bir orkestratör kur, RAG bağla, prompt’ları ayarla. Bu yolun gizli bir öncülü var: kullanıcının ne yapacağını önceden bilmeniz gerekiyor, ki o yeteneği bir tool’a sarabilesiniz.

Claude Code CLI, GitHub Copilot CLI ve Codex CLI gibi coding agent’lar ters yönden geldi. Tasarım hedefleri “gerçek bir dosya sisteminde, gerçek bir komut satırı üzerinden gerçek bir yazılım görevini tamamlamak”tı. Bunun için dört yetenek edinmek zorunda kaldılar:

• Dosya sistemi birinci sınıf vatandaş. Agent’ın bir çalışma dizini var, dosya okuyup yazabiliyor. Bir geliştirici için bu “kod düzenlemek”, bir pazarlama yöneticisi için “on iki tablo bırakıyorum, sunum alıyorum” demek. Aynı yetenek, farklı bağlamda tamamen farklı bir ürün.
• Shell evrensel tool. Geleneksel bir agent her yeni yetenek için yeni bir tool tanımı gerektiriyor. Coding agent’ın tek bir nihai tool’u var: komut çalıştırmak. Böylece pandas, LibreOffice, curl, ffmpeg, Chromium, container’a koyabileceğiniz her şey otomatik olarak agent yeteneğine dönüşüyor. Araç setini genişletmek kod yazmaktan Dockerfile yazmaya kayıyor.
• Doğası gereği uzun görev makinesi. Kod yazmak istek/yanıt değil; planla, çalıştır, hatayı oku, düzelt, tekrar çalıştır. Bu döngü iş bağlamına taşındığında şöyle oluyor: veriyi oku, sütunların uyuşmadığını fark et, temizle, yeniden hesapla, grafik çiz, raporu yaz.
• Olgun eklenti protokolleri var. MCP onu dış sistemlere bağlıyor, Skills ise alan bilgisini öğretiyor. Tek bir SKILL.md dosyası “aylık raporumuz böyle görünür, tanımlar bunlar, feragatname ikinci sayfada” diyebiliyor, hiç kod yazmadan.

Yazarın vardığı sonuç net: coding agent runtime’ı iş agent’ına dönüştürülmedi, o zaten elimizdeki en genel amaçlı agent runtime’ı. Kod sadece ilk iniş alanıydı, çünkü kodun en temiz değerlendirme fonksiyonu var: çalışıyor mu? Ama altta yatan şekil, yani izole bir ortamda bir yığın tool kullanarak yinelemeli şekilde dosya üretmek, bilgi işinin çoğunu tarif ediyor.

Bir dizüstünden bir departmana: üç gerçek sorun

Bir dizüstü bilgisayar ile bir departman arasında, AI yeteneğiyle hiç ilgisi olmayan sorunlar var:

• Pazarlama yöneticisinin Claude Code’u kendi Mac’inde, kendi API anahtarıyla çalışıyordu ve izin istemlerini keyifle atlamıştı.
• Bazı çalışma arkadaşları Copilot CLI istiyordu çünkü şirketin GitHub Enterprise’ı var. Diğerleri Codex CLI istiyordu çünkü kendi barındırdıkları OpenAI uyumlu bir gateway kullanıyorlar.
• Güvenlik ekibinin tek bir sorusu vardı: “Bu şey keyfi komut çalıştırabiliyor ve ağa erişebiliyor. Bizim neyimize dokunabilir?”

Bu üç sorunun adları var: runtime çeşitliliği, credential yönetişimi ve blast radius. Azure KARS tam olarak bunları hedefliyor.

Azure KARS nedir?

KARS, Azure Kubernetes Service ve Azure Linux’u geliştiren Azure Cloud Native ekibi tarafından açık kaynak olarak geliştiriliyor. Kod GitHub’da Azure/kars deposunda.

Yazarın en başta söylediği cümle önemli: bu resmi olarak desteklenen bir Microsoft ürünü değil. SLA yok, destek sözleşmesi yok, ürün yol haritası taahhüdü yok. Bir referans implementasyon: okumak, mimarisini öğrenmek ve üzerine kendi yığınınızı kurmak için. CRD’ler v1alpha1 seviyesinde ve minor sürümler arasında değişebilir; veri yolu, güvenlik modeli ve denetim zinciri ise stabil.

KARS README’sindeki bir cümle projenin tezini özetliyor: bir AI agent’a gerçek tool’lar vermek, gerçek credential’lar ve gerçek bir ağ vermek demek. Production’da bu çok büyük bir blast radius, çünkü prompt injection’a uğramış tek bir agent Azure aboneliğinize, GitHub organizasyonunuza ve müşteri verinize ulaşabilir.

KARS’ın cevabı “agent’ın yapabileceklerini kısıtla” değil. Agent’ları diğer servislerinizle aynı operasyonel disiplinle çalıştırın. Bu fikri credential tarafından daha önce ele almıştık: AI agent’ın davranışını değil, erişebildiği şeyleri kontrol edin.

Temel tasarım: güven sınırı cluster değil, pod

KARS’ın en belirleyici yapısal kararı şu: her agent için sertleştirilmiş bir sandbox ve agent’ın kendine ait bir ağı yok.

Agent container’ı UID 1000 olarak çalışıyor ve kendi başına dışarıya çıkışı yok. Sadece aynı pod içinde localhost üzerinden inference router’a ulaşabiliyor. Pod’dan çıkan her byte o Rust router’dan geçiyor. NetworkPolicy ve egress-guard iptables init container’ı ise router bir şekilde atlatılırsa blast radius’u sınırlayan güvenlik ağları. Sonuç: agent’ı ele geçirmek cloud hesabını, modeli, denetim logunu veya peer mesh’i ele geçirmek anlamına gelmiyor.

Router güvenlik modelinin taşıyıcı duvarı. Farklı bir UID (1001) altında ayrı bir container olarak çalışıyor, agent’ın hiç görmediği credential’ları tutuyor ve şunların tek uygulama noktası:

Sık gelen itiraz: “Zaten bir API gateway’imiz var, bu gereksiz değil mi?” Yazarın cevabı hayır. Kuzey-güney yönlü bir gateway trafiği cluster sınırında yönetiyor. KARS router ise agent ile her şey arasında localhost’ta oturan pod içi bir politika noktası; agent’ın onu atlatan bir ağ yolu yok. İkisi farklı katmanlarda çalışıyor ve birbirini tamamlıyor.

Tek YAML, sekiz agent framework’ü

Runtime, KarsSandbox.spec.runtime.kind ile seçiliyor ve router, yönetişim, izolasyon ve denetim zinciri hepsinde aynı. Yerleşik runtime’lar:

• OpenClaw (varsayılan, TypeScript/Node)
• Hermes (Nous Research, Python)
• OpenAI Agents SDK
• Microsoft Agent Framework (Python; .NET ertelendi)
• LangGraph
• LangGraph.js
• Anthropic Claude Agent SDK
• Pydantic-AI
• Ve BYO (Bring Your Own): kendi imajınız, onların sözleşmesi

Yazar bu cümleyi depodaki en az takdir edilen cümle olarak görüyor, çünkü güvenlik incelemesi bir kez yapılıyor. Güvenlik ekibi LangGraph’ı, sonra Claude Agent SDK’yı, sonra CLI wrapper’ınızı ayrı ayrı incelemiyor; pod şeklini, CRD’leri ve denetim formatını inceliyor. Projenin kendi ifadesiyle: güvenlik ekipleri Python değil YAML inceler. Onay kapıları, hız limitleri, tool allowlist’leri, içerik güvenliği eşikleri, token bütçeleri ve güven topolojisi bildirimsel Kubernetes kaynakları; bir repoya commit ediliyor, Argo veya Flux ile uzlaştırılıyor, git log ile denetleniyor.

Tek zihinsel model, üç çalışma biçimi

Aynı CRD’ler, aynı router kod yolu, aynı denetim formatı. Yerelden AKS’e geçiş tek satırlık bir CLI değişikliği. Başlangıç da bir Kubernetes projesi için alışılmadık derecede kolay:

npm i -g @kars-runtime/cli
kars dev --release --target local-k8s

İlk çalıştırmada bir sağlayıcı seçiyorsunuz; KARS controller’ı, şifreli mesh’i ve sandbox’lanmış bir agent’ı yerel bir kind cluster’ında ayağa kaldırıyor. İmajlar çok mimarili (amd64 + arm64, Apple Silicon’da native) ve cosign ile imzalı. --release bunları çektiği için Rust derlemesi, klonlama veya build gerekmiyor.

BYO: coding agent CLI’ı sözleşmeye getirirken beş tuzak

Pazarlama yöneticisi OpenClaw veya LangGraph istemiyor; zaten kullanmayı bildiği CLI’ı istiyor. Bu BYO senaryosu ve insanların en çok zarar gördüğü yer. BYO’nun özü şu: platform size izolasyon ve yönetişim iskeletini veriyor, ama “agent gerçekte nasıl çalışıyor” sorusu yine size kalıyor.

Tuzak 1: “Başlıyor” ile “yönetiliyor”u karıştırmak. Dokümantasyon bu konuda açık: CLI’lar yapılandırılmış model servislerine hâlâ kendi native protokolleriyle ulaşıyor. Bir BYO entegrasyonu, token bütçesi, içerik güvenliği veya her native tool çağrısı için değerlendirme gibi KARS yeteneklerinin otomatik açıldığı anlamına gelmiyor. Container’ınız BYO sözleşmesinin imaj ve HTTP adaptör kurallarını mükemmel şekilde karşılayıp yine de model çağrılarını doğrudan internete gönderebiliyor. Yani ayağa kalkan bir pod, yönetilen bir pod değil.

Gerçek bir BYO benimsemesi şu sırayla ilerliyor:

1. Upstream KARS’ı deploy edin, controller.byoStrict=true‘yu açın ve runtime imajlarını kendi registry’nize itin.
2. Agent yapılandırmasını ve yazılabilir workspace’leri bağlarken ilgili CRD ve controller implementasyonunu takip edin.
3. Sıfır credential yönlendirmesine geçerken Claude ve Codex çıkarımını router’ın /anthropic ve /v1 endpoint’leri üzerinden yönlendirin.
4. Tam tool yönetişimi iddia etmeden önce her CLI tool çalıştırması için /agt/evaluate entegrasyonunu yapın ve MCP’yi /mcp üzerinden yönlendirin.
5. Copilot CLI’ın native token kimlik doğrulaması ve ağ trafiği için kontrollü egress ve proxy uyumluluğunu ayrıca doğrulayın.

Son madde vurgulanmayı hak ediyor. Copilot CLI, Claude ve Codex’ten farklı kimlik doğruluyor; bu bir base URL’i başka yere yönlendirme meselesi değil. Kendi kimlik doğrulama zincirini taşıyan her CLI’ın yönetilen egress’i kendi başına doğrulanmalı, benzetmeyle değil.

Tuzak 2: Tools anahtarı bir onay değil, bir yetkilendirme. Agent’lar varsayılan olarak kısıtlı tool ayarlarıyla geliyor. Tools’u açmak CLI’a komut çalıştırma, workspace’ini değiştirme ve yapılandırılmış MCP server’larını çağırma yetkisi veriyor. Bu komut başına onay değil, geniş bir yetki. Birçok ekip burada tehlikeli bir yanılsamaya kapılıyor: CLI’ın kendi izin isteminin güvenlik sınırı olduğunu sanıyorlar. Değil. Gerçek sınır pod izolasyonu ve router’ın egress politikası. Bir de şu ayrıntı: Skill talimat veriyor, tool izni vermiyor. Skill dosya okumak veya iş akışı çalıştırmak zorundaysa tools’u da açmanız gerekiyor.

Tuzak 3: Geliştirme modundaki credential deposunu bir secret vault sanmak. Credential’lar imaj build bağlamına veya süreç komut satırına girmiyor. Ama dokümantasyon açıkça söylüyor: bu bir secret vault değil. Yerel kullanıcı, Docker yöneticileri ve tools açık agent’lar runtime credential’larına erişebiliyor. MCP environment variable’larını ve header’larını da secret olarak ele alın. Yerel kontrol düzlemini de asla doğrudan internete açmayın; çok kullanıcılı giriş, uygulama seviyesinde RBAC veya production seviyesinde secret yönetimi yok.

Tuzak 4: Sadece güvenilir MCP, ve anlık npx ile tool indirmeyi bırakın. Yalnızca güvenilir dış MCP server’larına bağlanın, çünkü onların kendi yetkileri ve yan etkileri var. stdio MCP süreçleri host’ta değil agent runtime’ının içinde çalışıyor. Ek bir çalıştırılabilir gerekiyorsa Dockerfile’ı genişletin; salt okunur root dosya sisteminde anlık npx çağrılarıyla tool indirmek önerilmiyor. Arkadaki ilke daha büyük: BYO dünyasında yetenek çalışma zamanında doğaçlanmamalı, imajla bildirilmeli. Bir imaj denetlenebilir, imzalanabilir ve geri alınabilir. Konuşma ortasında npx ile çekilen bir şey bunların hiçbiri değil.

Tuzak 5: Sürüm kayması. Runtime imajları CLI sürümlerini sabitliyor; örneğin Claude Code 2.1.263, GitHub Copilot CLI 1.0.83, Codex CLI 0.152.0. Copilot’un kısıtlı modu, o sürüm için doğrulanmış boş olmayan bir tool allowlist’i kullanıyor. CLI sürümü değiştiğinde adaptörleri yeniden doğrulayın. Coding agent CLI’ları haftalık güncelleniyor; BYO mimarisinde CLI sürümü rastgele güncellenen bir istemci değil, bir altyapı bağımlılığı. Değişiklik yönetimine alın, yoksa bir sabah tool allowlist’iniz sessizce gerçeklikle uyuşmamaya başlar.

Yazar bir de dokümantasyonun kendisiyle ilgili küçük ama öğretici bir not düşüyor: quickstart README’si k8s/karssandbox.yaml‘a atıfta bulunurken, main branch’teki örnek dosya hâlâ k8s/clawsandbox.yaml adını taşıyor olabilir. Eski olabilecek bir yola güvenmek yerine depodaki gerçek içeriği kullanın. BYO, aktif olarak gelişen bir sözleşmeye karşı çalışmak demek.

Pratikte: KARS BYO Agent Studio

Yazar tüm bu ilkeleri somutlaştıran bir örnek proje de paylaşıyor: KARS BYO Agent Studio. Claude Code CLI, GitHub Copilot CLI ve Codex CLI için bir agent çalışma alanı. Tek bir arayüzden agent oluşturuyor, MCP server’larını ve Skill’leri yapılandırıyor ve akışlı sohbetler yürütüyorsunuz. Hem yerel Docker geliştirmeyi hem AKS/KARS destekli Azure dağıtımını destekliyor.

Pazarlama yöneticisinin ihtiyacı tam olarak buydu: Kubernetes öğrenmek zorunda değil, ama agent’ı yine de yönetilen bir sandbox’ta çalışıyor.

Agent oluşturmak dört adım: runtime seçip isim, model, endpoint ve credential girmek; talimatları eklemek ve isteğe bağlı olarak tools, MCP ve Skill’leri açmak; agent’ı kaydedip runtime’ını başlatmak; sohbete @AgentName ile başlamak. Sonraki mesajlar başka bir @AgentName gelene kadar aynı agent’ta kalıyor.

Üç runtime’ın ihtiyaçları belirgin şekilde farklı, ve bu “BYO’yu runtime başına doğrula” ilkesinin somut hali:

Dağıtımların başarısı ayrıntılarda gizli:

• Claude için servis kökünü girin; CLI Messages API’yi çağırıyor.
• Codex için /v1 içeren bir base URL girin; sağlayıcı sadece /chat/completions değil, Responses API‘yi de uygulamalı.
• Copilot credential’ı CLI’ın desteklediği bir GitHub OAuth token’ı veya hesabında Copilot Requests erişimi olan fine-grained bir PAT olmalı. Klasik PAT desteklenmiyor, rastgele bir OpenAI anahtarı da Copilot credential’ı değil.
• Yerel hata ayıklamada en sık tuzak: yerel runtime container’ından host’taki bir model servisine localhost ile değil, http://host.docker.internal:<port> ile ulaşın.
• Runtime tipi oluşturulduktan sonra değiştirilemiyor; runtime değiştirmek için yeni bir agent oluşturmanız gerekiyor.

Uzun görevler: iş agent’larını gerçekten ayıran yer

Bu bölüm, kod dışı işin kod işinden ne kadar farklı olduğunu en iyi gösteren kısım. Tam bir sunum üretmek on dakikadan uzun sürebiliyor; sıradan bir sohbet turunun çok ötesinde.

• Web sitesi ve KARS runtime uzun dosya üretim akışlarını canlı tutmak için 15 saniyede bir heartbeat gönderiyor.
• Runtime bir agent’ın varsayılan olarak 60 dakika çalışmasına izin veriyor; CHAT_TIMEOUT_MS ile bir dakika ile 24 saat arasında ayarlanabiliyor.
• Tarayıcı ile web sitesi arasındaki akış kesilirse agent arka planda devam ediyor. Arayüz session’ı yokluyor ve görev bittiğinde son yanıtı ve çıktıları geri getiriyor. Sadece açık bir “Stop generating” eylemi görevi iptal ediyor.
• Gizlenen tool olayları için varsayılan 64 MiB bütçe var, böylece ara tool çıktısı 4 MiB’ı geçtiğinde uzun PPT işleri öldürülmüyor. Kullanıcıya görünen asistan metni 4 MiB ile sınırlı kalıyor.

Son madde, programatik olarak Office dokümanı üretmiş herkesin tanıdığı bir gerçeği yansıtıyor: ara çıktı, nihai cevaptan çok daha büyük.

Üretilen dosyalar asistan yanıtının altında türe duyarlı önizlemelerle gösteriliyor. Word, Excel ve PowerPoint önizleme için LibreOffice ile PDF’e çevriliyor ama indirilen dosya orijinal kalıyor. HTML, script izni olmayan sandbox’lanmış bir iframe’de gösteriliyor. Güvenlik sınırı çıktılara kadar uzanıyor: tool sonuçları tarayıcı çıktısından ve session kaydından hariç tutuluyor; çıktılar yalnızca ilgili agent’ın workspace’inden, path traversal, symlink, uzantı, dosya sayısı ve boyut kontrollerinden geçtikten sonra okunuyor.

Skills: iş bilgisini agent’a koymak

Kod dışı iş agent’ları için belirleyici parça bu. Her Skill en fazla 5 MiB’lik bir ZIP olarak yükleniyor; SKILL.md ZIP’in kökünde veya tek üst dizininde olmalı, arşiv script, şablon ve başka kaynaklar içerebiliyor.

Yüklenen Skill’ler kalıcı agent depolamasına güvenli şekilde açılıyor ve her konuşmadan önce /sandbox/agents/<agent-id>/skills/<skill-name>/ dizinine senkronize ediliyor; pod yeniden başladığında kaybolmuyor. Oradan her CLI’ın kendi native konumuna eşleniyor:

• Claude Code: ~/.claude/skills/
• GitHub Copilot CLI: <workspace>/.github/skills/
• Codex CLI: ~/.agents/skills/

Tek ZIP, üç runtime. Yani “şirketimiz aylık raporu nasıl yazar” bilgisi, asıl kurumsal varlığınız, tek bir model satıcısına bağlı kalmıyor.

Mimari: kontrol düzlemi ve yürütme düzlemi

Azure modunda web sitesi ve kontrol düzlemi Azure Container Apps‘te, agent’lar ise AKS üzerindeki bir KARS Sandbox’ında çalışıyor. Kontrol düzlemi agent, sağlayıcı ve Skill yapılandırmasını, session ve mesaj kalıcılığını, tarayıcı akışını ve arka plan kurtarmayı, çıktı önizleme ve indirme proxy’sini ve AKS’e Managed Identity ile kimlik doğrulamayı yönetiyor. Kalıcı durum Azure Files’ta tutuluyor.

Yürütme düzlemi daha önce anlatılan pod: UID 1000’de salt okunur root dosya sistemiyle çalışan BYO agent container’ı ve yanında KARS yönetişim katmanı. İçeride kurulu olanlar tamamen iş odaklı: üç CLI, Chromium ve curl, LibreOffice ve MCP istemcileri. Tarayıcıya da istisna yok; chrome, chromium ve türevleri KARS egress proxy’sini kullanıyor ve sandbox ağ yönetişimini atlatmıyor.

Yazarın özellikle beğendiği bir tasarım kararı var: session’lar üç CLI arasında paylaşılan native session ID’leri değil, taşınabilir transkriptler. Ve aşırı büyük konuşma bağlamı sessizce kırpılmak yerine açıkça hata veriyor. Sessiz kırpma, agent ürünlerindeki en sinsi hata; kullanıcı agent’ın neden birden “unuttuğunu” hiç öğrenmiyor.

Yazarın e-postaya bugün vereceği cevap şu: evet, departmana yayabilirsiniz, ama kurduğunuz şey “daha büyük bir Claude Code” değil, bir agent altyapısı katmanı. Bu katmanı dört seviyede düşünmek gerekiyor:

• Runtime: çeşitliliği kucaklayın, bahis oynamayın. Bu alan aylık değişiyor. Mimariniz Claude Code, Copilot CLI ve Codex CLI’ın bir arada yaşamasına izin vermeli.
• Yönetişim: sınırı agent’ın ulaşamayacağı yere koyun. Agent container’ının içinde kısıtladığınız her şey kolaylık; sadece dışında kısıtladığınız şey güvenlik.
• Bilgi: asıl hendeğiniz bu. Modeller değişir, CLI’lar güncellenir. Ama çeyrek raporunuzu nasıl yazdığınız sizin varlığınız. Bunu Skill olarak yazın.
• Deneyim: uzun görevler ve çıktılar ayrım çizgisi. Heartbeat, 60 dakikalık varsayılan süre, kopmaya dayanıklılık, Office önizlemeleri. Bunların hiçbiri “AI yeteneği” değil, ama biri eksik olsa o sunum hiç üretilmiyor.

Bu yazıda bence en değerli fikir ikinci madde. Coding agent’larda izin istemleri, tool anahtarları ve talimatlar kolayca güvenlik kontrolü sanılıyor; KARS ise bunları açıkça “kolaylık yapılandırması” olarak sınıflandırıyor ve gerçek sınırı agent’ın dokunamadığı bir yere, ayrı UID’li bir router container’ına ve pod dışı egress politikasına koyuyor. Son haftalarda gördüğümüz Docker Sandboxes’taki kaçış gibi olaylar, bu sınırın kendisinin de kusursuz olmadığını hatırlatıyor; bu yüzden KARS’ın katmanlı yaklaşımı, yani router atlatılırsa devreye giren NetworkPolicy ve egress-guard, doğru bir tercih.

Değerlendirirken akılda tutulacak şey KARS’ın konumu: resmi olarak desteklenen bir ürün değil, CRD’leri alfa aşamasında ve API’si değişebilir. Yazar README’deki “Known limitations” listesini ve şu cümleyi özellikle takdir ediyor: “Bunları production’da bulmaktansa bu listede bulmanızı tercih ederiz.” Production’a doğrudan almak yerine, agent altyapınızı tasarlarken okunacak bir referans olarak değerlendirmek daha doğru.

Kaynak: https://techcommunity.microsoft.com/blog/azuredevcommunityblog/when-the-coding-agent-leaves-the-codebase-building-a-multi-runtime-ai-agent-infr/4558449