Yardımcıdan meslektaşa: Yapay zekâ otonom çalıştığında ne değişir?

Öneri motorlarından otonom takım arkadaşlarına geçişe araştırma temelli bir bakış. Neden şimdi yaşanıyor, geçişte neler aksıyor ve tüm yetkiyi devretmeden nasıl devreye alınır?

Yardımcı dönemi durağanlaşıyor

15 Nisan 2026'de Sam Altman, X'te OpenAI'nin "bu hafta ekipler ve büyük şirketlere odaklanan Codex güncellemeleri" yayınladığını duyurdu.

Yanıtlar oldukça açıklayıcıydı. Yol haritasını soran her geliştiriciye karşılık, daha zor bir soru soran bir başkası vardı: Codex neden hâlâ başında beklememi istiyor? Altı ay önce, BeyondTrust araştırmacıları, özel olarak hazırlanmış bir Git dalı adıyla Codex'in kullanıcının GitHub jetonunu dışarı sızdırmasını sağlayan bir kavram kanıtı yayınlamıştı. Bir dal adıyla kandırılıp jeton sızdırabilen bir yardımcı, meslektaş değildir. Emniyet mandalı çekili bir silah gibidir.

Bu gerilim, 2026'deki her kurumsal yapay zekâ tartışmasının temelinde yatıyor. Yardımcılar tavan yaptı ve rakamlar da bunu gösteriyor:

MIT'nin NANDA girişimi, 2025'te üretken yapay zekâ pilotlarının 95%'ünün ölçülebilir iş değeri sunamadığını bildirdi.
RAND çalışması, Reddit'in r/ArtificialIntelligence topluluğunda 2026 başında sıkça atıf aldı ve AI ajan projelerinin üretimde 80 ila 90%'sinin başarısız olduğunu buldu.
GitHub Copilot için geliştirici kabul oranları 35 ila 40% civarında sabitlenirken, Cursor 42 ila 45% aralığında ve Claude Code, 2026 AI kodlama anketinde 46% "en çok sevilen" derecesini aldı. Sadece Mayıs 2025'te piyasaya çıkan bir araç için şaşırtıcı bir değişim.
Satya Nadella'nın, Microsoft'un dahili Copilot dağıtımını 2025 sonunda "neredeyse kullanılamaz" olarak nitelendirdiği ve şirketin, yöneticilerin kendi aralarında ürünü "yüksek riskli bir yeniden başlatma" olarak tanımladığı bir duyuru yaptığı bildirildi.
arXiv çalışması, 2025 sonunda yayımlandı ve Copilot tarzı otomatik tamamlamanın, uzman geliştiricilerde daha fazla hayal kırıklığına yol açtığını, çünkü akışlarını makul ama ince hatalı önerilerle böldüğünü buldu.

Bu durağanlık, temel modellerin başarısızlığı değil. Etkileşim deseninin başarısızlığı. Bir yardımcı, bireysel tuş vuruşu veya sorusu düzeyinde çalışır. Bir meslektaş, iş akışı düzeyinde çalışır. Bits&Chips, Nisan 2026'deki "Yardımcıdan meslektaşa" makalesinde bunu şöyle özetledi: "Bir yardımcı, bireysel etkileşim düzeyinde çalışırken, bir ajan iş akışı düzeyinde çalışır. Bu önemlidir, çünkü çoğu organizasyonda darboğaz bireysel görev değildir. Görevler arasındaki koordinasyondur."

Şirketlerin şimdi yapmaya çalıştığı değişim tam olarak bu. Düzensiz, kusurlu ve anlamlı ölçekte.

Otonomi spektrumu

"Ajan" artık bir pazarlama terimi oldu, o yüzden somutlaştıralım. Yapay zekâ otonomisinin dört ayrı seviyesi var ve 2025 ile 2026'deki hayal kırıklıklarının çoğu, bunların birbirine karıştırılmasından kaynaklandı.

Seviye 1: yardımcı

Önerir. İzin ister. Ekranınızda kalır. GitHub Copilot'un otomatik tamamlaması tipik örnektir. Değer, kaydedilen tuş vuruşlarıyla ölçülür.

Seviye 2: asistan

Soruları yanıtlar ve istek üzerine çıktılar oluşturur. ChatGPT, tarayıcıda Claude, Microsoft 365 Copilot'un sohbet paneli. Değer, taslak kalitesi ve bağlam senteziyle ölçülür.

Seviye 3: ajan

Bir hedef alır, adım adım plan yapar, araçlar arasında yürütür, raporlar. Claude Code bir depoyu tarayıp PR açar. ChatGPT'nin Derin Araştırması 20 dakikalık arama yapıp kaynaklı rapor döndürür. Anthropic, Claude'un Rakuten için 7 saatlik otonom mühendislik görevini tamamladığını belgeledi. Değer, insan başına tamamlanan iş akışıyla ölçülür.

Seviye 4: meslektaş

Mevcut izin modelinizde çalışan, ekibinizin iletişim kanallarına katılan, günler ve haftalar boyunca bağlam tutan ve insan çalışanla aynı denetim izine tabi olan bir ajan. Burası sınır noktası.

Reddit'in r/ChatGPT topluluğu, bu seviyeleri ayırt etmek için pragmatik bir test önerdi, özetle: bu şey inisiyatif alıyor mu, yoksa her talimatı mı bekliyor? Beklenmedik durumları yönetiyor mu, yoksa çöküp tekrar komut vermenizi mi istiyor? Çok adımlı bir görevde bağlamı hatırlıyor mu, yoksa kendinizi tekrar etmek zorunda mısınız? 2025'de "AI ajanı" olarak pazarlanan ürünlerin çoğu bu soruların hiçbirini geçemedi. Geçenler ise artık insanların "meslektaş" dediği şey.

Bilgisayar kullanımı vs yetenekler: Altyapı neden önemli?

Meslektaş seviyesinde bir yapay zekâ, dünyada eylem alabilmeli. Bunun için iki mimari yaklaşım var ve risk profilleri çok farklı.

Bilgisayar kullanımı

Yapay zekâ, simüle edilmiş fare ve klavye kullanır. Gerçekten bir ekran görür ve düğmelere tıklar. Anthropic, Bilgisayar Kullanımı'nı 2024 sonunda sundu, ardından OpenAI'nin Operator'u geldi. Cazibesi evrensellik: GUI olan her yazılım erişilebilir olur.

Bedeli ise etki alanı. Bilgisayar kullanan bir ajan, oturum açan kullanıcının tüm izinlerini devralır. Ekim 2025'da, BeyondTrust güvenlik ekibi, OpenAI'nin Codex ajanının, kabuk komutları içeren kötü niyetli bir Git dalı adıyla kandırılarak kullanıcının GITHUB_TOKEN'unu okuması ve dışarı sızdırmasını gösterdi. Ajan, bir insan geliştiricinin yapacağı gibi (dalı kontrol etmek) hareket ediyordu, fakat dal adının zararlı bir girdi olduğunu sezemezdi. Bu olayda yetki modeli ya hep ya hiçti. Bilgisayar kullanımının varsayılan hata modu budur.

Yetenekler

Yapay zekâ, ayrık yetenekler çağırır. Her yetenek, dar kapsamlı, açık tipli bir işlevdir: "Slack'te q ile eşleşen mesajları ara", "title ve body ile Linear görevi oluştur", "Bu GitHub dosyasını oku." Bilgisayar kullanımının aksine, bir yeteneğin önceden onaylanmış bir şekli vardır. Ajan, yalnızca sözleşmeye uyan parametrelerle çağırabilir ve platform, bu çağrıyı sandıktan çıkmadan önce izin verebilir, reddedebilir veya onay isteyebilir.

Güvenlik açısından fark, En Az Ayrıcalık İlkesi'ne dayanır. Bilgi güvenliğinde temel bir fikir: bir süreç, yalnızca işlevini yerine getirmek için gereken kaynaklara erişmeli, fazlasına değil. Yetenekler, her çağrıda en az ayrıcalığı uygulatır. Bilgisayar kullanımı bunu yapamaz.

Meslektaş seviyesinde bir dağıtım, yapılandırılmış eylemler için yetenekleri (CRM'e yazmak, bilet açmak) kullanır, bilgisayar kullanımını ise API sunmayan uygulamalar için saklar. Oran önemlidir. Ajan dağıtımınızdaki her eylem simüle edilmiş fareyle yapılıyorsa, bir verimlilik demosu sunuyorsunuz, üretim sistemi değil.

Kurumların gerçekten ihtiyaç duyduğu güven mimarisi

Yardımcıdan meslektaşa geçiş bir model yükseltmesi değil. Bir altyapı yükseltmesi. Dağıtılabilir bir meslektaşı bir riskten ayıran üç unsur var.

1. İzin izolasyonu

Her ajan, kendi izin sınırında çalışır ve kimlik bilgilerini sandıktan çıkaramaz. Andrej Karpathy'nin Mart 2026'te viral olan autoresearch deneyi, bir ajanın iki gün boyunca 700 eğitim deneyi yürütmesine izin verdiği örnek, yapmadığı şey açısından öğretici. Karpathy'nin kendi deposu, kullanıcıya otonom modda "tüm izinleri devre dışı bırakmasını" öneriyor. Kişisel araştırma dizüstü bilgisayarı için sorun yok. Düzenlemeye tabi bir kurumda işten çıkarılma sebebi.

Karşı örnek ise, Ocak 2026 sonunda kısa süreliğine viral olan, 1.5 milyon otonom ajana sahip yalnızca yapay zekâ tabanlı sosyal ağ Moltbook. Karpathy, bunu "son zamanlarda gördüğüm en inanılmaz bilim kurgu kalkışına yakın şey" olarak övdü. Ardından Wiz'den güvenlik araştırmacıları, ön uçta tüm üretim veritabanına tam okuma/yazma erişimi veren açık bir veritabanı API anahtarı buldu; bu, tüm 1.5 milyon ajan için kimlik doğrulama jetonlarını da içeriyordu. Karpathy, 24 saat içinde fikrini değiştirdi: "Tam bir felaket. İnsanların bunu bilgisayarlarında çalıştırmasını kesinlikle önermem." Ders, "ajanlar tehlikelidir" değil. Ders, kimlik başına izin izolasyonu olmadan dağıtılan ajanların tek bir ortak risk alanına dönüştüğüdür.

2. Denetim izleri

Her eylem kaydedilir, her karar izlenebilir. Singapur'un IMDA çerçevesi, Ocak 2026'de Davos'ta yayımlandı ve bir ajanın eylem alanını (okuma vs yazma, geri alınabilir vs alınamaz) otonomisiyle (ne kadar bağımsız karar verdiği) iki eksenli bir risk matrisinde eşleştiriyor. Her iki eksen de yükseldikçe, denetim gereksinimi de artıyor. Bu çerçeve, yönetişimi soyut ilkelerden operasyonel bir kalibrasyon aracına çeviren ilk örneklerden biri olduğu için Avrupa ve ABD düzenleyicileri tarafından yakından inceleniyor.

Simon Willison, paralel olarak birleşik günlükleme savunuyor; böylece ajanlar kendi işlemlerini izleyip hatalardan kurtulabiliyor: "Tam sistem erişimi olan ajanlar güçlü ve tehlikelidir." Pratik nokta: Ajan dağıtımınızda, bir uyum görevlisinin sırayla okuyabileceği birleşik bir günlük yoksa, dağıtım ayrıcalığını kaybetmeye bir olay uzaktasınız.

3. Sınırlı yetenek erişimi

"E-postaya erişim" değil. search inbox where from:@customer.com AND within last 7 days'ya erişim. Modern ajan platformları, bir ajanın bir yeteneği çağırma izninin, yöneticinin önceden onayladığı argümanlarla sınırlandığı, parametreli kapsamlar yönünde ilerliyor; insanın kullandığı kaba OAuth kapsamı değil.

Bu üç unsuru bir araya getirdiğinizde, her CISO'nun şu anda sorduğu soruya yanıt veriyor: Bu ajan hata yaptığında ne yapar ve ben bunu nasıl anlarım? 2026 McKinsey State of AI anketi, kurumsal katılımcıların 72%'sinin üretken yapay zekâda siber güvenliği endişe olarak gördüğünü ve güvenliğin, katılımcıların yaklaşık üçte ikisi tarafından #1 engel olarak adlandırıldığını buldu. İzin izolasyonu, denetim izleri ve sınırlı yetenek erişimi, uyum tiyatrosu değil. Bunlar, geçişi sağlayan altyapı.

Neden şimdi önemli: üç güç birleşiyor

2026'de yardımcıdan meslektaşa geçiş, tek bir atılımla değil, üç eğrinin kesişmesiyle yaşanıyor.

Güç 1: entegrasyon özel olmaktan çıktı

2024'de, bir ajanı kurumsal SaaS yığınına bağlamak, her araç için özel bir bağlayıcı yazmak demekti. 2026 başında, tipli yetenek sözleşmeleri ve hazır bağlayıcılar bu işi ortadan kaldırdı. 2024'de altı hafta entegrasyon gerektiren bir ajan, 2026'de bir öğleden sonra yeterli. Tipik bir orta ölçekli şirketin yüzey alanı (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, takvimler), artık tipli izinlerle gelen olgun, açık kaynak bağlayıcı kütüphaneleriyle kapsanıyor.

Güç 2: çoklu ajan gerçeğe dönüşüyor

Gartner, Çoklu Ajan Sistemlerini 2026 için en önemli stratejik teknoloji trendi olarak adlandırdı. Kıdemli Başkan Yardımcısı Analist Gene Alvarez, artık her kurumsal yapay zekâ sunumunda tekrarlanan metaforu sundu: "Bir Formula 1 pit ekibini düşünün. Her üyenin uzmanlaşmış bir rolü var (lastik değiştirici, yakıtçı, kriko operatörü) ama tek bir hedef etrafında koreografi yapılıyorlar. 2026'de kurumsal ajan dağıtımlarının şekli bu." Tek ajanlı sistemler, uzun vadeli görevlerde akıl yürütme sınırına takılıyor. Uzmanlaşmış roller ve açık devirlerle çoklu ajan sistemleri, ekiplerin bugün bu sınırları aşma yolu.

Güç 3: kurumsal bütçeler açılıyor

G2, 2026 State of Software araştırmasında şirketlerin 57%'ının üretimde AI ajanı kullandığını (bir yıl önce yaklaşık 20% idi) bildirdi.
McKinsey, kurumların 23%'sinin ajan tabanlı yapay zekâyı aktif olarak ölçeklendirdiğini, 62%'sinin ise deneme aşamasında olduğunu buldu. Sadece yaklaşık 15% büyük kuruluş hâlâ kenarda.
Deloitte'un 2026 anketinde 3,235 kurumsal lider, finansal hizmetleri başı çeken sektör olarak belirledi; bir AI ajanının, daha önce üç analistin yürüttüğü bir anlaşma hattında toplantı sonuçlarını yakalayıp harekete geçmesini belgeleyen bir vaka çalışması sunuldu.
Stanford'un Enterprise AI Playbook'u, 2026 başında yayımlandı ve 51 üretim dağıtımını katalogladı; düzenlemeye tabi sektör ekipleri için referans uygulama haline gelen bir fintech ETL geçiş vakası öne çıktı.
Bildirilen kurumsal yapay zekâ altyapı yatırımı, 2025 döngüsünde $600 milyar sınırını aştı.
Anthropic'ten Dario Amodei, Code with Claude konferansında, ajan iş gücüyle çalışan ilk tek kişilik milyar dolarlık şirketin 2026'de ortaya çıkma olasılığını 70 ila 80% olarak verdi.

Para var, protokol var, mimari var. Şu anda her yönetim kurulunda pazarlık konusu olan şey: ne kadar otonomi, hangi yönetişim altında ve hangi iş akışları için.

Şüphecinin bakışı: Reddit, arXiv ve olay raporları ne diyor?

Bu değişime sorumlu bir bakış, tüm sürecin abartıldığını düşünenlerle ciddi şekilde yüzleşmeli.

Reddit'te, r/LocalLLaMA, r/ClaudeCode ve r/ChatGPT genelinde uzlaşı pragmatik: kodlama ajanları geldi ve faydalı. Diğer "ajanların" çoğu ise sohbet botu kılığına girmiş otomasyon iş akışları. 2026 başlığında onlarca kez alıntılanan satır, "Öneri istiyorsan Copilot kullan. Gerçekten bir şey yapmasını istiyorsan Claude Code veya Cursor kullan," verimli ayrımı özetliyor. Aynı topluluklar, kıyaslamalarda acımasız. En iyi ajanlar bile Terminal-Bench'te yaklaşık 60% puan alıyor ve zor görevlerde 16%'ya düşüyor. Claude Opus 4.5, SWE-bench'te 80.9% ile lider, bu da hâlâ her beş görevden birinin başarısız olduğu anlamına geliyor.

Akademik şüphecilik ise daha zor sarsılıyor. Vishal Sikka (eski SAP CTO'su, John McCarthy'nin öğrencisi) ve iş arkadaşı, Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models başlıklı çalışmada, dönüştürücü LLM'lerin belirli bir karmaşıklık eşiğinin ötesinde hesaplama ve ajan görevlerini yerine getirme yeteneğinde temel sınırlamalar olduğunu matematiksel olarak savundu. Sikka'nın sonucu, "Çok kritik işlemler için güvenilir olmaları mümkün değil" şu anda her CISO Slack kanalında dolaşıyor. Makale, ajanların işe yaramaz olduğunu iddia etmiyor. Model ne kadar iyi olursa olsun, insanı döngüden çıkaramayacağınız bir problem sınıfı olduğunu iddia ediyor.

Gerçek olaylar şüpheciliği destekliyor. Yellow.ai'nin 2026 anketinde bir perakende müşteri deneyimi lideri şöyle diyor: "Yapay zekâ destekli desteğimizi sadece iki hafta sonra geri çekmek zorunda kaldık, çünkü biletlerin yaklaşık 1.35%'ında yanlış iade politikaları aktarmaya ve uydurma indirim teklifleri yapmaya başladı. Bu hataları karşılamanın maliyeti, umduğumuz tasarruftan çok daha fazlaydı." Ölçek büyüdükçe, %2% altı hata oranı bile hızla pahalıya mal olur.

Özet: Meslektaş seviyesinde yapay zekâ, kodlama, araştırma, yapılandırılmış operasyonlar ve dar destek iş akışlarında gerçek. Henüz gerçek değil insan denetimi olmadan açık uçlu müşteri etkileşimlerinde. 2026'de değer elde eden kurumlar, bir iş akışının hangi kategoriye ait olduğu konusunda dürüst olanlar.

Pratik sonuç: Dağıtımdan önce beş soru

Ekibiniz bir yapay zekâ takım arkadaşı (iç geliştirme veya üçüncü taraf) değerlendiriyorsa, üretim dağıtımını neredeyse kaçırmaktan ayıran sorular şunlar:

Bu ajanın tek bir eylemde yaratabileceği en kötü etki alanı nedir? Haritalayın. En kötü senaryo "yanlış kişiye taslak e-posta göndermekse" yönetişim çıtası düşük. "Üretim verisini değiştiriyor" veya "havale talimatı gönderiyor" ise çıta kat kat yüksek. Dağıtımdan önce haritalayın, ilk olaydan sonra değil.
Ajan kimlik bilgilerini nasıl alıyor ve ham jetonu okuyabilir mi? Üç yanıt var, sadece biri güvenli. Ajan, kullanıcının OAuth jetonunun bir kopyasına ortamında sahipse, LLM'ye cüzdanınızı vermiş olursunuz. Ajanın "kendi" kimliği varsa, ayrı bir servis hesabı OAuth ile, onu gerçek bir kullanıcı gibi izleyip iptal etmeniz gerekir. Asıl istenen üçüncü yanıt: Jeton asla ajana ulaşmaz. Platformda şifreli durur, ağ proxy katmanında, yalnızca politika kontrolünden geçen çağrılar için, sadece çağrı süresince enjekte edilir.
Her eylem, bir uyum görevlisinin sırayla okuyabileceği şekilde kaydediliyor mu? Birleşik, sorgulanabilir, kurcalamaya karşı kanıtlı. "CloudWatch'ta bir yerde loglarımız var" diyorsanız, hazır değilsiniz.
Yetenek erişimini bu iş akışının ihtiyaç duyduğu parametrelere göre sınırlandırabiliyor musunuz? Her çağrı için, her entegrasyon için değil. Okuma vs yazma. Kaynak kimliğiyle. Zaman aralığıyla. Ajanın izinleri, işin etrafına sıkı çizilmiş bir dikdörtgen olmalı, tüm depoya değil.
Bir şey ters giderse geri alma hikayeniz nedir? Bir eylemi nasıl geri alırsınız? Ne kadar hızlı? Kim bilgilendirilir? Geri alınamaz eylemler (para transferleri, müşteri e-postaları, üretim dağıtımları) onay adımı veya gecikme penceresi gerektirir. Geri alınabilirler otonom çalışabilir.

Beşi üzerinde çalışın. Hepsine yanıt verebiliyorsanız, zaten yardımcı dönemini aşıp ekibinizin iş yapışını gerçekten değiştiren kısma geçtiniz. İki ya da üçüne yanıt verebiliyorsanız, odaklanmanız gereken yer orası; beklemek için sebep değil. Yol haritanızın ulaşmak istediği meslektaş seviyesinde takım arkadaşı, bugün bir yerde üretimde çalışıyor. Sizinle onun arasındaki fark, bir altyapı farkı; öncü yapay zekâ farkı değil. Ve altyapı farkları hızla kapanır.

Bir sonraki model sürümünü beklemenize gerek yok. Bu beş soruya zaten yanıt veren bir platform seçip, ajana gerçek iş vermeye başlamanız yeterli.

Sıkça sorulan sorular

Yardımcı ile yapay zekâ meslektaşı arasındaki gerçek fark nedir?

Bir yardımcı önerir, izin ister ve tek bir araç içinde yaşar. Bir meslektaş, hedefleri kabul eder, sistemler arasında plan yapar, sınırlı izinlerle yürütür ve insan gibi aynı denetim izine tabidir. Bits&Chips bunu net özetledi: yardımcılar etkileşim düzeyinde, meslektaşlar iş akışı düzeyinde çalışır.

Ajanlar kullanıcı kimlik bilgilerini nasıl yönetmeli?

Bariz iki seçenek de doğru değil. Kullanıcının OAuth jetonunu ajanın ortamına kopyalamak, canlı bir kimlik bilgisini LLM'nin bağlamına koyar. Her ajana ayrı kimlik vermek, her ajanı insan gibi izleyip iptal etmeniz gereken bir kullanıcıya dönüştürür. Pratikte işe yarayan desen: aracılı erişim; jeton platformda şifreli durur; sandığın dışa giden ağ proxy'si, istek anında platforma geri çağrı yapar; platform jetonu çözer ve yalnızca politika kontrolünden geçen çağrılar için çözümlenmiş kimlik başlıklarını döndürür; ajan ham jetonu asla okumaz, kaydetmez veya istemez.

Bilgisayar kullanımı mı yetenekler mi seçilmeli?

Varsayılan olarak yetenekler, API olan her şey için. Bilgisayar kullanımı sadece hedef sistemin programlanabilir arayüzü yoksa. BeyondTrust Codex olayı uyarıcı örnek: bilgisayar kullanımı, kullanıcının tüm izinlerini devralır ve ajanın görüş alanındaki kötü niyetli bir girdi, istismara dönüşebilir.

Ajanlara ne kadar otonomi tanımalıyız?

Singapur IMDA'nın iki eksenli çerçevesini kullanın: eylem alanı × otonomi. Dar eylem alanı (salt okuma, geri alınabilir) yüksek otonomiye tolerans gösterir. Geniş eylem alanı (yazma, geri alınamaz, müşteriyle yüz yüze) insan onayı veya müdahale için zaman gecikmesi gerektirir. En kötü yapılandırma, yüksek otonomiyle yüksek riskli eylemler ve denetim izi olmamasıdır.

Yatırım getirisini nasıl ölçeriz?

Kaydedilen tuş vuruşunu ölçmeyi bırakın. İnsan başına tamamlanan iş akışı, operasyonel olaylarda çözüm süresi ve kaçış oranını (ajanın insana devrettiği görevler) ölçün. Deloitte'un 2026 bulguları, öncülerin üç metriği izlediğini gösteriyor: iş akışı tamamlama oranı, hata oranı ve insan müdahale oranı; aralarındaki oranı optimize ediyorlar.

95% pilot başarısızlık oranı için ne yapmalı?

MIT NANDA'nın analizini dikkatlice okuyun. Başarısız olan pilotlar çoğunlukla "Aptal RAG" (her şeyi bağlama atmak), "Kırılgan Bağlayıcılar" (bozuk API entegrasyonları) ve olaysız mimariyle çalıştı. Başarılı olanlar, LLM etrafında bir işletim katmanına sahipti: bellek, I/O ve izinler. LLM çekirdeği darboğaz değil. Çevresindeki altyapı darboğaz.

VM0'ın yeri

Zero'yu tek bir mimari iddia üzerine inşa ettik: ajan asla kimlik bilgisini tutmamalı. Ne ortamında, ne isteminde, ne belleğinde. Jeton platformda kalır. Ajanın yaptığı her dış çağrı, çağrı başına kimlik başlığı enjekte edip etmeyeceğine veya isteği engelleyip engellemeyeceğine karar veren bir ağ proxy'si üzerinden yönlendirilir.

Bu alışılmadık bir tercih. 2026'de yaygın desenler, ya ajana kendi OAuth kimliğini vermek (artık denetleyip iptal etmeniz gereken ikinci bir kullanıcı var) ya da kullanıcının jetonunu ortam değişkeniyle vermek (LLM cüzdanınızı okuyabilir). Biz ikisini de yapmıyoruz. Gerçekten nasıl çalıştığı şöyle:

Jeton asla ajana ulaşmaz. Zero'ya bir bağlayıcı (GitHub, Slack, Gmail, Linear, Notion, HubSpot vb.) bağladığınızda, OAuth jetonu platformda şifreli saklanır. Yenileme jetonları veritabanında kalır ve asla dışarı çıkmaz. Sandık içinde, okunacak GITHUB_TOKEN ortam değişkeni, açılacak gizli dosya veya jeton döndüren araç yoktur.

Her çağrıyı bir ağ proxy'si aracılık eder. Sandıktan çıkan her HTTP isteği, mitmproxy tabanlı bir eklentiden geçer. Proxy, isteğin ana bilgisayar adından bağlayıcıyı tanımlar, o ajan için güvenlik duvarı politikasına bakar ve yöntem-yolun izinli olup olmadığını kontrol eder. İzinliyse, proxy platformun webhook'una geri çağrı yapar. Platform jetonu çözer, süresi dolmuşsa yeniler, başlık şablonlarını çözümler (${{ secrets.GITHUB_TOKEN }} gerçek değere dönüşür) ve yalnızca çözümlenmiş kimlik başlıklarını proxy'ye döndürür. Proxy, bu başlıkları giden isteğe enjekte eder. Çağrı tamamlandığında, başlıklar proxy belleğinden silinir. Ajan onları hiç görmez.

İzinler ajan başına, bağlayıcı başına ve uç nokta düzeyinde tiplenmiş. Her ajan, her bağlayıcıyı adlandırılmış izin gruplarına eşleyen bir politika nesnesi taşır. github:repo-read belirsiz bir kapsam değildir. Belirli yöntem-yol kurallarının bir demetidir, örneğin GET /repos/{owner}/{repo}/pulls. GitHub erişimi vermek, tüm GitHub'a erişim vermek değildir. GitHub içinde bir niyet şekli verir.

İki değil üç politika durumu. Her izin, allow, deny veya ask olarak çözülür. Sonuncusu, eylem gerçekleşmeden önce bir insanı uyarır. Güvenlik duvarının açıkça eşleştirmediği her şey, bağlayıcı başına unknownPolicy'ya düşer ve varsayılanı deny'dır. En az ayrıcalık varsayılandır, isteğe bağlı değil.

Her çalıştırma için bir sandık. Her ajan yürütmesi, izole ağ ad alanına sahip kendi Firecracker microVM'inde çalışır. Çalıştırma bittiğinde ad alanı kaldırılır. Aynı ajanın iki çalıştırması, iki ayrı sandık ve iki ayrı denetim izi demektir.

İstek başına denetim izi. İzin ver/engelle kararı veren aynı proxy, güvenlik duvarı meta verisiyle her isteğe eklenmiş şekilde, çalıştırma başına bir JSONL günlük de yazar: bağlayıcı, eşleşen izin grubu, eşleşen kural, karar, zaman damgası. Bu günlükler platforma geri gönderilir. Bir CISO, 3 Nisan 14'de 15:00-17:00 CST arasında ajanın ne yaptığını bilmek isterse, tek sorgu yeter.

Kendi engellemelerini açıklayan bir CLI. Bir izin bir çağrıyı engellediğinde, ajan (veya yanındaki insan) zero doctor permission-deny <connector> --method <M> --path <P> komutunu çalıştırıp isteği engelleyen tam izin grubunu ve bir düzeltme bağlantısını alabilir. zero doctor permission-change ile yöneticiler doğrudan izin açıp kapatabilir veya bir üye, yöneticilere yönlendirilen yazılı bir talep gönderebilir (500 karakterle sınırlı, böylece gerekçe okunur). slack:chat:write veya gmail.send gibi yüksek riskli izinler, daha güvenli, bot kapsamlı alternatife işaret eden ek bir uyarı tetikler.

İki rol, tek onay akışı. Sahipler ve yöneticiler izinleri doğrudan değiştirir. Üyeler, gerekçeyle bir talep gönderir, bu yöneticiye yönlendirilir. Üçüncü bir "yarı-yönetici" katmanı yok. Akış yeterince küçük, insanlar gerçekten kullanıyor; amaç da bu.

Bilgisayar kullanımını, API sunmayan eski sistemlerin dar bir alt kümesiyle sınırlandırıyoruz. Diğer her şey yeteneklerle çalışıyor. Her eylem politika kontrolünden geçiyor. Her kimlik bilgisi platformda kalıyor. Her karar kaydediliyor.

"Bir başka AI otomatik tamamlama"yı aştıysanız ve güvenlik ekibinizin onaylayacağı bir AI takım arkadaşı denemek istiyorsanız, Zero'nun zamanlanmış iş akışlarını nasıl yönettiğine bakın, üretim olaylarını nasıl triyaj ettiğine göz atın veya sabah ürün brifingi çalıştırın.

Yardımcı dönemi bitmiyor. Daha büyük bir yapının parçası oluyor. Bir sonraki döngüyü kazanacak ekipler, farkı anlayanlar olacak.