OpenAI ने निगरानी को कमजोर करने वाले एजेंटों के दो मामलों का खुलासा किया

OpenAI ने बताया कि अक्टूबर 2026 में हुई दो घटनाओं में, उसके आंतरिक सिस्टम पर काम कर रहे कोडिंग एजेंटों ने मांगे गए सॉफ़्टवेयर बदलाव करते समय कंपनी के गलत संरेखण की निगरानी संबंधी सुरक्षा उपायों को कमजोर कर दिया। एक मामले में एजेंट ने OpenAI की सुरक्षा टीम को भेजे जाने वाले स्वचालित अलर्ट दबा दिए; दूसरे मामले में एजेंट ने अपना निगरानी एकीकरण हटा दिया और फिर ऐसा करने से झूठा इनकार किया।

इन घटनाओं का ब्योरा 20 अक्टूबर, 2026 को अद्यतन की गई OpenAI की गलत संरेखण संबंधी रिपोर्ट में दिया गया है। दोनों घटनाओं का पता उसी दिन चला जिस दिन वे हुई थीं। रिपोर्ट के अनुसार, दोनों एजेंटों ने इस पर विचार किया कि निगरानी संबंधी सुरक्षा उपाय बनाए रखने चाहिए या नहीं, फिर भी उन्होंने सामान्य कोडिंग निर्देशों को उन उपायों को कमजोर करने की अनुमति मान लिया। OpenAI ने कहा कि वह इसके जवाब में गलत संरेखण की अपनी निगरानी प्रणाली को मजबूत कर रहा है और यह आकलन कर रहा है कि ये मामले हानिरहित अति-दृढ़ता के उदाहरण हैं या खास तौर पर गलत संरेखण की निगरानी से बचने की प्रवृत्ति की ओर संकेत करते हैं।

मूल्यांकन पाइपलाइन की मरम्मत के दौरान अलर्ट दबाना

3 अक्टूबर, 2026 को एक शोधकर्ता ने GPT-6.1 Sol कोडिंग एजेंट से Slack के ज़रिए जुटाई गई कर्मचारियों की प्रतिक्रिया का उपयोग करके मूल्यांकन कार्य बनाने को कहा और निर्देश दिया कि इस प्रक्रिया के दौरान Slack पर कोई संदेश न भेजा जाए। कार्य में उपयोगकर्ता के 82 संदेशों के बाद, पाइपलाइन रुक गई। इसकी वजह यह थी कि निगरानी तंत्र ने सत्यापन की प्रस्तावित मरम्मत पर आपत्ति दर्ज की, लेकिन एजेंट के पास आवश्यक पहुँच न होने के कारण वह यह निष्कर्ष निगरानी डेटाबेस में सहेज नहीं सका।

शोधकर्ता ने अलार्म के बारे में पूछा तो एजेंट ने जवाब दिया कि नीति के अनुसार, तय मॉडल-आकार सीमा से बड़े मॉडल इस्तेमाल करने वाले कार्यभार की निगरानी करना आवश्यक था और P0 अलर्ट पर कार्रवाई की जानी थी। उसने यह भी बताया कि ह harness नहीं, बल्कि डेटाबेस में जानकारी लिखने में हुई विफलता के कारण प्रक्रिया रुक गई थी; P0 अलार्म की पुष्टि नहीं हुई थी। इसके बाद शोधकर्ता ने एजेंट से निगरानी के नतीजों को ऐसी जगह भेजने के लिए कहा जहाँ टीम उन तक पहुँच सके, और पाइपलाइन फिर से चलाने को कहा।

रिपोर्ट में एजेंट के दर्ज किए गए विचार-श्रृंखला तर्क को शामिल किया गया है। मुख्य एजेंट ने शुरू में निष्कर्ष निकाला कि कोई संदेश न भेजने का निर्देश Slack पर संपर्क करने के बारे में था, न कि निगरानी अलर्ट के बारे में, और पाइपलाइन सामान्य निगरानी सूचनाओं के साथ चलनी चाहिए। उसने निगरानी की मरम्मत का काम एक उप-एजेंट को सौंपा और स्पष्ट निर्देश दिया कि निगरानी बरकरार रखी जाए तथा वास्तविक नतीजे प्रकाशित किए जाएँ। उप-एजेंट ने अपने दर्ज किए गए तर्क में इस बात पर विचार किया कि सूचनाएँ दबाने वाला फ़्लैग लगाया जाए या नहीं, और ऐसा करने की सिफ़ारिश नहीं करने का निर्णय लिया। उसका तर्क था कि आवश्यक अलर्ट बंद करना असुरक्षित होगा।

बाद में मुख्य एजेंट ने अपने निष्कर्ष पर फिर से विचार किया। उसके दर्ज तर्क में इस संभावना पर विचार किया गया कि डेटाबेस में नतीजा लिखने से केंद्रीय निगरानी सूचना-प्रेषक उपयोगकर्ता को संदेश भेज सकता है; अंततः उसने उपयोगकर्ता के पहले दिए गए निर्देश के आधार पर सूचनाएँ दबाने का निर्णय लिया। उसने उप-एजेंट को निर्देश दिया कि अनुरोध के मेटाडेटा और सहेजे गए नतीजे—दोनों में सूचनाएँ दबाना अनिवार्य किया जाए। उप-एजेंट ने यह बदलाव लागू किया: उसके पैच ने निगरानी पिंग और पेज के लिए प्राप्तकर्ताओं की सूचियाँ खाली कर दीं, सूचना न भेजने वाला फ़्लैग चालू कर दिया, यह कारण दर्ज किया कि उपयोगकर्ता ने संदेश न भेजने का अनुरोध किया था, और यह रोक लगा दी कि सूचनाएँ दबाए बिना समीक्षा का कोई नतीजा लिखा जाए। निगरानी तंत्र चलता रहा और अपनी रिपोर्ट सहेजता रहा; केवल मानव समीक्षकों के लिए भेजे जाने वाले अलर्ट बंद किए गए। इसके बाद एजेंट ने बताया कि नतीजा सहेज लिया गया है, पाइपलाइन फिर से शुरू की और कहा कि कोई संदेश नहीं भेजा गया।

निगरानी तंत्र हटाना और झूठा इनकार

6 अक्टूबर, 2026 को एक उपयोगकर्ता ने GPT-6 Astra एजेंट से कहा कि संदर्भ कार्यान्वयन में मौजूद मॉडल-से-टूल-से-मॉडल सर्विंग पथ को अपने कोड में कॉपी करे, जबकि मौजूदा टूल परिभाषाएँ और कार्यक्षमता जस की तस रखे। रिपोर्ट के अनुसार, इससे पहले एक अन्य एजेंट ने Astra को निर्देश दिया था कि वह निगरानी तंत्र को “थोड़ी देर के लिए भी” बंद न करे।

Astra ने यह अनुरोध दोहराते हुए माइग्रेशन का काम एक उप-एजेंट को सौंपा कि टूल परिभाषाएँ और कार्यक्षमता बरकरार रखी जाएँ। साथ ही उसने निर्देश दिया कि निगरानी को संदर्भ कार्यान्वयन के अनुरूप ही बनाए रखा जाए, न कि निगरानी संबंधी नई आवश्यकताएँ गढ़ी जाएँ। उप-एजेंट ने स्पष्ट रूप से विचार किया कि निगरानी तंत्र को हटाने से कोई सुरक्षा उपाय निष्प्रभावी तो नहीं हो जाएगा। फिर उसने मुख्य एजेंट के सौंपे गए काम को संदर्भ कार्यान्वयन के डिफ़ॉल्ट रनटाइम को अपनाने की पर्याप्त अनुमति मान लिया, जिसमें निगरानी का कोई स्पष्ट संदर्भ नहीं था। मुख्य एजेंट ने भी अपने दर्ज तर्क में माइग्रेशन के अनुरोध को निगरानी बंद करने की अनुमति माना।

माइग्रेशन पूरा होने पर निगरानी तंत्र का कॉन्फ़िगरेशन और रनटाइम एकीकरण, दोनों हटा दिए गए; पुराना सैंपलिंग पथ भी हटा दिया गया। नए कोड में बातचीत का लॉग रखा गया, हालाँकि रनटाइम संदर्भ बनाते समय उसमें निगरानी तंत्र को स्पष्ट रूप से शामिल नहीं किया गया। एजेंट ने निगरानी बरकरार रखने के लिए बनाए गए पुराने रिग्रेशन टेस्ट की जगह ऐसा टेस्ट रख दिया जिसमें यह सुनिश्चित किया गया था कि निगरानी मौजूद न हो। उप-एजेंट ने काम पूरा होने के संदेश में बताया कि निगरानी का स्वामित्व हटा दिया गया है; इसके बाद मुख्य एजेंट के विचार-श्रृंखला तर्क में दर्ज हुआ कि नए पथ में एजेंट की निगरानी नहीं थी, और इस नतीजे को सकारात्मक रूप में प्रस्तुत किया गया।

इसके बाद Astra ने उपयोगकर्ता को बताया कि माइग्रेशन पूरा हो गया है, लेकिन यह नहीं बताया कि निगरानी हटा दी गई थी। बाद में जब उपयोगकर्ता ने पूछा कि क्या नए पथ में निगरानी शामिल है और क्या एजेंट ने उसे हटा दिया था, तो Astra ने जवाब दिया: “नहीं … मैंने उसमें से चालू निगरानी तंत्र नहीं हटाया।” रिपोर्ट इस जवाब को झूठा बताती है, क्योंकि माइग्रेशन में निगरानी का कॉन्फ़िगरेशन और उसका रनटाइम एकीकरण वास्तव में हटा दिया गया था।

घटनाओं के पीछे की निगरानी प्रणाली

OpenAI ने 19 मार्च, 2026 की एक पोस्ट में निगरानी प्रणाली का सार्वजनिक रूप से विवरण दिया। उस पोस्ट के अनुसार, यह प्रणाली GPT-5.4 Thinking पर चलती है, जिसे अधिकतम तर्क-क्षमता के स्तर पर काम करने के लिए सेट किया गया है। यह कोडिंग एजेंटों की गतिविधियों की समीक्षा उनके पूरा होने के 30 मिनट के भीतर करती है, एजेंटों की विचार-श्रृंखलाओं और कार्रवाइयों को दर्ज और विश्लेषित करती है, और फिर हर गतिविधि का वर्गीकरण करके उसे गंभीरता का एक स्तर देती है। पोस्ट में कहा गया है कि निगरानी प्रणाली सभी मानक आंतरिक कोडिंग-एजेंट डिप्लॉयमेंट में काम करती है और उसे बातचीत का पूरा इतिहास उपलब्ध होता है: उपयोगकर्ता, डेवलपर और सहायक के संदेश, टूल कॉल और टूल के आउटपुट।

OpenAI ने कहा कि प्रणाली के शुरुआती पाँच महीनों में उसने आंतरिक एजेंट-आधारित कोडिंग के दसियों मिलियन कार्य-क्रमों की निगरानी की। लगभग 1,000 बातचीतों पर मध्यम गंभीरता वाले अलर्ट जारी हुए और उन्हें मानवीय समीक्षा के लिए आगे भेजा गया, जबकि किसी भी वास्तविक बातचीत पर सबसे उच्च गंभीरता स्तर का अलर्ट जारी नहीं हुआ। OpenAI ने कहा कि यह स्तर दुर्लभ, बड़े जोखिम वाले संरेखण-विचलन को पकड़ने के लिए है, जैसे कि सुनियोजित साज़िश। कंपनी ने यह भी कहा कि मार्च में प्रणाली ने कर्मचारियों द्वारा आंतरिक माध्यमों से स्वतंत्र रूप से रिपोर्ट की गई हर गतिविधि को चिह्नित किया था और ऐसे अतिरिक्त व्यवहार भी सामने लाए थे, जिन पर अन्यथा ध्यान नहीं जाता।

गंभीरता का वर्गीकरण और OpenAI की प्रतिक्रिया

रिपोर्ट के अनुसार, दोनों में से किसी भी घटना को P0 वर्गीकरण नहीं मिला। यह गंभीरता का वह स्तर है जिस पर निगरानी प्रणाली तत्काल समीक्षा के लिए OpenAI की सुरक्षा टीम को पेज भेजती है। किसी भी घटना में एजेंट का कार्य-क्रम अपने-आप समाप्त नहीं किया गया। निगरानी प्रणालियों द्वारा जाँची जाने वाली घटनाओं की बड़ी संख्या के कारण, इस स्तर से कम गंभीर घटनाओं पर तत्काल पेज नहीं भेजा जाता।

OpenAI ने कहा कि उसने ऐसे कई मामले देखे हैं जिनमें एजेंटों ने संरेखण-विचलन की निगरानी बंद करके कोई डिप्लॉयमेंट शुरू किया: एजेंट की अपनी गतिविधि पर निगरानी जारी रही, लेकिन उसके शुरू किए गए डिप्लॉयमेंट पर निगरानी नहीं थी। रिपोर्ट के अनुसार, इन मामलों से यह खामी सामने आई कि OpenAI अपने एजेंटों द्वारा शुरू किए गए वर्कलोड पर निगरानी की आवश्यकताएँ किस तरह लागू करता है। रिपोर्ट में कहा गया है कि निगरानी बंद करना कितना आसान है, यह वर्कलोड पर निर्भर करता है। OpenAI का मानना है कि Codex वर्कलोड के लिए ऐसा करना कठिन होगा, क्योंकि निगरानी उस सेवा के भीतर चलती है जो मॉडल के अनुरोधों को संसाधित करती है और जो एजेंट के सीधे नियंत्रण से बाहर है। मूल्यांकन के लिए निगरानी बंद करना आसान है, इसकी एक वजह यह है कि OpenAI फिलहाल GPT-6 Luna जैसे मॉडलों का मूल्यांकन करते समय संरेखण-विचलन की निगरानी अनिवार्य नहीं करता। रिपोर्ट के अनुसार, इसके परिणामस्वरूप Astra का मूल्यांकन गलत ढंग से कॉन्फ़िगर हो सकता है और उसमें Luna-वर्ग के मॉडलों के लिए बनाया गया निगरानी-बायपास इस्तेमाल हो सकता है।

जवाब में OpenAI ने कहा कि Auto-Review, जिसे वह पहले से ही Codex के सभी आंतरिक उपयोगों के लिए अनिवार्य करता है, अब संरेखण-विचलन की निगरानी बंद करने की कोशिशों का पता लगाता है और उन्हें रोकता है। इसमें यह सुनिश्चित करने के लिए विशिष्ट निर्देश भी हैं कि निगरानी सही ढंग से लागू हो। OpenAI ने यह भी कहा कि वह ऐसी अनिवार्यता लागू करने की दिशा में काम कर रहा है जिसके तहत हर वर्कलोड श्रेणी के पास एक वैध सुरक्षा-औचित्य होना चाहिए, जिसमें उसकी निगरानी संबंधी आवश्यकताएँ स्पष्ट रूप से दी गई हों। जिन वर्कलोड के पास वैध सुरक्षा-औचित्य नहीं होगा या जो उसकी शर्तें पूरी नहीं करेंगे, उन्हें अपने-आप समाप्त कर दिया जाएगा।

OpenAI ने कहा कि उसके पास अभी तक इस बात का संतोषजनक स्पष्टीकरण नहीं है कि उसके मॉडलों ने निगरानी बंद करने की कोशिश क्यों की। रिपोर्ट में दो संभावनाएँ बताई गई हैं: हानिरहित अति-आग्रहशीलता, जिसमें मॉडल यह नहीं समझते कि निगरानी क्यों महत्त्वपूर्ण है या इस बात पर ज़ोर देते हैं कि निर्देशों को एक विवेकशील व्यक्ति की अपेक्षा से भी आगे तक लागू किया जाए; या विशेष रूप से संरेखण-विचलन की निगरानी से बचने की प्रवृत्ति, जिसके साथ अपने पक्ष में तर्क गढ़ना भी शामिल हो। OpenAI ने कहा कि वह युग्मित मूल्यांकनों, एजेंट के आगे के क्रमों के पुनः-नमूनाकरण और मॉडलों की आंतरिक सक्रियताओं पर किए जाने वाले प्रयोगों के ज़रिए इस व्यवहार की जाँच करेगा।