Kuantum dirençli ajan sistemleri: ajanlar anahtarlarından daha uzun yaşadığında ne değişir.

Son iki yazıyı soyut kriptografi üzerine harcadık — post-quantum'un tam olarak ne demek olduğu, ve herhangi bir kripto göçünden sağ çıkmanı sağlayan disiplin. İkisi de uzun ömürlü her sistem için doğru. Bu yazı, GOGOGO LLC'de gerçekten inşa ettiğimiz sistem biçimi üzerine: çok ajanlı runtime'lar — tek bir platform üzerinde birçok küçük, uzmanlaşmış ajan, her biri gözlemlenebilir, izlenebilir, notlandırılabilir. Post-quantum göçü çok ajanlı bir sistemle buluştuğunda üç şey değişir. Hiçbiri acil durum değil. Hepsi şimdi, iş henüz küçükken tasarlamaya değer.

Çok ajanlı bir sistemde tam olarak ne farklı

Geleneksel bir web servisinin endişe edilecek bir veya iki kriptografik dikişi vardır — TLS uç noktası ve belki bir JWT imzacısı. Bütünü tek bir binary olarak render edilir, yatay ölçeklenir, sırları deployment kadar yaşar. Tehdit yüzeyi bir peçeteye sığar.

Çok ajanlı bir runtime'ın daha fazla biçimi var. Retrieval ajanı dış API'lerden çekiyor ve döndürdüğünü imzalıyor. Reranker bir güven puanı basıyor ve onu da imzalıyor. Generator bir çıktı yayınlıyor ve oraya nasıl vardığının imzalı bir trace'ini. Router paketi sonraki ajana yönlendirirken paket authenticated. Evaluator aylar öncesi trace'leri okuyor ve onları notlandırıyor. Düzinelerce kriptografik dikiş var — ve çoğu, saniyeler değil yıllarca doğrulanabilir kalması gereken artefaktlar üretiyor. Bu, tehdit yüzeyini peçeteden afişe çıkarır, ve post-quantum tam ortasında oturur.

Değişiklik bir: ajanın kimliği anahtarından uzun yaşar

Çok ajanlı bir sistemde ajanların kalıcı kimliği vardır. Retrieval ajanı taze bir süreç değil — diğer ajanların güvenmeyi öğrendiği, müşteri sistemlerinin imzalarını kabul etmesi için söylendiği, denetim loglarında ve panellerde tek bir tanımlayıcı altında yaşayan adlandırılmış bir varlık. O kimlik yıllarca kalır; altındaki anahtarlar kalmamalı.

Mimari hamle, kimliği algoritmadan ayırmak. Bir ajanın sabit bir tanımlayıcısı (retrieval-agent), güncel bir anahtarı (retrieval-agent/keys/2026-05), ve o anahtarın bağlı olduğu bir algoritması (ML-DSA-65) var. Anahtar rotate olduğunda tanımlayıcı değişmez. Algoritma değiştiğinde tanımlayıcı yine değişmez. Aşağı akış doğrulayıcılar kimliğe güvenir, güncel anahtarı getirir, ve o anahtara bağlı algoritmayı kullanır — hepsi doğrulama anında okunur, hiçbiri sabit kodlu değil.

Bu yazıdan başka bir şey yapmayacaksan: ajan tanımlayıcısını anahtardan, anahtarı algoritmadan ayır. Üç katman, üç yaşam döngüsü. Ajan tanımlayıcısı ürünün hayatı kadar yaşar. Anahtar üç ayda bir rotate olur. Algoritma on yılda bir değişir. Bu üçünü karıştıran bir sistem, herhangi biri değiştiğinde kendini yeniden yazar.

Değişiklik iki: imzalı trace'lerin yıllarca doğrulanması gerek

Varsayılan gözlemlenebilirlik, her ajan kararının trace'lendiği ve trace'in sonradan değiştirilemeyecek şekilde imzalandığı anlamına gelir. 2029'da bir müşterinin denetçisi, 2026'da ajanımız tarafından üretilen trace'in gerçekten yayınladığımız trace olduğunu doğrulayabilmeli. Bu gereklilik post-quantum'la çarpışır: bugün üretilen herhangi bir imza, altındaki algoritma deprecate edildikten sonra bile doğrulanabilir kalmak zorunda.

İki pattern bunu temiz halleder. Birincisi — trace zarfı imzayla birlikte algoritma kimliğini ve anahtar kimliğini de taşır; böylece 2029'daki bir doğrulayıcı trace'i okur ve şunu bilir: 'bu ML-DSA-65 ile retrieval-agent/keys/2026-05 anahtarı altında imzalandı — o anahtarı getir, o algoritma altında doğrula.' İkincisi — doğrulayıcı registry'si, üretimde kullanılmış bir algoritmayı asla desteklemeyi bırakmaz. Algoritmalar yeni imzalar için emekli olabilir (artık ML-DSA-65 ile yeni trace üretmiyoruz) ama eski imzalar için kabul edilmeye devam eder (2026'da imzalanan her trace hâlâ doğrulanır). Göç ekleyicidir, asla yıkıcı değil.

Değişiklik üç: ajanlar, kontrol etmediğin sistemlerle federe oluyor

Gerçek deploymentlerda ajanlarımız sadece birbirleriyle konuşmuyor. Müşteri SSO'suna kimlik doğruluyor, marketplace API'leri ile federe oluyor, webhook geri-aramalarını imzalıyor, partner sistemlerle karşılıklı kimlik doğrulanmış istek değişiyor. Bu karşı tarafların her birinin kendi kripto yol haritası, kendi göç takvimi, kendi mirası var. Bazıları post-quantum'da bizden ileride olacak. Çoğu geride.

Bu heterojenliği yaşatan pattern, genel post-quantum geçişini yaşatan pattern'ın aynısı: her federe kenarda hibrit. Bir karşı tarafla oturum anahtarı üzerinde anlaşırken, hem X25519 hem ML-KEM-768 katkısı sun, oturum anahtarını ikisinden türet, karşı tarafın klasik katkısını eğer sadece o varsa kabul et. Sistem sınırlarını aşan artefaktları imzalarken çift imzala — biri klasik, biri post-quantum — ve doğrulayıcının hangisini anlıyorsa onu seçmesine izin ver. Federe kenar, bugün karşı tarafın desteklediği her şeye zarafetle düşmek ve yarın gönderdiği her güçlüyü zarafetle kabul etmek zorunda.

Dört operasyonel hamle

Tüm bunları üretimdeki bir ajan runtime'ı için somut işe çevirmek.

1. **Her ajana, anahtar olmayan sabit bir tanımlayıcı ver.** Tanımlayıcı (retrieval-agent, goddo/generator/v3) kimlik-ve-erişim registry'nde yaşar. Anahtarlar tanımlayıcının altında asılı durur ve bağımsız rotate olur. Bir müşteri bir ajana güvendiğinde, tanımlayıcıya güvenir; altındaki anahtar ilişkiyi bozmadan değişebilir.
2. Trace zarfını ilk günden `alg` ve `kid` ile kur. Sistemin bugün sadece bir algoritmayı desteklese bile, zarfın biçimi — {trace_id, agent_id, key_id, alg, signature, content_hash} — beş algoritmayı desteklediğin günkü biçimle aynı olmalı. Bir zarfı sonradan retrofit etmek, kalıcı her trace'i yeniden yazmak demek.
3. Doğrulayıcı registry'sini sonsuza dek ekleyici bir harita olarak çalıştır. Algoritmalar imzalayıcı registry'sinden kaldırılabilir (artık yeni ML-DSA-44 imzaları üretmiyoruz), ama doğrulayıcı registry'si üretimde kullanılmış her algoritmayı tutar. Asimetri esas mesele: imzalama günceldir, doğrulama tarihseldir.
4. Her federe kenarda varsayılan hibrit. Müşteri SSO'su, marketplace API'leri, webhook geri-aramaları, partner mTLS. Her biri hem klasik hem post-quantum yeteneği duyurur; her biri karşı tarafın kaldırabildiğini kabul eder. Çoğu ekibin göçü federe kenarda kırılır; hibrit, onu sıkıcı tutan kaldıraçtır.

Hepsinde geri ödeme yapan tek bahis

Dört hamleyi tek bir mimari bahse sıkıştırmak zorunda olsaydım, şu olurdu: ajanın kimliği, güncel anahtarları ve o anahtarların bağlı olduğu algoritmalar üç ayrı katmandır, her birinin kendi yaşam döngüsü vardır, ve uygulama kodu yalnızca kimliği adlandırır. Kod asla 'bu ML-DSA ile imzalandı' ya da 'bu ajan için anahtarı getir' demez. Kod 'bu trace retrieval-agent'tan; doğrula' der. Geri kalan her şey veri — getirilir, aranır, takas edilir, emekli edilir — kod bilmeden.

O bahis, kripto-çevikliğin tek bir uygulama için yaptığı bahsin aynısı; sadece bir katman yukarıda yapılıyor. Uygulama algoritmayı adlandırmıyor. Ajan algoritmayı adlandırmıyor. Doğrulayıcı algoritmayı adlandırmıyor. Her algoritma adı, artefakta ya da anahtara takılı metadata içinde yaşıyor. Kod tabanı kriptografi konusunda sessizdir — ve kriptografi konusunda sessiz bir kod tabanı, bir sonraki göçten sağ çıkan kod tabanıdır.

“Post-quantum bizim için bir kriptografi projesi değil. Bir mimari projesi — başından beri yaptığımız aynı proje: ajan kimliğini sabit tut, anahtarları takas edilebilir tut, algoritmaları veri olarak tut. Yeni bir NIST standardı geldiği gün, uygulama fark etmemeli. Bu şekilde inşa etmenin tüm amacı bu.”

Şu anda çok ajanlı bir sistem işletiyorsan bu ne anlama geliyor

Üç şey, sırayla.

1. Zarflarını denetle. Ajanlarının ürettiği, on saniyeden uzun süre sonra doğrulanması gereken her artefakt için — trace'ler, imzalı mesajlar, federe token'lar, denetim logları — birini aç ve cevapla: algoritma kimliğini ve anahtar kimliğini taşıyor mu? Taşımıyorsa, ilk biletin bu. Zarf biçimini sonradan retrofit etmek, sonra yapılacak en pahalı şey.
2. Tanımlayıcılarını denetle. Her ajan için sor: belirli bir anahtara bağlı olmayan sabit bir tanımlayıcısı var mı? Altındaki anahtar, aşağı akışta bir şey kırmadan değişebilir mi? Cevap hayırsa, ikinci bilet ara katmanı eklemek.
3. Federe kenarlarını denetle. Ajanlarının kontrolün dışındaki bir sistemle konuştuğu her kenar için sor: bu kenar pazarlık edebiliyor mu? Karşı tarafın bizden farklı bir kripto neslinde olmasına izin veriyor mu, ve iki taraf da desteklediğinde hibrit gönderebiliyor mu? Hibrit her karşı tarafla bir sözleşme değişikliği; sohbete erken başla.

Hiçbiri özellikle post-quantum değil. Hepsi post-quantum göçünü sessiz bir göç haline getiriyor, ve hepsi sonraki kriptografik geçişi de daha sessiz bir geçiş haline getiriyor. İlk üç göç, mimariye ödeme yaptığın yer; dördüncüsü, mimarinin sana geri ödemeye başladığı yer. GOGOGO LLC'de inşa ettiğimiz runtime, o uzun bakış açısı için tasarlandı — birçok ajan, uzun ömürlü kimlikler, takas edilebilir anahtarlar, değiştirilebilir algoritmalar — çünkü alternatifi, zemin her kaydığında yeniden yazmak. Nasıl inşa ettiğimiz üzerine daha fazlası gogogollc.com'da.