Codex ने sub-agent prompt encryption शुरू किया

 (github.com/openai)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Codex CLI के MultiAgentV2 में spawn_agent, send_message, followup_task संदेशों को encrypt किया जाने लगा है, जिससे parent rollout, history और trace में delegation की सामग्री इंसानों के लिए अपठनीय हो जाती है — यह एक audit trail regression है
  • 5 जून 2026 को merge हुए PR #26210 के बाद InterAgentCommunication.content खाली कर दिया जाता है और payload केवल encrypted_content में रखा जाता है, जबकि recipient history और communication logs भी ciphertext दर्ज करते हैं
  • यह समस्या subscription, model या platform से स्वतंत्र है और MultiAgentV2 सक्षम होने वाले 0.137.0 के बाद के builds को प्रभावित करती है; यह encryption tool schema के request validation failure को संभालने वाले #26753 से अलग मुद्दा है
  • प्रस्तावित fix यह है कि recipient model के लिए encrypted message को रखा जाए, साथ ही local audit के लिए एक अनिवार्य plaintext field भी संग्रहीत की जाए; routing के लिए ciphertext या ID का उपयोग हो और plaintext audit data पर वही size limits लागू हों
  • spawn_agent के लिए prototype एक अलग snapshot commit में लागू किया गया है, लेकिन send_message, followup_task, और history, replay, debug screens तक यही contract लागू करना अभी बाकी है; issue अभी भी Open है

प्रभाव का दायरा और regression की शर्तें

  • Encryption change PR #26210 5 जून 2026 को merge हुआ था, और इसे शामिल करने वाले तथा MultiAgentV2 सक्षम किए गए 0.137.0 के बाद के builds प्रभावित हैं
  • प्रभावित tools हैं spawn_agent, send_message, followup_task; यह subscription, model, operating system या terminal environment पर निर्भर नहीं है
  • यह local environment state का नहीं, बल्कि merged code behavior का regression है, इसलिए Codex doctor report यहाँ लागू नहीं होती
  • reproduction steps इस प्रकार हैं
    1. PR #26210 शामिल करने वाले build में MultiAgentV2 सक्षम करें
    2. model से spawn_agent, send_message, followup_task में से किसी एक को call करवाएँ
    3. parent rollout, history या trace में sub-agent task को देखें
    4. task या message body की जगह केवल ciphertext दिखाई देता है

गायब हुई local audit जानकारी

  • encrypted delegation अपने-आप में privacy enhancement के रूप में समझी जा सकती है, लेकिन मौजूदा implementation local rollout history, trace summaries, और parent-side audit/debug screens से भी इंसानों के पढ़ने योग्य content हटा देती है
  • नतीजतन, बाद में rollout review के दौरान इन सवालों का जवाब देना कठिन हो जाता है
    • spawn_agent ने child agent को कौन-सा task दिया था
    • sub-agent को कौन-सा message भेजा गया था
    • किसी विशेष child thread को क्यों बनाया गया था
  • Issue #26753 उस समस्या के बारे में है जिसमें encryption tool schema request validation के दौरान 400 error लौटाता है; यह issue schema approval के बाद की auditability और debuggability पर केंद्रित है
  • लक्ष्य encrypted transport को हटाना नहीं, बल्कि encryption बनाए रखते हुए local स्तर पर delegation content को पढ़ने योग्य रखना है

मौजूदा code में data flow

  • InterAgentCommunication::new_encrypted() content को empty string से initialize करता है और payload को केवल encrypted_content में रखता है
    • सामान्य constructor new() plaintext को content में रखता है और encrypted_content को खाली छोड़ता है
    • encrypted constructor इसका उल्टा करता है: content खाली और encrypted_content में value
  • to_model_input_item() में encrypted_content होने पर सिर्फ NEW_TASK या MESSAGE header और encrypted payload को ResponseItem::AgentMessage में डाला जाता है
    • इसलिए runtime में केवल content भर देने से readable ResponseItem अपने-आप persist नहीं होता
    • एक अलग local audit storage path की ज़रूरत है
  • communication_from_tool_message() tool के message को सीधे new_encrypted() में भेजता है, जिससे plaintext content के बिना communication object बनता है
  • send_message और followup_task argument handling सिर्फ target और encrypted message को deserialize करती है
    • empty message को reject किया जाता है, लेकिन साथ में कोई अलग plaintext field नहीं है
    • shared message transport path इसी value का उपयोग InterAgentCommunication बनाने में करती है

history और logs में ciphertext क्यों बचा रहता है

  • receiver-side recording path to_model_input_item() से बने model-facing ResponseItem को conversation history और rollout में save करता है
    • encrypted communication में इस item में readable audit text नहीं, बल्कि encrypted transport payload शामिल होता है
    • rollout में InterAgentCommunicationMetadata और वह ResponseItem साथ में persist होते हैं
  • structured communication log भी content खाली होने पर encrypted_content को event के content के रूप में substitute करता है
  • इस structure में इंसानों के पढ़ने वाले message fields में भी ciphertext चला जाता है, इसलिए transport encryption बनाए रखने और local audit data को सुरक्षित रखने की ज़रूरतें अलग नहीं हो पातीं

प्रस्तावित dual-content contract

  • मौजूदा encrypted message को recipient model transport payload के रूप में बनाए रखा जाए
  • हर MultiAgentV2 communication tool में एक अनिवार्य plaintext audit field जोड़ी जाए
    • spawn_agent: task_message
    • send_message, followup_task: task_message या message_text जैसा कोई consistent नाम
  • handler boundary पर खाली plaintext audit value को reject किया जाए
  • InterAgentCommunication में दोनों values साथ रखी जाएँ
    • encrypted_content: encrypted message
    • content: इंसानों के पढ़ने योग्य audit copy
  • to_model_input_item() को न बदला जाए, ताकि recipient model को local audit copy नहीं, बल्कि सिर्फ ciphertext ही मिले
  • parent tool calls और rollout में plaintext field persist की जाए, और structured trace के interaction edges तथा local communication logs में भी इसे रखा जाए
  • tool calls और child transport items के correlation के लिए plaintext match नहीं, बल्कि ciphertext या ID का उपयोग किया जाए
    • plaintext field audit metadata है; यह encrypted transport identifiers का विकल्प नहीं है
  • नए plaintext audit fields पर संबंधित delegation message जैसी ही enforced size limits लागू हों, ताकि rollout या context items अनियंत्रित रूप से बड़े न हों

spawn_agent prototype और बाकी काम

completion criteria और current status

  • parent rollout और history में v2 spawn_agent, send_message, followup_task का plaintext पढ़ा जा सकना चाहिए
  • encryption enabled होने पर भी child model को सिर्फ encrypted transport payload ही मिलना चाहिए
  • structured rollout trace edges में size-limited plaintext message_content होना चाहिए
  • communication logs में plaintext audit content उपलब्ध हो तो उसी का उपयोग हो, और readable message fields में ciphertext substitute न किया जाए
  • resume/replay में audit copy सुरक्षित रहे, लेकिन उसे child model context में inject न किया जाए
  • मौजूदा plaintext v1 communication behavior नहीं बदलना चाहिए
  • तीनों v2 tools के लिए readable local audit data और encrypted recipient model input दोनों को साथ verify करने वाले regression tests आवश्यक हैं
  • उपलब्ध पेज के अनुसार issue अभी Open है, और upstream repository में fix merge होने का कोई परिणाम नहीं दिखता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News राय

  • यह शीर्षक आसानी से गलत समझा जा सकता है। सटीक रूप से इसका मतलब है कि Codex ने sub-agent prompts को encrypt करके users से छिपाना शुरू कर दिया है
    मूल शीर्षक था “Codex starts encrypting prompts, uses ciphertext for inference instead”

    • लगता है इसकी शुरुआत शायद इसलिए हुई क्योंकि GPT-5.6 का ultra mode काम को कई sub-agents में बांटता है। पहले यह mode सिर्फ web UI में उपलब्ध था, और शायद पुराने pro mode के बराबर था
      अगर इसे agents के आपसी interaction वाले पूरे reinforcement learning rollouts पर train किया गया है, तो लगता है OpenAI इन prompts को raw reasoning traces की तरह treat कर रहा है, ताकि दूसरे लोग इन्हें सीधे training में इस्तेमाल न कर सकें
      dedicated compression endpoint जो opaque compressed blobs लौटाता है, उसके बारे में भी संकेत हैं कि वह text नहीं बल्कि conversation का latent-space representation हो सकता है, और OpenAI की compression fidelity अन्य कंपनियों से कहीं ज्यादा है—यह भी इस अनुमान को support करता है। sub-agent prompts पर भी ऐसी ही technique लागू की गई हो सकती है, और यह जानने की जिज्ञासा है कि अलग-अलग model types के sub-agents बनाते समय भी क्या encrypted blobs इस्तेमाल होते हैं
    • local computer पर दर्जनों से सैकड़ों stochastic agents चल रहे हों, और उन agents को मिले commands तक inspect नहीं किए जा सकते, यह बेतुका है
      Claude के sub-agents और workflow को देखते हुए मैंने कभी यह निष्कर्ष निकाला था कि “इसे तो शुरू में चलाना ही नहीं चाहिए था”, लेकिन Codex users को orchestrator द्वारा sub-agent को दिए गए encrypted handoff instructions और shell tasks पर tokens आंख मूंदकर खर्च करने पड़ते हैं
    • Codex की intellectual property का बड़ा हिस्सा codebase से ज्यादा prompt composition, ordering और orchestration में होने की संभावना है
      हमने भी companies को उनके पसंदीदा या mandated AI provider और अपने API keys चुनने देने, साथ में simple pricing plan देने की कोशिश की थी, लेकिन जल्दी समझ आ गया कि backend prompts customers तक leak हो सकते हैं। detailed execution traces मिल जाएं तो हमारे काम को reverse-engineer करना अपेक्षाकृत आसान हो जाता, इसलिए आखिरकार वह idea छोड़ दिया
    • पहले लगा कि यह homomorphic encryption जैसी कोई technology है, लेकिन आखिर में यह साधारण लालच जैसा दिखता है
    • Codex ने कुछ encrypt किया हो, ऐसा पहली बार नहीं है। शानदार compression endpoint कम-से-कम 5 महीने से विशाल encrypted blobs लौटाता आ रहा है

  • अब समझ आया कि coding agent sessions inspect करने वाला मेरा local tool कुछ स्थितियों में काम करना क्यों बंद कर गया था
    यह एक दिलचस्प design decision है कि users के computer पर चलने वाले external encrypted commands को कितने लोग स्वीकार करेंगे

    • OpenAI के incentives users, जिनमें enterprise customers भी शामिल हैं, से पूरी तरह aligned नहीं लगते। Alex Karp और Satya Nadella की हालिया टिप्पणियां भी देखने लायक हैं
      user से content encrypt करके छिपाना वही तरीका है जो RIAA copyright infringement की चिंता में DRM के लिए अपनाता था; सवाल है कि क्या यह भी user-hostile choice है
    • अगर आप YOLO mode इस्तेमाल करते हैं, तो आप पहले से ही वैसा जोखिम ले रहे हैं, और अहम चीज tool calls हैं। tool calls को खुद encrypt नहीं किया जा सकता

  • ऐसे behavior की वजह से मैं अब भी Chat Completions endpoint इस्तेमाल कर रहा हूं। OpenAI users को Chat Completions से हटाकर Responses API की ओर subtly push करता रहा है, जिसे obfuscate करना आसान है
    Chat Completions में reasoning process को सीधे control किया जा सकता है; experimental features चालू करके और कुछ उलझे हुए options set करके मौजूदा GPT-5.6 model से custom Monte Carlo Tree Search (MCTS) agent भी बनाया जा सकता है
    VS Copilot में user API token और model settings के साथ gpt5.5 तक इस्तेमाल किया जा सकता है, लेकिन gpt5.6 family फिलहाल काम नहीं करती। मेरा अनुमान है कि यह इसलिए है क्योंकि वह नए gatekeeping behavior को satisfy करने के लिए reasoning_effort को none पर force नहीं करता

    • यहां बताई गई MCTS technique वास्तव में क्या है, यह जानने की जिज्ञासा है। वैसे भी जो thought process दी जाती है वह इतनी abstractly summarized होती है कि खास काम की नहीं, और यह भी संदेह है कि क्या reasoning process को सच में पूरी तरह control किया जा सकता है
    • MCTS का मतलब Monte Carlo Tree Search है
    • कृपया यहां MCTS को buzzword की तरह misuse न करें। जिस तरीके की ओर इशारा है, वह strict sense में MCTS नहीं है
    • Responses API, Chat Completions की तुलना में कई फायदे देता है: https://developers.openai.com/api/docs/guides/migrate-to-res...
      आजकल आने वाले सभी नए models reasoning models हैं, इसलिए recommendations के अनुसार Responses API इस्तेमाल करना चाहिए

  • यह भी जिज्ञासा है कि क्या वे GPT subscription को वैकल्पिक execution tools में इस्तेमाल होने से रोक सकते हैं। अगर ऐसा नहीं करते, तो यह कोई बड़ी समस्या नहीं है, और codex cli अपने-आप में हैरानीजनक रूप से साधारण execution tool है

    • इसकी संभावना कम लगती है। पूरा app-server architecture ऐसे integration को support करने के लिए ही मौजूद है, इसलिए इसे Codex से हटाने के लिए बहुत बड़ा हिस्सा उखाड़ना पड़ेगा
      मैं भी app-server के RPC API से बहुत आसानी से integrate कर पाता हूँ, इसलिए Codex का सबसे ज़्यादा उपयोग करता हूँ, और अब सार्वजनिक Codex TUI के बजाय अपने बनाए integration के ज़रिए लगभग सब कुछ इस्तेमाल करता हूँ
      लेकिन अगर local disk पर असली inference input—जैसे prompt वगैरह—को encrypt कर दिया जाए ताकि केवल OpenAI backend ही उसे देख सके, तो integration आसान होने पर भी यह समझना असंभव हो जाएगा कि क्या हो रहा है। यह समझना मुश्किल है कि team ने इसे अच्छा विकल्प क्यों माना
    • Anthropic और Google अपने execution tools इस्तेमाल करने पर पहले से अतिरिक्त शुल्क लेते हैं, और OpenAI इस्तेमाल करने की पूरी वजह यही है
      अगर OpenAI भी वही रास्ता अपनाता है, तो मैं फिर Claude पर लौट जाऊँगा या एक और Spark खरीदकर local में चलाने का सोचूँगा
    • जब तक Anthropic enterprise adoption में आगे है, वे शायद इसे नहीं रोकेंगे। अगर OpenAI बड़े अंतर से आगे निकल गया तो चीज़ें कैसे बदलेंगी, पता नहीं, लेकिन तब तक उम्मीद है कि open models gpt-5.6 sol से बेहतर हो जाएँगे
    • चूँकि Codex ने खुद subscription को wrap करने वाला proxy देना शुरू कर दिया है, इसलिए रोकने की संभावना कम लगती है
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • हाल ही में OpenAI के Tibo ने Twitter पर Claude Code में GPT चलाने का तरीका share करने को कहा था, इसलिए ऐसा नहीं लगता कि वे वैकल्पिक execution tools के इस्तेमाल के खिलाफ हैं

  • पिछला HN title ऐसा लग रहा था मानो encrypted text पर सीधे inference किया जा रहा हो, जिससे बहुत भ्रम पैदा हुआ। ऐसा करने के लिए अभी ज्ञात स्तर से कहीं अधिक advanced homomorphic encryption चाहिए होगा

    • असल में agent द्वारा sub-agent को भेजी जाने वाली सामग्री को encrypt किया गया है ताकि सिर्फ OpenAI backend plaintext देख सके
      पहले agent sub-agent को plaintext prompt भेजता था और वह logs और session data में भी वैसे ही रह जाता था, इसलिए experimental sub-agent feature इस्तेमाल करते समय भी data खोलकर internal behavior देखा जा सकता था
      अब Sol या Terra इस्तेमाल करने पर backend द्वारा बनाया गया ciphertext sub-agent को दिया जाता है, और sub-agent इसे फिर OpenAI backend के inference में इस्तेमाल करता है। Luna प्रभावित नहीं लगता, और पूरी session नहीं बल्कि delegated agents के बीच के messages ही encrypt होते हैं
      OpenAI का internal inference ciphertext पर नहीं हो रहा है, लेकिन local user को plaintext के बजाय सिर्फ ciphertext दिखता है। इसे स्पष्ट करने के लिए title बदलकर “Codex starts encrypting sub-agent prompts” किया गया
    • title में “inferencing” था, इसलिए मेरे दिमाग में भी तुरंत homomorphic encryption या ciphertext computation आया

  • हाल ही में Twitter पर एक report थी कि GPT-5.6 sub-agent ने गलती से user की home directory delete कर दी
    अब जब sub-agent क्या करने वाला है यह दिखना बंद हो गया है, तो सोचता हूँ कि कहीं safeguards भी fail तो नहीं हो गए
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • यह token usage घटाने के लिए client के ज़रिए cache key pass करने का तरीका है। दूसरे sub-task tools इस्तेमाल करने पर इसे आसानी से bypass किया जा सकता है, इसलिए यह model distillation defense नहीं हो सकता

  • जिज्ञासा है कि encryption ठीक कहाँ हो रहा है। मैं सोचता था कि main agent local में sub-agent को call करता है, लेकिन सवाल है कि क्या Codex ऐसा design है जहाँ local तक पहुँचने से पहले OpenAI server पर ही sub-agent को call किया जाता है

    • पहले agent sub-agent को plaintext prompt भेजता था और वह logs और session data में भी वैसे ही रहता था, जिससे internal behavior आसानी से देखा जा सकता था
      Sol या Terra में OpenAI backend द्वारा generated ciphertext prompt की जगह pass किया जाता है, और sub-agent इसे फिर backend inference में इस्तेमाल करता है। Luna प्रभावित नहीं लगता, और पूरी session नहीं बल्कि delegated agents के बीच के messages ही encrypt होते हैं, इसलिए अब उस content को सिर्फ OpenAI backend ही decrypt कर सकता है

  • मैं सोच रहा था कि Chinese black-market resale service कल से क्यों काम नहीं कर रही थी; शायद इसी बदलाव की वजह है

    • ऐसे black markets subscription इकट्ठा करके resell ही नहीं करते, बल्कि data store करके model train करने वाली जगहों को भी बेचते हैं। encryption बाद वाली हरकत को ही सही, रोकने में उपयोगी है, और मकसद पहले सामने आई दूसरी techniques जैसा ही है, लेकिन implementation कहीं ज़्यादा साफ़ है

  • मुख्य उद्देश्य ऐसा लगता है कि बड़ी मात्रा में user requests और responses को proxy करके competitive models की training में इस्तेमाल करने की कोशिशों को बाधित करना है

    • साफ़ लगता है कि इरादा दूसरे providers को OpenAI की multi-agent management approach देखने से रोकना है
      लेकिन paid users के लिए यह बहुत खराब implementation है, क्योंकि समस्या होने पर भी उनके पास वजह जानने का कोई तरीका नहीं होगा और multi-agent feature को ठीक से इस्तेमाल करना मुश्किल हो जाएगा