Codex mulai mengenkripsi prompt subagen

 (github.com/openai)
2 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • MultiAgentV2 di Codex CLI mengenkripsi pesan spawn_agent, send_message, dan followup_task, sehingga terjadi regresi jejak audit yang membuat isi delegasi tidak bisa dibaca manusia dari rollout induk, riwayat, dan pelacakan
  • Setelah PR #26210 digabung pada 5 Juni 2026, InterAgentCommunication.content dikosongkan dan payload hanya disimpan di encrypted_content, sementara riwayat penerima dan log komunikasi juga mencatat ciphertext
  • Masalah ini tidak bergantung pada langganan, model, atau platform, dan berlaku untuk build sejak 0.137.0 saat MultiAgentV2 diaktifkan; ini terpisah dari #26753 yang menangani kegagalan validasi permintaan pada skema alat enkripsi
  • Perbaikan yang diusulkan adalah menyimpan bersama message terenkripsi untuk model penerima dan field plaintext wajib untuk audit lokal, sambil tetap memakai ciphertext atau ID untuk identifikasi pengiriman dan menerapkan batas ukuran yang sama pada data audit plaintext
  • Prototipe untuk spawn_agent sudah diimplementasikan dalam commit snapshot terpisah, tetapi pekerjaan untuk menerapkan kontrak yang sama ke send_message, followup_task, serta layar riwayat, replay, dan debug masih tersisa, dan isu ini masih berstatus Open

Cakupan kejadian dan kondisi regresi

  • PR perubahan enkripsi #26210 digabung pada 5 Juni 2026, dan yang terdampak adalah build sejak 0.137.0 yang mencakup perubahan ini dan mengaktifkan MultiAgentV2
  • Alat yang terdampak adalah spawn_agent, send_message, dan followup_task, serta tidak bergantung pada langganan, model, sistem operasi, atau lingkungan terminal
  • Karena ini adalah regresi yang terlihat dari perilaku kode yang sudah digabung, bukan dari status lingkungan lokal, laporan Codex doctor tidak relevan
  • Langkah reproduksinya sebagai berikut
    1. Aktifkan MultiAgentV2 pada build yang mencakup PR #26210
    2. Buat model memanggil salah satu dari spawn_agent, send_message, atau followup_task
    3. Periksa pekerjaan subagen pada rollout induk, riwayat, dan pelacakan
    4. Yang terlihat hanya ciphertext, bukan isi tugas atau badan pesan

Informasi audit lokal yang hilang

  • Pengiriman terenkripsi itu sendiri bisa dipahami sebagai penguatan privasi, tetapi implementasi saat ini juga menghapus isi yang bisa dibaca manusia dari riwayat rollout lokal, ringkasan pelacakan, dan layar audit/debug di sisi induk
  • Akibatnya, saat meninjau rollout setelah kejadian, sulit menjawab pertanyaan berikut
    • Tugas apa yang diberikan spawn_agent kepada agen anak
    • Pesan apa yang dikirim ke subagen
    • Mengapa thread anak tertentu dibuat
  • Isu #26753 adalah masalah skema alat enkripsi yang mengembalikan error 400 saat validasi permintaan, sedangkan isu ini membahas kemampuan audit dan debugging setelah skema disetujui
  • Tujuannya bukan harus membatalkan pengiriman terenkripsi, melainkan mempertahankan enkripsi sambil tetap memungkinkan isi delegasi dibaca secara lokal

Alur data pada kode saat ini

  • InterAgentCommunication::new_encrypted() menginisialisasi content sebagai string kosong dan hanya menyimpan payload di encrypted_content
    • Konstruktor biasa new() menyimpan plaintext di content dan membiarkan encrypted_content kosong
    • Konstruktor terenkripsi melakukan kebalikannya: mengosongkan content dan menaruh nilai di encrypted_content
  • to_model_input_item() bila encrypted_content ada, hanya memasukkan awalan NEW_TASK atau MESSAGE dan payload terenkripsi ke ResponseItem::AgentMessage
    • Karena itu, walaupun content runtime diisi, ResponseItem yang bisa dibaca dan otomatis dipersistenkan tidak akan terbentuk
    • Dibutuhkan jalur penyimpanan audit lokal yang terpisah
  • communication_from_tool_message() langsung meneruskan message dari alat ke new_encrypted(), sehingga membuat objek komunikasi tanpa content plaintext
  • Pemrosesan argumen send_message dan followup_task hanya mendeserialisasi target dan message terenkripsi
    • message kosong ditolak, tetapi tidak ada field pendamping plaintext terpisah
    • Jalur pengiriman pesan bersama menggunakan nilai ini apa adanya untuk membuat InterAgentCommunication

Mengapa ciphertext tersisa di riwayat dan log

  • Jalur pencatatan di sisi penerima menyimpan ResponseItem untuk model yang dibuat oleh to_model_input_item() ke riwayat percakapan dan rollout
    • Pada komunikasi terenkripsi, item ini berisi payload pengiriman terenkripsi, bukan kalimat audit yang bisa dibaca
    • Rollout memersistenkan InterAgentCommunicationMetadata bersama ResponseItem tersebut
  • Log komunikasi terstruktur juga mengganti content yang kosong dengan encrypted_content sebagai content event
  • Dalam struktur ini, bahkan field yang ditampilkan sebagai pesan untuk manusia juga berisi ciphertext, sehingga kebutuhan mempertahankan enkripsi pengiriman dan mempertahankan data audit lokal tidak dipisahkan

Kontrak konten ganda yang diusulkan

  • message terenkripsi yang ada dipertahankan sebagai payload untuk pengiriman ke model penerima
  • Tambahkan field audit plaintext wajib ke setiap alat komunikasi MultiAgentV2
    • spawn_agent: task_message
    • send_message, followup_task: nama yang konsisten seperti task_message atau message_text
  • Tolak nilai audit plaintext kosong di batas handler
  • Simpan kedua nilai itu di InterAgentCommunication
    • encrypted_content: message terenkripsi
    • content: salinan audit yang bisa dibaca manusia
  • to_model_input_item() tidak diubah, sehingga model penerima tetap menerima hanya ciphertext, bukan salinan audit lokal
  • Persistenkan field plaintext pada pemanggilan alat induk dan rollout, serta pertahankan juga pada edge interaksi di pelacakan terstruktur dan log komunikasi lokal
  • Korelasi antara pemanggilan alat dan item pengiriman anak ditentukan lewat ciphertext atau ID, bukan kecocokan plaintext
    • Field plaintext adalah metadata audit dan tidak menggantikan identifier pengiriman terenkripsi
  • Terapkan batas ukuran yang sama pada field audit plaintext baru seperti pada pesan delegasi terkait, agar rollout atau item konteks tidak membesar tanpa batas

Prototipe spawn_agent dan pekerjaan yang tersisa

Syarat selesai dan status saat ini

  • Plaintext untuk v2 spawn_agent, send_message, dan followup_task harus bisa dibaca dari rollout dan riwayat induk
  • Saat enkripsi aktif, model anak tetap harus menerima hanya payload pengiriman terenkripsi
  • Edge pada pelacakan rollout terstruktur harus memuat message_content plaintext yang dibatasi ukurannya
  • Log komunikasi harus menggunakan konten audit plaintext bila tersedia, dan tidak mengganti field pesan yang bisa dibaca dengan ciphertext
  • Resume/replay harus mempertahankan salinan audit tanpa menyuntikkannya ke konteks model anak
  • Perilaku komunikasi v1 plaintext yang sudah ada tidak boleh berubah
  • Untuk ketiga alat v2, dibutuhkan regression test yang memverifikasi sekaligus data audit lokal yang bisa dibaca dan input model penerima yang terenkripsi
  • Pada halaman yang diberikan, isu ini masih berstatus Open, dan tidak ada hasil bahwa perbaikan sudah digabung ke repositori utama

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Judul ini mudah menyesatkan. Yang lebih tepat, Codex mulai mengenkripsi prompt subagen dan menyembunyikannya dari pengguna
    Judul aslinya adalah “Codex starts encrypting prompts, uses ciphertext for inference instead”

    • Kemungkinan besar ini diperkenalkan karena mode ultra di GPT-5.6 mendistribusikan pekerjaan ke beberapa subagen. Sebelumnya mode ini hanya tersedia di web UI, dan mungkin setara dengan mode pro lama
      Jika dilatih dengan rollout reinforcement learning penuh yang melibatkan interaksi antaragen, OpenAI tampaknya memperlakukan prompt ini seperti jejak penalaran mentah agar pihak lain tidak bisa langsung memanfaatkannya untuk pelatihan
      Blob terkompresi buram yang dikembalikan endpoint kompresi khusus juga bisa menjadi tanda bahwa itu bukan teks, melainkan representasi ruang laten dari percakapan, dan fakta bahwa fidelitas kompresi OpenAI jauh lebih tinggi daripada vendor lain mendukung dugaan ini. Teknik serupa mungkin juga diterapkan pada prompt subagen, dan menarik untuk tahu apakah mereka juga memakai blob terenkripsi saat membuat subagen dengan tipe model yang berbeda
    • Fakta bahwa puluhan hingga ratusan agen probabilistik berjalan di komputer lokal, tetapi kita bahkan tidak bisa memeriksa instruksi yang mereka terima, terasa absurd
      Saya pernah meninjau subagen dan alur kerja Claude lalu menyimpulkan, “ini seharusnya tidak dijalankan sejak awal”, tetapi pengguna Codex pada dasarnya harus membakar token secara membabi buta untuk instruksi penerusan terenkripsi dan tugas shell yang dikirim orkestrator ke subagen
    • Sebagian besar kekayaan intelektual Codex kemungkinan ada bukan pada codebase-nya, melainkan pada susunan prompt, urutannya, dan orkestrasi
      Kami juga sempat ingin membiarkan perusahaan memilih penyedia AI yang mereka sukai atau wajibkan beserta API key mereka sendiri, dan menawarkan paket harga sederhana, tetapi kami cepat menyadari bahwa prompt backend bisa bocor ke pelanggan. Jika jejak eksekusi yang rinci tersedia, akan relatif mudah melakukan reverse engineering terhadap apa yang kami lakukan, jadi akhirnya ide itu dibatalkan
    • Awalnya saya kira ini semacam teknologi seperti homomorphic encryption, tetapi pada akhirnya tampak seperti keserakahan biasa
    • Ini bukan pertama kalinya Codex mengenkripsi sesuatu. Endpoint kompresi yang sangat bagus itu sudah mengembalikan blob terenkripsi raksasa setidaknya sejak 5 bulan lalu

  • Sekarang saya paham kenapa alat lokal saya untuk memeriksa sesi coding agent berhenti bekerja dalam beberapa situasi
    Ini keputusan desain yang menarik: berapa banyak orang yang akan menerima perintah enkripsi eksternal yang dijalankan di komputer pengguna?

    • Insentif OpenAI tampaknya tidak benar-benar selaras dengan pengguna, termasuk pelanggan enterprise. Pernyataan terbaru dari Alex Karp dan Satya Nadella juga layak dicermati
      Menyembunyikan isi dari pengguna lewat enkripsi adalah pendekatan yang dulu dipakai RIAA untuk DRM karena khawatir soal pelanggaran hak cipta, jadi wajar dipertanyakan apakah ini juga pilihan yang memusuhi pengguna
    • Jika memakai mode YOLO, berarti Anda memang sudah menerima risiko semacam itu, dan yang penting adalah pemanggilan tool. Pemanggilan tool itu sendiri tidak bisa dienkripsi

  • Karena perilaku seperti ini saya tetap memakai endpoint Chat Completions. OpenAI secara halus mendorong pengguna menjauh dari Chat Completions ke Responses API yang lebih mudah diobfuscate
    Di Chat Completions, Anda bisa mengendalikan prosedur penalaran secara langsung, jadi dengan menyalakan fitur eksperimental dan mengatur beberapa opsi yang agak membingungkan, saat ini Anda bahkan bisa membuat agen custom Monte Carlo Tree Search (MCTS) dengan model GPT-5.6
    Di VS Copilot, Anda bisa memakai hingga gpt5.5 dengan token API pengguna dan pengaturan model, tetapi keluarga gpt5.6 saat ini tidak bekerja. Dugaan saya karena ia tidak memaksa reasoning_effort menjadi none agar memenuhi perilaku baru yang memperluas hambatan masuk ini

    • Saya penasaran teknik MCTS yang dimaksud di sini sebenarnya seperti apa. Lagi pula proses berpikir yang diberikan tetap diringkas terlalu abstrak sehingga tidak terlalu berguna, jadi saya juga ragu apakah prosedur penalarannya benar-benar bisa dikendalikan sepenuhnya
    • MCTS adalah singkatan dari Monte Carlo Tree Search
    • Saya harap MCTS tidak disalahgunakan sebagai buzzword di sini. Cara yang dimaksud bukan MCTS dalam arti yang ketat
    • Responses API punya banyak keunggulan dibanding Chat Completions: https://developers.openai.com/api/docs/guides/migrate-to-res...
      Semua model baru yang keluar belakangan ini adalah model penalaran, jadi mengikuti rekomendasi, Responses API memang sebaiknya digunakan

  • Ada juga yang penasaran apakah langganan GPT mungkin akan diblokir agar tidak bisa dipakai di alat eksekusi alternatif. Jika tidak, ini bukan masalah besar, dan codex cli sendiri adalah alat eksekusi yang sangat biasa saja

    • Kemungkinannya tampak kecil. Seluruh arsitektur app-server memang ada untuk mendukung integrasi seperti itu, jadi jika ingin menghapusnya dari Codex, mereka harus membongkar bagian yang sangat besar
      Saya juga bisa terintegrasi dengan sangat mudah lewat API RPC app-server, jadi saya paling sering memakai Codex, dan sekarang hampir semuanya saya gunakan lewat integrasi buatan sendiri alih-alih Codex TUI yang sudah dipublikasikan
      Namun jika prompt dan semacamnya, yang merupakan input inferensi nyata dari disk lokal, dienkripsi sehingga hanya backend OpenAI yang bisa melihatnya, maka meskipun integrasinya mudah, kita jadi tidak bisa memahami apa yang sebenarnya terjadi. Sulit mengerti kenapa tim menganggap ini pilihan yang baik
    • Anthropic dan Google sudah mengenakan biaya tambahan jika memakai alat eksekusi buatan mereka sendiri, dan itulah satu-satunya alasan memakai OpenAI
      Jika OpenAI menempuh jalan yang sama, saya akan kembali ke Claude atau membeli satu Spark lagi untuk dijalankan secara lokal
    • Selama Anthropic masih unggul dalam adopsi enterprise, sepertinya mereka tidak akan memblokirnya. Kalau OpenAI nanti memimpin dengan selisih besar, saya tidak tahu akan berubah seperti apa, tapi pada saat itu saya berharap model terbuka sudah lebih baik daripada gpt-5.6 sol
    • Karena Codex sendiri sudah mulai menyediakan proxy yang membungkus langganan, kecil kemungkinan mereka akan memblokirnya
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • Baru-baru ini Tibo dari OpenAI meminta orang membagikan cara menjalankan GPT dengan Claude Code di Twitter, jadi tampaknya mereka tidak menentang penggunaan alat eksekusi alternatif

  • Judul HN sebelumnya terdengar seolah inferensi dilakukan langsung pada ciphertext, sehingga sangat menyesatkan. Untuk itu dibutuhkan homomorphic encryption yang jauh lebih maju daripada tingkat yang saat ini diketahui

    • Sebenarnya, yang dilakukan adalah mengenkripsi konten yang dikirim agen ke sub-agen sehingga hanya backend OpenAI yang bisa melihat plaintext
      Dulu agen mengirim prompt plaintext ke sub-agen, dan itu juga tetap tercatat apa adanya di log serta data sesi, sehingga bahkan saat memakai fitur sub-agen eksperimental pun kita bisa membuka datanya dan memeriksa cara kerjanya di dalam
      Sekarang jika memakai Sol atau Terra, ciphertext yang dibuat backend dikirim ke sub-agen, lalu sub-agen memakainya lagi untuk inferensi di backend OpenAI. Luna tampaknya tidak terdampak, dan yang dienkripsi bukan seluruh sesi melainkan hanya pesan antar agen yang didelegasikan
      Inferensi internal OpenAI tidak dilakukan di atas ciphertext, tetapi bagi pengguna lokal yang terlihat hanyalah ciphertext, bukan plaintext. Untuk memperjelas hal ini, judulnya diubah menjadi “Codex starts encrypting sub-agent prompts”
    • Karena ada kata “inferencing” di judul, saya juga langsung terpikir homomorphic encryption atau operasi atas ciphertext

  • Baru-baru ini ada laporan di Twitter bahwa sub-agen GPT-5.6 secara tidak sengaja menghapus direktori home milik pengguna
    Saya jadi penasaran apakah dengan tidak bisa melihat apa yang hendak dilakukan sub-agen, mekanisme pengaman juga ikut gagal
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • Ini tampaknya cara untuk menurunkan pemakaian token dengan meneruskan cache key melalui klien. Karena bisa dengan mudah dilewati memakai alat sub-tugas lain, ini tidak mungkin merupakan langkah pertahanan terhadap distilasi model

  • Saya penasaran enkripsi ini tepatnya terjadi di mana. Saya kira agen utama memanggil sub-agen secara lokal, tetapi jadi bertanya-tanya apakah struktur Codex justru memanggil sub-agen dari server OpenAI sebelum sampai ke lokal

    • Sebelumnya agen mengirim prompt plaintext ke sub-agen, dan itu juga tetap tercatat apa adanya di log serta data sesi, sehingga cara kerja internalnya bisa dengan mudah diperiksa
      Di Sol atau Terra, ciphertext yang dibuat backend OpenAI dikirim alih-alih prompt, lalu sub-agen memakainya lagi untuk inferensi backend. Luna tampaknya tidak terdampak, dan yang dienkripsi bukan seluruh sesi melainkan hanya pesan antar agen yang didelegasikan, jadi sekarang isi tersebut hanya bisa didekripsi oleh backend OpenAI

  • Saya sempat penasaran kenapa layanan penjualan ulang pasar gelap dari Tiongkok tidak berfungsi sejak kemarin, dan mungkin ini penyebabnya

    • Pasar gelap seperti ini bukan hanya mengumpulkan langganan untuk dijual kembali, tetapi juga menyimpan data lalu menjualnya ke tempat yang melatih model. Enkripsi setidaknya berguna untuk mencegah praktik yang kedua; tujuannya sama dengan metode lain yang pernah terungkap sebelumnya, tetapi implementasinya jauh lebih rapi

  • Tampaknya tujuan utamanya adalah menghambat upaya mem-proxy permintaan dan respons pengguna dalam jumlah besar untuk dimanfaatkan melatih model pesaing

    • Jelas tampaknya ada niat untuk mencegah penyedia lain mengintip cara OpenAI mengelola multi-agent
      Namun bagi pengguna berbayar, ini adalah implementasi yang buruk karena ketika ada masalah mereka sama sekali tidak punya cara untuk mengetahui penyebabnya, sehingga sulit benar-benar memakai fitur multi-agent