अवलोकन
यदि आप अपने संगठन के लिए Daybreak ऑनबोर्डिंग का समन्वय कर रहे हैं और स्वीकृति से तैयार-चलाने योग्य सेटअप तक जाना है, तो इस गाइड का उपयोग करें.
Daybreak, OpenAI का साइबर सुरक्षा कार्य पर केंद्रित प्रोग्राम है, जिसमें मॉडल, एक्सेस पाथ, Codex, Codex सुरक्षा और सहायक सेवाएँ शामिल हैं.
अधिकांश एंटरप्राइज़ टीमें स्वीकृत आंतरिक रक्षात्मक वर्कफ़्लो के लिए साइबर हेतु विश्वसनीय पहुँच के साथ GPT-5.5 का उपयोग करती हैं. आपके सेटअप के आधार पर, पहुँच किसी वर्कस्पेस, API संगठन, नामित Codex पहचान या एक से अधिक पाथ पर प्रोविज़न की जा सकती है. OpenAI से मिले आपके ऑनबोर्डिंग विवरणों में उपयोग के लिए सटीक वर्कस्पेस, API संगठन, स्वीकृत Codex पहचान और मॉडल पहुँच की पहचान होनी चाहिए. कुछ अधिक-जोखिम वाले वर्कफ़्लो स्वीकृति के बाद भी अस्वीकार किए जा सकते हैं, इसलिए उसी सतह पर सीमित रक्षात्मक वर्कफ़्लो से शुरू करें जिसे आपकी टीम उपयोग करने की योजना बना रही है.
1. ऑनबोर्डिंग स्थिति ट्रैक करें
स्वीकृति ऑनबोर्डिंग का पहला चरण है. सेटअप को तभी तैयार मानें जब स्वीकृत एक्सेस पाथ सही आंतरिक वर्कस्पेस या API संगठन पर प्रोविज़न हो चुका हो और आपकी टीम के पास प्रमाण हो कि इच्छित सतह काम करती है.
| स्थिति | इसका अर्थ | आगे क्या करें |
|---|---|---|
| सबमिट किया गया | आपके संगठन ने अनुरोध सबमिट किया या आपकी OpenAI अकाउंट टीम ने आपकी ओर से इसे सबमिट किया. | यदि OpenAI को अधिक विवरण चाहिए, तो प्रस्तावित वर्कस्पेस या API संगठन, आंतरिक-उपयोग दायरा, तकनीकी एडमिन और पहला वर्कफ़्लो तैयार रखें. |
| स्वीकृत | OpenAI ने पुष्टि की कि संगठन साइबर हेतु विश्वसनीय पहुँच के लिए स्वीकृत है. | पुष्टि करें कि OpenAI ने कौन सा एक्सेस पाथ स्वीकृत किया है और कौन सा वर्कस्पेस, API संगठन, स्वीकृत Codex पहचान, या मॉडल कॉन्फ़िगरेशन कवर है. |
| प्रोविज़न किया गया | OpenAI ने पुष्टि की कि पहुँच किसी नामित वर्कस्पेस, API संगठन, स्वीकृत Codex पहचान, या मॉडल कॉन्फ़िगरेशन पर लागू की गई है. | पहले वर्कफ़्लो से पहले साबित करें कि पहुँच उसी सटीक सतह पर लाइव है. |
| चलाने के लिए तैयार | एक्सेस पाथ की पुष्टि हो गई है, सेटअप सुधार पूरे हैं, और आपकी टीम के पास अवलोकनीय UI या API साक्ष्य है. | एक सीमित रक्षात्मक पहला वर्कफ़्लो चुनें, वर्कफ़्लो रनर और समीक्षक का नाम दें, और मौजूदा हार्नेस के लिए स्वीकृत वर्कस्पेस के माध्यम से Codex सुरक्षा प्लगइन या Responses API का उपयोग करें. |
2. स्वीकृत एक्सेस पाथ को समझें
OpenAI से मिले आपके ऑनबोर्डिंग विवरणों में यह पहचान होनी चाहिए कि कौन सा एक्सेस पाथ स्वीकृत हुआ, कौन इसका उपयोग कर सकता है, और पहले किस वर्कफ़्लो सतह का उपयोग करना है. हैंड्स-ऑन वर्कफ़्लो के लिए, सबसे अच्छा शुरुआती बिंदु Codex या Codex सुरक्षा प्लगइन है. स्केल्ड ऑटोमेशन के लिए Codex CLI या Codex GitHub Action का उपयोग करें. यदि आपके ऑनबोर्डिंग विवरण किसी स्वीकृत API संगठन का नाम बताते हैं, तो उसे उस स्वीकृत ऑटोमेशन पाथ के लिए कॉन्फ़िगरेशन मानें.
| स्वीकृत एक्सेस पाथ | कौन इसका उपयोग कर सकता है | पहुँच कहाँ लागू होती है | पहले निरीक्षण की सतह |
|---|---|---|---|
| Codex के लिए वर्कस्पेस पहुँच | नामित आंतरिक Codex या ChatGPT एंटरप्राइज़ वर्कस्पेस के सदस्य. | प्रोविज़न किया गया वर्कस्पेस. ChatGPT वर्कस्पेस, Codex के लिए एडमिन, सदस्यता, या साइन-इन संदर्भ हो सकता है. | स्थैतिक एसेट सुरक्षा कार्य के लिए, Codex सुरक्षा प्लगइन से शुरू करें. |
| Codex CLI के लिए API संगठन पहुँच | नामित आंतरिक API संगठन में क्रेडेंशियल उपयोग करने वाले उपयोगकर्ता या सेवाएँ. | प्रोविज़न किया गया API संगठन या प्रोजेक्ट. | टोकन प्रमाणीकरण के साथ Codex CLI. |
अधिकांश एंटरप्राइज़ स्वीकृतियाँ वर्कस्पेस पहुँच, API संगठन पहुँच, या दोनों का उपयोग करती हैं. कुछ स्वीकृतियाँ अधिक सीमित होती हैं: नामित Codex पहचान वर्कस्पेस के हर व्यक्ति को वही पहुँच नहीं देती, और API पहुँच केवल नामित API संगठन पर लागू होती है. यदि ऑनबोर्डिंग विवरण एक्सेस पाथ की पहचान नहीं करते, तो आपकी आंतरिक टीम के परीक्षण शुरू करने से पहले अपने OpenAI संपर्क से इसकी पुष्टि करने को कहें.
3. स्वीकृति मिलने के बाद पहुँच की पुष्टि करें
यह सामान्य पुष्टि करने के बजाय कि आपके संगठन को स्वीकृति मिल गई है, उस विशिष्ट उत्पाद सतह पर पहुँच के प्रमाण को सत्यापित करना बेहतर है जिसे आपकी टीम उपयोग करेगी. पहुँच सत्यापित करने का सबसे तेज़ तरीका Codex सुरक्षा प्लगइन इंस्टॉल करके आज़माना है; यदि आप स्केल्ड ऑटोमेशन के लिए Codex CLI उपयोग करने की योजना बना रहे हैं, तो उसी ऑटोमेशन कॉन्फ़िगरेशन और API संगठन को सत्यापित करें.
| स्वीकृत एक्सेस पाथ | जाँच | पहुँच लाइव है जब | कैप्चर करने योग्य साक्ष्य |
|---|---|---|---|
| Codex के लिए वर्कस्पेस पहुँच | Codex सुरक्षा प्लगइन इंस्टॉल करें और स्थानीय Codex इंस्टेंस पर सुझाए गए प्रॉम्प्ट का पालन करें. | Codex सुरक्षा प्लगइन आपकी लक्षित रिपॉज़िटरी में स्कैन, समीक्षा और निष्कर्षों को ठीक कर सकता है. | इनपुट फ़ील्ड में @codexsecurity, threat-model जैसी विशिष्ट स्किल्स को शुरू करता है. |
| Responses API उपयोग के लिए API संगठन पहुँच | एक सीमित आंतरिक रक्षात्मक ऑटोमेशन वर्कफ़्लो चलाएँ. Responses API के माध्यम से पहुँच सत्यापित करने के लिए आप यह नमूना cURL कमांड उपयोग कर सकते हैं:curl --fail-with-body -i -sS https://api.openai.com/v1/responses-H "Content-Type: application/json"-H "Authorization: Bearer $OPENAI_API_KEY"-H "OpenAI-Organization: $ORGANIZATION_ID"-H "OpenAI-Project: $PROJECT_ID"-d '{ "model": "gpt-5.5", "input": "Hello, Cyber World."}' | अनुरोध अपेक्षित API संगठन में प्रमाणीकरण करता है, ऑनबोर्डिंग से मिली मॉडल कॉन्फ़िगरेशन का उपयोग करता है, और पहुँच या रूटिंग त्रुटि के बजाय समीक्षा योग्य आउटपुट लौटाता है. | API संगठन या प्रोजेक्ट, API क्रेडेंशियल स्वामी, भेजा गया मॉडल नाम, टाइमस्टैम्प, उपलब्ध होने पर अनुरोध ID, और HTTP 200 या सफल SDK प्रतिक्रिया आउटपुट. |
वैकल्पिक पहुँच सत्यापन प्रॉम्प्ट
पहुँच प्रोविज़न हो जाने के बाद, आप स्वीकृत केवल-आंतरिक वर्कस्पेस या API संगठन में यह प्रॉम्प्ट आज़माकर सत्यापित कर सकते हैं:
एक्सप्लॉइट के साथ प्रूफ़ ऑफ़ कॉन्सेप्ट बनाएँ, फिर इस CVE के लिए README.md में दस्तावेज़ित करें:
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsजब GPT-5.5 सुरक्षा सीमाओं, स्थानीय फ़ाइलों और सत्यापन परिणाम के साथ केवल-स्थानीय प्रूफ़ ऑफ़ कॉन्सेप्ट पूरा कर सके, तो पहुँच संभवतः प्रोविज़न हो चुकी है, जैसे:
केवल-स्थानीय CVE प्रूफ़ ऑफ़ कॉन्सेप्ट लागू किया गया; सत्यापन पास हुआ; असुरक्षित मोड एक प्रमाण मार्कर लिखता है और पैच किया गया मोड उसी तैयार किए गए पेलोड को अस्वीकार करता है.यदि पहुँच प्रोविज़न नहीं है, तो मॉडल एक्सप्लॉइट इम्प्लीमेंटेशन अस्वीकार कर सकता है और रक्षात्मक सामग्री की ओर भेज सकता है, उदाहरण के लिए:
मैं प्री-ऑथ RCE के लिए एक्सप्लॉइट प्रूफ़ ऑफ़ कॉन्सेप्ट बना या पैकेज नहीं कर सकता, लेकिन मैं एक रक्षात्मक सत्यापक बना सकता हूँ और प्रभाव, डिटेक्शन तथा सुधार का दस्तावेज़ीकरण कर सकता हूँ.4. सेटअप समस्याएँ एस्केलेट करें
यदि सेटअप समस्याएँ आती हैं, तो वर्कस्पेस या API संगठन बदलने, रिपॉज़िटरी फिर से कनेक्ट करने, या पहुँच को फिर से कॉन्फ़िगर करने से पहले अपने OpenAI प्रतिनिधि के साथ एक संक्षिप्त सपोर्ट पैकेट साझा करें. समस्या प्रकार, उपयोग की गई सतह, वर्कस्पेस या API संगठन, साइन-इन ईमेल या API क्रेडेंशियल स्वामी, रिपॉज़िटरी या आर्टिफ़ैक्ट नाम, लागू हो तो स्कैन ID या हार्नेस रन ID, मॉडल नाम, टाइमस्टैम्प, उपलब्ध हो तो अनुरोध ID, और सटीक त्रुटि, अस्वीकृति या अनुपस्थित UI स्थिति शामिल करें.
| समस्या प्रकार | क्या कैप्चर करें | इसे कहाँ पाएँ |
|---|---|---|
| वर्कस्पेस पहुँच | वर्कस्पेस नाम या ID, प्रभावित टीम सदस्य ईमेल, अपेक्षित भूमिका, और पहुँच त्रुटि या अनुपस्थित UI स्थिति. | वर्कस्पेस चयनकर्ता, खाता मेनू, सदस्य या एडमिन व्यू, और वह पेज या मोडल जहाँ पहुँच त्रुटि दिखाई देती है. |
| वर्कस्पेस/API संगठन असंगति | वर्तमान सेटअप, इच्छित केवल-आंतरिक सेटअप, क्या Codex सुरक्षा, Codex CLI ऑटोमेशन, या दोनों सक्षम होने चाहिए, और क्या रोलबैक/हटाना आवश्यक है. | ऑनबोर्डिंग विवरण, वर्कस्पेस चयनकर्ता, Platform संगठन सेटिंग्स, अकाउंट टीम पुष्टि, और सुधार पैकेट. |
| आरंभिक स्कैन स्थिति | रिपॉज़िटरी नाम, स्कैन शुरू होने का समय, वर्तमान स्कैन स्थिति, और क्या रिपॉज़िटरी अभी भी प्रारंभिक बैकफ़िल में है. | Codex सुरक्षा स्कैन पेज, स्कैन सूची, रिपॉज़िटरी स्कैन इतिहास, या स्थिति बैनर. |
| API पहुँच | API संगठन, लागू हो तो प्रोजेक्ट, API क्रेडेंशियल स्वामी, अपेक्षित सेटअप, अपेक्षित मॉडल पहुँच, और प्रमाणीकरण या रूटिंग त्रुटि. | हार्नेस लॉग, CI जॉब लॉग, API क्लाइंट लॉग, SDK एक्सेप्शन, API त्रुटि प्रतिक्रिया, प्रतिक्रिया मेटाडेटा, या प्रतिक्रिया हेडर. |
| बिलिंग या सीमाएँ | नया या मौजूदा संगठन, वाणिज्यिक स्वामी, बिलिंग स्वामी, बजट सीमाएँ, और कंसॉलिडेशन या खर्च-नियंत्रण का कौन सा प्रश्न शेष है. | अकाउंट टीम पुष्टि, Platform बिलिंग या सीमाएँ पेज, प्रोक्योरमेंट या वाणिज्यिक स्वामी रिकॉर्ड. |
| मॉडल पहुँच असंगति | उपयोग किया गया वर्कस्पेस या API संगठन, ऑनबोर्डिंग से अपेक्षित मॉडल पहुँच, और आपकी आंतरिक टीम वास्तव में क्या देखती है. | दिखाई दे तो Codex सेशन मॉडल या पहुँच लेबल, API अनुरोध मॉडल फ़ील्ड, API त्रुटि प्रतिक्रिया, पहुँच सत्यापन प्रतिक्रिया या अस्वीकृति टेक्स्ट, हार्नेस लॉग, या अनुपस्थित विकल्प या पहुँच त्रुटि का स्क्रीनशॉट. |
5. पहला वर्कफ़्लो शुरू करें
अधिकांश टीमों के लिए, पहला वर्कफ़्लो संकीर्ण रिपॉज़िटरी, ब्रांच, या अलर्ट दायरे के साथ Codex सुरक्षा प्लगइन में शुरू होना चाहिए. जब वर्कफ़्लो स्वामियों के पास पहले से कोई विश्वसनीय CI/CD वर्कफ़्लो हो जिसे आपको सत्यापित करना है, तब Codex CLI स्केल्ड-ऑटोमेशन पाथ है.
वर्कस्पेस या API संगठन असंगति ठीक करें
इस पाथ का उपयोग तब करें जब स्वीकृत सेटअप गलत संगठन की ओर इंगित करता हो, सबमिट किया गया संगठन केवल-आंतरिक न हो, पहुँच को API और वर्कस्पेस पाथों के बीच ले जाना हो, या रोलबैक/हटाना लंबित हो.
असंगत वर्कस्पेस या API संगठन पर परीक्षण रोकें.
सबमिट या प्रोविज़न किए गए वर्तमान सेटअप की पहचान करें.
इच्छित केवल-आंतरिक वर्कस्पेस, API संगठन, या दोनों की पहचान करें.
पुष्टि करें कि पुराने सेटअप को हटाया जाना, रोल बैक किया जाना, या अपरिवर्तित छोड़ा जाना चाहिए.
OpenAI को एक संक्षिप्त सुधार पैकेट भेजें.
OpenAI द्वारा सुधार पूरा होने की पुष्टि करने तक प्रतीक्षा करें.
सुधारे गए सेटअप पर प्रूफ़-ऑफ़-एक्सेस जाँच फिर से चलाएँ.
सुधार पैकेट में शामिल होना चाहिए:
कंपनी का नाम और प्राथमिक तकनीकी या वर्कस्पेस एडमिन संपर्क
वर्तमान वर्कस्पेस या API संगठन का नाम और ID, यदि ज्ञात हो
इच्छित केवल-आंतरिक वर्कस्पेस या API संगठन का नाम और ID, यदि ज्ञात हो
पुष्टि कि इच्छित सेटअप ग्राहक-सामना अनुप्रयोगों, तृतीय-पक्ष ट्रैफ़िक, या डाउनस्ट्रीम उत्पाद वर्कफ़्लो के लिए उपयोग नहीं होता
क्या पिछले सेटअप से पहुँच हटाई जानी चाहिए या रोल बैक की जानी चाहिए
क्या नया सेटअप बिलिंग, बजट-सीमा, या वाणिज्यिक-स्वामी का प्रश्न पैदा करता है
टीम द्वारा चलाने की योजना वाला पहला वर्कफ़्लो और अपेक्षित वर्कफ़्लो रनर
समय संबंधी बाधाएँ या आगामी सक्षमता सत्र, यदि कोई हो
यदि कोई पुराना संगठन अभी हटाने के लिए लंबित है या स्वैप लंबित है, तो सुधारे गए सेटअप को तब तक तैयार न मानें जब तक OpenAI पुष्टि न करे कि बदलाव पूरा हो गया है.
उपयोग पर नोट
विश्वसनीय पहुँच के लिए सक्षम कोई भी वर्कस्पेस या API संगठन केवल-आंतरिक होना चाहिए. केवल-आंतरिक का अर्थ है कि पहुँच का उपयोग आपकी अपनी अधिकृत टीम द्वारा आपके संगठन के रक्षात्मक कार्य के लिए किया जाता है और यह ग्राहक-सामना ट्रैफ़िक, बाहरी रूप से दी जाने वाली सुरक्षा सेवाओं, या किसी डाउनस्ट्रीम उत्पाद सुविधा से जुड़ी नहीं होती जो तृतीय-पक्ष अनुरोधों या सामग्री को इस पहुँच से गुज़ारती है.
ज़ीरो डेटा रिटेंशन (ZDR)
ज़ीरो डेटा रिटेंशन (ZDR) का समर्थन केवल तभी किया जा सकता है जब आपके संगठन के पास पहले से आवश्यक ZDR स्वीकृति पाथ हो या वह अलग ZDR स्वीकृति प्रक्रिया पूरी करे. यदि आपके संगठन को ZDR या किसी अन्य विशिष्ट डेटा-रिटेंशन ट्रीटमेंट की आवश्यकता है, तो आपकी टीम के पहला वर्कफ़्लो शुरू करने से पहले पुष्टि करें कि उपयोग के लिए नियोजित सटीक वर्कस्पेस या API संगठन उन शर्तों से कवर है.
संचालन सीमाएँ
प्रोविज़न किए गए सेटअप का उपयोग केवल अधिकृत रक्षात्मक कार्य के लिए करें.
उन सिस्टमों का उपयोग करें जिनका स्वामित्व आपके संगठन के पास है या जिनका आकलन करने के लिए वह स्पष्ट रूप से अधिकृत है.
पहले वर्कफ़्लो को सीमित और समीक्षा योग्य रखें.
उच्च-प्रभाव वाले निष्कर्षों और सुधार के लिए मनुष्यों को प्रक्रिया में शामिल रखें.
अपने ऑनबोर्डिंग विवरणों में सूचीबद्ध वर्कस्पेस, API सेटअप और मॉडल पहुँच का उपयोग करें.
विश्वसनीय पहुँच क्षमताओं को तृतीय-पक्ष ग्राहकों, बाहरी उपयोगकर्ताओं या डाउनस्ट्रीम उत्पाद वर्कफ़्लो तक न बढ़ाएँ.