Codex, alt ajan istemi şifrelemesini başlattı

 (github.com/openai)
2 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Codex CLI’nin MultiAgentV2’si spawn_agent, send_message, followup_task mesajlarını şifrelediği için, üst rollout’larda, geçmişte ve izlerde devredilen içeriğin insan tarafından okunamaz hâle geldiği bir denetim izi regresyonu ortaya çıktı
  • 5 Haziran 2026’da birleştirilen PR #26210’dan sonra InterAgentCommunication.content boş bırakılıyor, payload yalnızca encrypted_content içinde saklanıyor; alıcı geçmişi ve iletişim günlükleri de şifreli metin kaydediyor
  • Sorun abonelikten, modelden ve platformdan bağımsız; MultiAgentV2’nin etkin olduğu 0.137.0 sonrası derlemeleri kapsıyor ve şifreleme aracı şemasında istek doğrulama hatasını ele alan #26753’ten ayrı
  • Önerilen düzeltme, alıcı model için şifreli message ile yerel denetim için zorunlu düz metin alanını birlikte saklamak; ancak aktarım eşleştirmesinde şifreli metin veya ID kullanmak ve düz metin denetim verilerine aynı boyut sınırını uygulamak
  • spawn_agent prototipi ayrı bir snapshot commit’inde uygulanmış olsa da aynı sözleşmenin send_message ve followup_task ile geçmiş, yeniden oynatma ve debug ekranlarına uygulanması işi sürüyor; issue hâlâ Open durumunda

Etki kapsamı ve regresyon koşulları

  • Şifreleme değişikliği PR #26210 5 Haziran 2026’da birleştirildi; bunu içeren ve MultiAgentV2’yi etkinleştiren 0.137.0 sonrası derlemeler kapsamda
  • Etkilenen araçlar spawn_agent, send_message, followup_task; abonelik, model, işletim sistemi ve terminal ortamından bağımsız
  • Bu, yerel ortam durumundan değil birleştirilmiş kod davranışından doğrulanan bir regresyon olduğu için Codex doctor raporları geçerli değil
  • Yeniden üretme adımları şöyle
    1. PR #26210’u içeren bir derlemede MultiAgentV2’yi etkinleştirin
    2. Modelin spawn_agent, send_message, followup_task araçlarından birini çağırmasını sağlayın
    3. Üst rollout’ta, geçmişte veya izde alt ajan görevini kontrol edin
    4. Görev ya da mesaj gövdesi yerine yalnızca şifreli metin göründüğünü doğrulayın

Kaybolan yerel denetim bilgileri

  • Şifreli aktarımın kendisi gizlilik güçlendirmesi olarak anlaşılabilir; ancak mevcut uygulama, yerel rollout geçmişinde, iz özetlemesinde ve üst taraftaki denetim/debug ekranlarında insan tarafından okunabilir içeriği kaldırıyor
  • Bunun sonucu olarak rollout sonrası incelemede şu soruları yanıtlamak zorlaşıyor
    • spawn_agent çocuk ajana hangi görevi verdi?
    • Alt ajana hangi mesaj gönderildi?
    • Belirli bir çocuk thread neden oluşturuldu?
  • Issue #26753, şifreleme aracı şemasının istek doğrulama sürecinde 400 hatası döndürmesiyle ilgili; bu issue ise şema onaylandıktan sonraki denetlenebilirlik ve debug edilebilirlik konusunu ele alıyor
  • Amaç, şifreli aktarımı mutlaka geri almak değil; şifrelemeyi korurken yerelde devredilen içeriğin okunabilmesini sağlamak

Mevcut koddaki veri akışı

  • InterAgentCommunication::new_encrypted(), content değerini boş string olarak başlatıyor ve payload’u yalnızca encrypted_content içine kaydediyor
    • Normal kurucu new(), düz metni content içine kaydedip encrypted_content alanını boş bırakıyor
    • Şifreleme kurucusu ise tersine content alanını boş bırakıp değeri encrypted_content içine koyuyor
  • to_model_input_item(), encrypted_content varsa ResponseItem::AgentMessage içine yalnızca NEW_TASK veya MESSAGE başlığını ve şifreli payload’u koyuyor
    • Bu nedenle runtime’da sadece content doldurulsa bile okunabilir ResponseItem otomatik olarak kalıcılaştırılmıyor
    • Ayrı bir yerel denetim saklama yolu gerekiyor
  • communication_from_tool_message(), aracın message değerini doğrudan new_encrypted() içine geçirerek düz metin content içermeyen bir iletişim nesnesi oluşturuyor
  • send_message ve followup_task argüman işleme, yalnızca target ve şifreli message alanlarını deserialize ediyor
    • Boş message reddediliyor, ancak ayrı bir eşlik eden düz metin alanı yok
    • Ortak mesaj aktarım yolu, bu değeri doğrudan InterAgentCommunication oluşturmak için kullanıyor

Geçmişte ve günlüklerde neden şifreli metin kalıyor

  • Alıcı taraf kayıt yolu, to_model_input_item() tarafından oluşturulan model amaçlı ResponseItem değerini konuşma geçmişine ve rollout’a kaydediyor
    • Şifreli iletişimde bu öğe, okunabilir bir denetim metni yerine şifreli aktarım payload’u içeriyor
    • Rollout’a InterAgentCommunicationMetadata ile ilgili ResponseItem birlikte kalıcılaştırılıyor
  • Yapılandırılmış iletişim günlüğü de content boşsa, olayın content değeri olarak encrypted_content alanını kullanıyor
  • Bu yapıda insanın okuyacağı mesaj olarak gösterilen alanlara da şifreli metin girdiği için, aktarım şifrelemesini koruma gereksinimi ile yerel denetim verisini koruma gereksinimi birbirinden ayrılmıyor

Önerilen çift içerik sözleşmesi

  • Mevcut şifreli message, alıcı modele aktarılacak payload olarak korunur
  • Her MultiAgentV2 iletişim aracına zorunlu bir düz metin denetim alanı eklenir
    • spawn_agent: task_message
    • send_message, followup_task: task_message veya message_text gibi tutarlı bir ad
  • Handler sınırında boş düz metin denetim değerleri reddedilir
  • InterAgentCommunication iki değeri birlikte saklar
    • encrypted_content: şifreli message
    • content: insan tarafından okunabilir denetim kopyası
  • to_model_input_item() değiştirilmez; böylece alıcı modele yerel denetim kopyası değil, yalnızca şifreli metin aktarılır
  • Üst araç çağrısı ve rollout içinde düz metin alan kalıcılaştırılır; yapılandırılmış izdeki etkileşim kenarlarında ve yerel iletişim günlüklerinde de korunur
  • Araç çağrısı ile çocuk aktarım öğesi arasındaki korelasyon, düz metin eşleşmesiyle değil şifreli metin veya ID ile belirlenir
    • Düz metin alanı denetim metadatasıdır; şifreli aktarımın tanımlayıcısının yerine geçmez
  • Yeni düz metin denetim alanına, karşılık gelen devir mesajıyla aynı zorunlu boyut sınırı uygulanır; böylece rollout veya bağlam öğeleri sınırsız büyümez

spawn_agent prototipi ve kalan işler

Tamamlanma koşulları ve mevcut durum

  • Üst rollout ve geçmişte v2 spawn_agent, send_message, followup_task düz metinleri okunabilmeli
  • Şifreleme etkin olduğunda bile çocuk model yalnızca şifreli aktarım payload’unu almalı
  • Yapılandırılmış rollout iz kenarlarında boyutu sınırlandırılmış düz metin message_content bulunmalı
  • İletişim günlükleri, düz metin denetim içeriği varsa bunu kullanmalı ve okunabilir mesaj alanına onun yerine şifreli metin koymamalı
  • Devam ettirme ve yeniden oynatma, denetim kopyasını korumalı ancak bunu çocuk model bağlamına enjekte etmemeli
  • Mevcut düz metin v1 iletişim davranışı değişmemeli
  • Üç v2 aracının tamamı için okunabilir yerel denetim verisi ile şifreli alıcı model girdisini birlikte doğrulayan regresyon testleri gerekli
  • Sağlanan sayfada issue Open durumunda; üst depoya bir düzeltmenin birleştirildiğine dair sonuç yok

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Bu başlık yanlış anlaşılmaya çok açık. Doğru anlamı, Codex’in alt ajan istemlerini şifreleyip kullanıcıdan gizlemeye başladığı
    Orijinal başlık “Codex starts encrypting prompts, uses ciphertext for inference instead” idi

    • Muhtemelen GPT-5.6’nın ultra modu işi birden fazla alt ajana dağıttığı için devreye alındı. Daha önce bu mod yalnızca web UI’da sunuluyordu ve muhtemelen eski pro moduna karşılık geliyordu
      Eğer ajanların birbiriyle etkileştiği tam pekiştirmeli öğrenme rollout’larıyla eğitildiyse, OpenAI bu istemleri ham akıl yürütme izleri gibi değerlendirip başkalarının doğrudan eğitimde kullanmasını engellemeye çalışıyor olabilir
      Özel sıkıştırma endpoint’inin döndürdüğü opak sıkıştırılmış blob da metin değil, konuşmanın gizil uzay temsili olabilir; OpenAI’nin sıkıştırma sadakatinin diğer şirketlerden çok daha yüksek olması da bu tahmini destekliyor. Benzer bir tekniği alt ajan istemlerine de uygulamış olabilirler; ayrıca farklı model türlerinden alt ajanlar üretirken de şifrelenmiş blob kullanıp kullanmadıklarını merak ediyorum
    • Yerel bilgisayarda onlarca ila yüzlerce olasılıksal ajanın çalışması ama bu ajanların aldığı talimatları bile denetleyememek saçma
      Claude’un alt ajanlarını ve iş akışını incelerken “bu zaten en başta çalıştırılmamalıydı” diye düşündüğüm oldu; Codex kullanıcıları ise orkestratörün alt ajanlara ilettiği şifreli yönlendirmelere ve shell görevlerine token’larını körü körüne harcamak zorunda kalıyor
    • Codex’in fikri mülkiyetinin önemli bir kısmı kod tabanından çok istemlerin kurgusu, sıralaması ve orkestrasyonu içinde olabilir
      Biz de şirketlerin tercih ettiği ya da zorunlu tuttuğu AI sağlayıcısını ve kendi API anahtarlarını seçmelerine izin verip basit bir ücretlendirme sunmak istemiştik, ama backend istemlerinin müşteriye sızabileceğini kısa sürede fark ettik. Ayrıntılı yürütme izleri elde edilirse yaptığımız şeyin nispeten kolay biçimde tersine mühendislik edilebileceğini gördüğümüz için sonunda bu fikirden vazgeçtik
    • İlk başta bunun homomorfik şifreleme gibi bir teknoloji olduğunu düşündüm, ama sonunda sıradan açgözlülük gibi görünüyor
    • Codex’in bir şeyi şifrelediği ilk olay bu değil. Mükemmel sıkıştırma endpoint’i en az 5 aydır devasa şifreli blob’lar döndürüyor

  • Kodlama ajanı oturumlarını denetleyen yerel aracımın bazı durumlarda neden çalışmayı bıraktığını artık anlıyorum
    Kullanıcının bilgisayarında çalıştırılacak harici şifreleme komutunu kaç kişinin kabul edeceğini merak ettiğim ilginç bir tasarım kararı

    • OpenAI’nin teşvikleri, kurumsal müşteriler dahil kullanıcılarınkilerle tam olarak örtüşmüyor gibi görünüyor. Alex Karp ve Satya Nadella gibi isimlerin son açıklamalarına da bakmaya değer
      İçeriği şifreleyip kullanıcıdan saklamak, RIAA’nın telif ihlalinden endişe edip DRM’de kullandığı yöntemdi; bunun da kullanıcıya karşı bir tercih olup olmadığını sorguluyorum
    • YOLO modu kullanıyorsanız zaten bu riski almışsınızdır; önemli olan araç çağrılarıdır. Araç çağrılarının kendisi şifrelenemez

  • Bu tür davranışlar yüzünden hâlâ Chat Completions endpoint kullanıyorum. OpenAI kullanıcıları Chat Completions’tan çıkarıp karartması daha kolay olan Responses API’ye doğru ince ince yönlendiriyor
    Chat Completions’ta akıl yürütme sürecini doğrudan kontrol edebiliyorsunuz; deneysel özellikleri açıp biraz karmaşık seçenekler ayarlarsanız mevcut GPT-5.6 modeliyle özel bir Monte Carlo Tree Search (MCTS) ajanı bile kurabilirsiniz
    VS Copilot’ta kullanıcı API token’ı ve model ayarlarıyla gpt5.5’e kadar kullanılabiliyor, ama gpt5.6 ailesi şu anda çalışmıyor. Muhtemelen yeni giriş engeli artırma davranışını karşılamak için reasoning_effort değerini none olmaya zorlamadığı için

    • Burada sözü edilen MCTS tekniğinin tam olarak ne olduğunu merak ediyorum. Zaten verilen düşünce süreci aşırı soyut özetleniyor ve pek işe yaramıyor; gerçekten akıl yürütme sürecinin tamamen kontrol edilip edilemediğinden de emin değilim
    • MCTS, Monte Carlo Tree Search ifadesinin kısaltmasıdır
    • Burada MCTS’nin moda sözcük gibi aşırı kullanılmamasını isterdim. İşaret edilen yöntem teknik olarak tam anlamıyla MCTS değil
    • Responses API, Chat Completions’a göre birçok avantaj sunuyor: https://developers.openai.com/api/docs/guides/migrate-to-res...
      Bugün çıkan tüm yeni modeller akıl yürütme modeli olduğundan, öneri doğrultusunda Responses API kullanılmalı

  • GPT aboneliğinin alternatif yürütme araçlarında kullanılmasının engellenip engellenmeyeceği de merak konusu. Bu yapılmazsa büyük bir sorun değil; codex clinin kendisi şaşırtıcı derecede sıradan bir yürütme aracı

    • Bu pek olası görünmüyor. Tüm app-server yapısı zaten tam olarak bu entegrasyonu desteklemek için var, dolayısıyla bunu Codex’ten kaldırmak isterlerse çok büyük parçaları söküp atmaları gerekir
      Ben de app-serverın RPC API’siyle çok kolay entegre olabildiğim için Codex’i en çok kullanıyorum ve artık herkese açık Codex TUI yerine neredeyse her şeyi kendi yazdığım entegrasyon üzerinden kullanıyorum
      Ama yerel diskteki gerçek çıkarım girdileri olan prompt’lar vb. şifrelenip yalnızca OpenAI backend’inin görebileceği hale getirilirse, entegrasyon kolay olsa bile neler olduğunu anlamak imkansız hale geliyor. Ekibin bunu neden iyi bir tercih gördüğünü anlamak zor
    • Anthropic ve Google, kendi yürütme araçları kullanıldığında zaten ek ücret alıyor; OpenAI kullanma nedenim de tamamen bu
      OpenAI de aynı yola girerse tekrar Claude’a dönmeyi ya da bir Spark daha alıp yerelde çalıştırmayı düşünüyorum
    • Anthropic kurumsal benimsemede öndeyken bunu engellemezler gibi görünüyor. OpenAI açık ara liderliğe geçerse işlerin nasıl değişeceğini bilemem, ama o zamana kadar açık modellerin gpt-5.6 sol’dan daha iyi olmasını umuyorum
    • Codex’in kendisi artık aboneliği saran bir proxy sağlamaya başladığı için bunu engelleme ihtimalleri düşük görünüyor
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • OpenAI’den Tibo kısa süre önce Twitter’da Claude Code ile GPT çalıştırma yöntemlerinin paylaşılmasını istemişti; bu da alternatif yürütme araçlarının kullanımına karşı olmadıklarını düşündürüyor

  • Önceki HN başlığı, sanki doğrudan şifreli metin üzerinde çıkarım yapılıyormuş gibi duyuluyordu ve çok yanlış anlaşılmaya yol açtı. Bunun için şu anda bilinen seviyenin çok ötesinde gelişmiş homomorphic encryption gerekir

    • Aslında yapılan şey, ajanın alt ajana gönderdiği içeriği şifreleyip yalnızca OpenAI backend’inin düz metni görebilmesini sağlamak
      Eskiden ajan, alt ajana düz metin prompt gönderiyordu ve bu içerik log’larda ve oturum verilerinde de aynen kaldığı için, deneysel alt ajan özelliği kullanılırken bile verileri açıp iç işleyişi incelemek mümkündü
      Artık Sol veya Terra kullanıldığında backend’in ürettiği şifreli metin alt ajana iletiliyor ve alt ajan da bunu yeniden OpenAI backend’inin çıkarımında kullanıyor. Luna bundan etkilenmiyor gibi görünüyor; ayrıca tüm oturum değil, yalnızca devredilen ajanlar arasındaki mesajlar şifreleniyor
      OpenAI içindeki çıkarım şifreli metin üzerinde yapılmıyor, ama yerel kullanıcı artık düz metin yerine yalnızca şifreli metni görüyor. Bunu netleştirmek için başlığı “Codex starts encrypting sub-agent prompts” olarak değiştirdim
    • Başlıkta “inferencing” geçtiği için benim de aklıma hemen homomorphic encryption ya da şifreli metin üzerinde hesaplama geldi

  • Kısa süre önce Twitter’da GPT-5.6 alt ajanının yanlışlıkla kullanıcının home directory’sini sildiğine dair bir bildirim vardı
    Alt ajanın ne yapmaya çalıştığını artık göremediğimiz için, güvenlik önlemlerinin de başarısız olup olmadığını merak ediyorum
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • Bu, token kullanımını azaltmak için istemci üzerinden cache key iletme yöntemi. Başka alt görev araçları kullanılarak kolayca aşılabildiğinden, model damıtmayı önlemeye yönelik bir savunma olması mümkün değil

  • Şifrelemenin tam olarak nerede yapıldığını merak ediyorum. Ana ajanın alt ajanı yerelde çağırdığını sanıyordum; Codex’in yapısı, yerel makineye ulaşmadan önce alt ajanı OpenAI sunucularında çağırıyor olabilir mi diye düşünüyorum

    • Eskiden ajan alt ajana düz metin prompt gönderiyordu ve bu içerik log’larda ve oturum verilerinde de aynen kaldığı için iç işleyişi kolayca incelemek mümkündü
      Sol veya Terra’da prompt yerine OpenAI backend’inin ürettiği şifreli metin iletiliyor ve alt ajan da bunu yeniden backend çıkarımında kullanıyor. Luna etkilenmiyor gibi görünüyor; ayrıca tüm oturum değil, yalnızca devredilen ajanlar arası mesajlar şifrelendiğinden, artık bu içeriği sadece OpenAI backend’i çözebiliyor

  • Çin’deki karaborsa yeniden satış servislerinin neden dünden beri çalışmadığını merak ediyordum; muhtemelen sebep bu değişiklik

    • Bu karaborsalar yalnızca abonelikleri toplayıp yeniden satmakla kalmıyor, verileri depolayıp daha sonra modeli eğiten yerlere de satıyor. Şifreleme en azından bu ikinci davranışı engellemekte işe yarar; daha önce ortaya çıkan diğer yöntemlerle amaç aynı ama uygulama çok daha temiz

  • Asıl amaç, çok sayıda kullanıcı isteği ve yanıtını proxy’leyip rakip modellerin eğitiminde kullanma girişimlerini zorlaştırmak gibi görünüyor

    • Diğer sağlayıcıların OpenAI’nin çok ajanlı orkestrasyon yöntemini incelemesini engelleme niyeti açıkça görülüyor
      Ama ücretli kullanıcılar için, bir sorun çıktığında nedenini anlamanın hiçbir yolu kalmadığından, çok ajanlı özellikleri düzgün kullanmayı zorlaştıran berbat bir uygulama bu