रहस्य कार्य वातावरण से बाहर रखें और संवेदनशील फ़ाइलों तक पहुँच रोकें। शुरुआत इन दोनों उपायों को साथ अपनाने से करें।
केवल पढ़ने का मोड, मंज़ूरियाँ और प्रशिक्षण के लिए डेटा का उपयोग बंद करना अलग-अलग काम करते हैं। गोपनीय फ़ाइलों तक पहुँच रोकने में हर उपाय की भूमिका अलग से जाँचें।
पढ़ने, चलाने और भेजने की अलग-अलग जाँच करें
कार्य वातावरण से गैरज़रूरी रहस्य हटाएँ। संवेदनशील फ़ाइलों को पढ़ने से रोकने के लिए deny नियम पर विचार करें।
देखें कि मंज़ूरी के अनुरोध कौन जाँचता है। Full access या सैंडबॉक्स के बाहर चलाने की अनुमति देकर सीमा न बढ़ाएँ।
कमांड का नेटवर्क, मॉडल को भेजा जाने वाला डेटा, और ब्राउज़र या MCP की पहुँच अलग-अलग जाँचें।
OpenAI के Permissions, Sandbox, मंज़ूरी, सुरक्षा और कॉन्फ़िगरेशन दस्तावेज़ों की समीक्षा 8 अक्टूबर 2026 को की गई। यह गाइड स्थानीय सैंडबॉक्स में चलने वाले कमांड पर केंद्रित है। उदाहरण वाली सेटिंग किसी वास्तविक मशीन पर लागू नहीं की गई और उसका प्रवर्तन नहीं जाँचा गया। डिवाइस या खाते की कोई सेटिंग नहीं बदली गई।
विषय-सूची
- 1. केवल पढ़ने का मोड, मंज़ूरियाँ और प्रशिक्षण सेटिंग
- 2. रहस्य कार्य वातावरण से बाहर रखें
- 3. पढ़ने से रोकने की उदाहरण सेटिंग
- 4. .env पैटर्न और जाँचने योग्य कमियाँ
- 5. कमांड का नेटवर्क बंद करने से क्या रुकता है और क्या नहीं
- 6. पर्यावरण चर, ऑपरेटिंग सिस्टम और Cloud
- 7. डमी फ़ाइलों से सत्यापन
- अक्सर पूछे जाने वाले सवाल
1. केवल पढ़ने का मोड, मंज़ूरियाँ और प्रशिक्षण सेटिंग
फ़ाइल में बदलाव रोकना और उसे पढ़ने से रोकना अलग बातें हैं।
ऐसा मोड जो लिखने को सीमित करता है। यह पढ़ी जा सकने वाली फ़ाइलों की सामग्री को रहस्य मानकर छिपाता नहीं है।
यह तय करता है कि कहाँ संपादन की अनुमति है। ज़रूरी नहीं कि पढ़ने की अनुमति भी उन्हीं जगहों तक सीमित हो।
| नियंत्रण | मुख्य रूप से किस पर नियंत्रण है | यह अकेले किस बात की गारंटी नहीं देता |
|---|---|---|
| केवल पढ़ने का मोड | फ़ाइलों में बदलाव हो सकता है या नहीं | पहुँच में मौजूद गोपनीय फ़ाइलें नहीं पढ़ी जाएँगी |
| मंज़ूरी की नीति | सीमा पार करने वाली कार्रवाई की समीक्षा कौन करेगा | अनुमति वाले दायरे में हर बार पढ़ने से पहले मानवीय जाँच |
| फ़ाइल रोकने के नियम | निर्दिष्ट पथों पर पढ़ने और लिखने का इनकार | पहले पेस्ट की गई सामग्री हटाना या दूसरे टूल से पहुँच रोकना |
| कमांड के नेटवर्क पर प्रतिबंध | सैंडबॉक्स में चलने वाले कमांड के नेटवर्क गंतव्य | मॉडल, प्रमाणीकरण, ब्राउज़र, MCP और दूसरी सेवाओं का पूरा संचार रोकना |
| प्रशिक्षण सेटिंग | प्रसंस्कृत डेटा मॉडल सुधारने में इस्तेमाल होगा या नहीं | डेटा संसाधित या भेजा नहीं जाएगा |
on-request का उपयोग करने पर भी अनुमति वाले दायरे के कमांड अतिरिक्त मंज़ूरी के बिना चल सकते हैं। मानवीय समीक्षा के लिए मंज़ूरी की नीति और समीक्षा अनुरोध पाने वाले, दोनों को जाँचें।
AI से स्वचालित समीक्षा कैसे अलग है
approvals_reviewer = "auto_review" संबंधित समीक्षा AI को भेजता है। यह मानवीय समीक्षा नहीं है और पहले से अनुमति वाली हर कार्रवाई के लिए समीक्षा की नई शर्त नहीं जोड़ता।
स्रोत: OpenAI: मंज़ूरी और सैंडबॉक्स की सीमाएँ । प्रशिक्षण के बारे में अलग लेख देखें: ChatGPT और Codex की प्रशिक्षण सेटिंग और गोपनीय जानकारी ।
2. रहस्य कार्य वातावरण से बाहर रखें
UI में बदलाव के लिए केवल स्रोत कोड और काल्पनिक डेटा काफ़ी हो सकते हैं। उत्पादन वाले API की, ग्राहक डेटा और परिवार के दस्तावेज़ उसी वातावरण में रखना ज़रूरी नहीं है।
फ़ाइलों को दूसरे फ़ोल्डर में ले जाना काफ़ी नहीं है। यदि पढ़ने की व्यापक अनुमति बनी है, तो उन फ़ाइलों तक अब भी पहुँचा जा सकता है।
कार्य प्रति में केवल ज़रूरी सामग्री रखें
उत्पादन डेटा की जगह छोटे इनपुट इस्तेमाल करें जो समस्या दोहरा सकें।
सेटिंग के उदाहरण में केवल फ़ील्ड के नाम हों। लॉग, बैकअप और इतिहास भी जाँचें।
देखें कि दूसरे फ़ोल्डर, होम डायरेक्टरी, साझा स्टोरेज या जुड़े ऐप तक पहुँच उपलब्ध है या नहीं।
क्या Git के अनदेखा करने वाले नियम पढ़ना रोक सकते हैं?
.gitignore उन अनट्रैक्ड फ़ाइलों को निर्दिष्ट करता है जिन्हें Git को अनदेखा करना चाहिए। यह OS की पढ़ने की अनुमति नहीं हटाता। कोई खोज टूल आम तौर पर फ़ाइल छोड़ देता है, तो भी उसके सीधे पथ से पढ़ने का अनुरोध रोका जाएगा, इसकी गारंटी नहीं है। अनदेखा करने का नया नियम उन फ़ाइलों को भी प्रभावित नहीं करता जिन्हें Git पहले से ट्रैक करता है। Git दस्तावेज़: gitignore का दायरा ।
निर्देश बनाम लागू किया गया पहुँच प्रतिबंध
AGENTS.md में “रहस्य न पढ़ें” लिखना काम के उपयोगी निर्देश दे सकता है। इससे अपने आप OS की पहुँच पर प्रतिबंध नहीं लगते। निर्देशों के साथ लागू किया गया पहुँच प्रतिबंध भी रखें। इनपुट की पहचान छिपाने के उदाहरणों के लिए AI टूल में जानकारी डालने की सावधानियाँ देखें।
3. पढ़ने से रोकने की उदाहरण सेटिंग
Permission profiles एक बीटा सुविधा है। उपयोग से पहले समर्थित वातावरण और मौजूदा सत्र में चुनी गई सेटिंग जाँचें।
read: पढ़नालक्ष्य पढ़ने की अनुमति
write: संपादनलक्ष्य पर लिखने की अनुमति
deny: रोकनालक्ष्य को पढ़ने और उस पर लिखने, दोनों से इनकार
पुरानी सैंडबॉक्स सेटिंग से टकराव पर ध्यान दें
पुरानी सेटिंग लागू रहने पर Permission profiles का उपयोग नहीं हो सकता।
टकराने वाली सेटिंग और व्यवस्थापक के नियंत्रण जाँचें
पुरानी सेटिंग साथ न मिलाएँ: default_permissions और [permissions] को पुरानी सेटिंग sandbox_mode या [sandbox_workspace_write] के साथ मिलाकर इस्तेमाल करने के लिए नहीं बनाया गया है। सामान्यतः लोड की गई सेटिंग में sandbox_mode मौजूद हो या शुरुआत में --sandbox का इस्तेमाल हो, तो पुराना तरीका लागू होता है। allowed_permission_profiles के ज़रिए व्यवस्थापक का नियंत्रण अलग शर्त है।
नीचे एक उदाहरण के तौर पर सुझाया गया कॉन्फ़िगरेशन है, जो आधिकारिक कार्यक्षेत्र वाले उदाहरण में गोपनीय फ़ाइलों का प्रतिबंध और मानवीय मंज़ूरी जोड़ता है। इसे अपनी पूरी मौजूदा सेटिंग की जगह न रखें। संस्करण का समर्थन, संगठन के प्रतिबंध और ज़रूरी निष्पादन पथ जाँचकर डमी वातावरण में परीक्षण करें।
सेटिंग कहाँ रखें: उपयोगकर्ता और प्रोजेक्ट कॉन्फ़िगरेशन
~/.codex/config.toml
.codex/config.toml
इनका दायरा और लोड होने की शर्तें अलग हैं। प्रोजेक्ट कॉन्फ़िगरेशन केवल विश्वसनीय प्रोजेक्ट के लिए लोड होता है।
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = falseयह उदाहरण कौन-से पथ शामिल करता है?
मौजूदा कार्यक्षेत्र और हर अतिरिक्त कार्यक्षेत्र पर लागू
.envरोकने के लिए निर्दिष्ट.env.productionरोकने के लिए निर्दिष्टsecrets/ और उसकी सामग्रीरोकने के लिए निर्दिष्टsubfolder/.envअलग से जाँचेंबदले नाम वाले रहस्य या लॉग में प्रतियाँअलग से जाँचें:root पढ़ना रोकता है। अपवादों में निष्पादन के लिए :minimal और विरासत में मिले प्रोफ़ाइल द्वारा अनुमत अस्थायी डायरेक्टरी शामिल हैं।
:workspace से संपादन की अनुमति मिलती है और ऊपर दिए विशिष्ट पथ रोके जाते हैं। यह उदाहरण आउटपुट में छिपे रहस्य नहीं पकड़ता।
प्रोफ़ाइल के नाम, कई कार्यक्षेत्र और अस्थायी फ़ाइलें
project-private इस उदाहरण के लिए चुना हुआ नाम है। :workspace_roots मौजूदा और अतिरिक्त कार्यक्षेत्रों पर लागू होता है और हर रूट के सीधे भीतर दिए हुए पथों को लक्ष्य बनाता है। secrets उस नाम की फ़ाइल या उप-वृक्ष को लक्ष्य बनाता है।
यह कॉन्फ़िगरेशन कार्यक्षेत्र के बाहर हर बार पढ़ने को नहीं रोकता। रहस्यों को अस्थायी स्टोरेज में कॉपी करने से भी बचना होगा।
स्रोत: OpenAI: Permission profile कॉन्फ़िगरेशन, प्रतिबंध और दायरा । यह लेख वास्तविक मशीन पर उदाहरण लागू करके अलगाव जाँचने की रिपोर्ट नहीं है।
4. .env पैटर्न और जाँचने योग्य कमियाँ
ज्ञात जगह पर रखे रहस्यों के लिए सटीक नाम उपयोगी हैं। पैटर्न इस्तेमाल करते समय याद रखें कि *.env और .env.* अलग हैं। यह न मानें कि आधिकारिक **/*.env उदाहरण समान शर्तों पर .env.production को भी रोक देगा।
| नियम का उदाहरण | लक्ष्य | अलग से जाँचें |
|---|---|---|
.env | कार्यक्षेत्र के रूट में सीधे इस नाम की फ़ाइल | उपफ़ोल्डर और अतिरिक्त प्रत्यय वाले फ़ाइल नाम |
.env.production | रूट में उत्पादन की कॉन्फ़िगरेशन फ़ाइल | दूसरे नामों से उत्पादन सेटिंग या उसकी प्रतियाँ |
secrets | रूट में इस नाम का पथ और उसकी सामग्री | लॉग या बैकअप जैसी दूसरी जगह की प्रतियाँ |
**/*.env | डायरेक्टरी के स्तरों में .env पर समाप्त होने वाली फ़ाइलें | प्रत्यय वाले नाम, स्कैन की गहराई और शुरुआत के बाद के बदलाव |
डायरेक्टरी की गहराई और शुरुआत के बाद जोड़ी गई फ़ाइलें जाँचें
Linux, WSL और मूल Windows पर, असीमित ** वाले प्रतिबंध पैटर्न को शुरुआत से पहले सीमित विस्तार की आवश्यकता हो सकती है। आधिकारिक दस्तावेज़ glob_scan_max_depth को कम-से-कम 1 पर रखने या *.env, */*.env और */*/*.env जैसे पैटर्न से गहराई स्पष्ट करने को बताते हैं। अधिक गहरी डायरेक्टरी हो, तो उस गहराई तक कवरेज सत्यापित करें।
प्रवर्तन के कुछ तरीके शुरुआत से पहले मिलते हुए पथ इकट्ठे करते हैं। जाँचें कि उसके बाद बनी फ़ाइलें आपके वास्तविक OS, संस्करण और निष्पादन वातावरण में रोकी जाती हैं या नहीं। प्रतिबंध पैटर्न को ऐसा सार्वभौमिक नियम न मानें जो आगे बनने वाले हर रहस्य की रक्षा करेगा।
अनुमतियाँ आपस में मिलने पर कौन-सा नियम लागू होगा?
ज़्यादा विशिष्ट पथ का नियम व्यापक नियम को बदल सकता है। समान पथ पर रोक को प्राथमिकता मिलती है, लेकिन व्यापक प्रतिबंध के भीतर सीमित अनुमति भी बन सकती है। कॉन्फ़िगरेशन की अतिरिक्त परतें और मूल प्रोफ़ाइल से मिली सेटिंग भी जाँचें।
स्रोत: OpenAI: पथ और पैटर्न से पढ़ना रोकना, कॉन्फ़िगरेशन लोड होने का क्रम । प्रोजेक्ट का .codex/config.toml केवल विश्वसनीय प्रोजेक्ट में लोड होता है। फ़ाइल में लिखी सेटिंग और मौजूदा सत्र में लागू सेटिंग में फ़र्क रखें।
5. कमांड का नेटवर्क बंद करने से क्या रुकता है और क्या नहीं
कमांड का नेटवर्क बंद करने से संबंधित सैंडबॉक्स में चलने वाले प्रोग्राम का नेटवर्क उपयोग सीमित होता है। लेकिन Codex क्लाइंट के मॉडल और प्रमाणीकरण अनुरोध कमांड के नेटवर्क नियंत्रण से अलग हैं । कमांड का नेटवर्क बंद होना यह साबित नहीं करता कि Codex का पढ़ा हुआ कोड मॉडल के संदर्भ में नहीं भेजा जाएगा।
कमांड के नेटवर्क प्रतिबंध का दायरा
कमांड, स्क्रिप्ट और उनकी चाइल्ड प्रक्रियाओं की नेटवर्क गतिविधि।
मॉडल और प्रमाणीकरण, वेब खोज, जुड़े ऐप, MCP, ब्राउज़र और Computer Use, तथा क्लाउड टास्क।
नेटवर्क चालू रखकर गंतव्य सीमित करने के लिए डोमेन के नियमों के साथ नेटवर्क प्रॉक्सी भी चालू करना होगा। प्रोफ़ाइल में अनुमत डोमेन लिख देने भर से वे नियम सक्रिय नहीं होते।
| कमांड का नेटवर्क | प्रॉक्सी | नतीजा |
|---|---|---|
| बंद | कोई भी सेटिंग | कमांड का नेटवर्क उपयोग अनुमत नहीं |
| चालू | बंद | सीधा नेटवर्क संभव; प्रोफ़ाइल के डोमेन नियम लागू नहीं |
| चालू | चालू | प्रॉक्सी डोमेन के नियम लागू करता है; कोई गंतव्य अनुमत न हो तो बाहरी गंतव्य रोकता है |
अनुमत गंतव्य पर भी रहस्य भेजे जा सकते हैं। डोमेन सीमित करना भेजी जा रही सामग्री की जाँच करने जैसा नहीं है। सैंडबॉक्स के बाहर निष्पादन मंज़ूर करते समय यह न मानें कि मौजूदा रोक के नियम वैसे ही सुरक्षा देंगे। देखें कि मंज़ूरी किस दायरे को बढ़ाती है। OpenAI: नेटवर्क अनुमतियाँ और प्रॉक्सी की आवश्यकताएँ ।
6. पर्यावरण चर, ऑपरेटिंग सिस्टम और Cloud
रहस्य केवल फ़ाइलों में नहीं होते। शेल में API की हो, तो फ़ाइल तक पहुँच रोके जाने पर भी चाइल्ड प्रक्रिया विरासत में मिले पर्यावरण चरों से उसका मान इस्तेमाल कर सकती है। वातावरण की विरासत का प्रबंधन अलग से shell_environment_policy से किया जाता है।
चर का स्वचालित बहिष्करण: true बनाम false
true | डिफ़ॉल्टलागू नहीं करता उन चरों का स्वचालित बहिष्करण जिनके नाम में KEY, SECRET या TOKEN हो
falseलागू करता है वह स्वचालित बहिष्करण
ignore_default_excludes के मानों की तुलना है। यह फ़ाइल रोकने के नियम से अलग है और चर के नाम पर फ़िल्टर करता है; हर रहस्य नहीं पकड़ता।यह दूसरे नाम वाले चरों या प्रोग्राम द्वारा दूसरी जगह से लाए मानों की रक्षा नहीं करता। set बहिष्करण के बाद लागू होता है और हटाए गए चर वापस जोड़ सकता है। OpenAI: वातावरण की विरासत और प्राथमिकता ।
Windows: सैंडबॉक्स का तरीका भी जाँचें
स्थानीय Permission profiles के दस्तावेज़ macOS, Linux, WSL और मूल Windows को शामिल करते हैं, लेकिन उनके तरीके अलग हैं। Windows पर elevated सैंडबॉक्स को अधिक मज़बूत तरीका बताया गया है। unelevated सैंडबॉक्स में नेटवर्क अलगाव कमज़ोर है और पढ़ने-लिखने की कुछ अलगाव नीतियाँ लागू नहीं हो सकतीं। दस्तावेज़ बताते हैं कि असमर्थित नीतियों पर निष्पादन से इनकार होता है। त्रुटि आने पर Full access चुनना समाधान नहीं है। OpenAI: ऑपरेटिंग सिस्टम के अनुसार प्रवर्तन ।
Cloud: स्थानीय सेटिंग को वैसे ही न अपनाएँ
विशिष्ट Codex Cloud वातावरण की सेटिंग अलग से जाँचें। यह न मानें कि स्थानीय प्रोफ़ाइल पूरे Cloud या dot के क्लाउड वातावरण पर स्वतः लागू होगी। इस लेख के स्थानीय कॉन्फ़िगरेशन सुझाव को बिना बदलाव क्लाउड सेटिंग के रूप में न अपनाएँ। निष्पादन स्थान के अंतर के लिए देखें: Codex Remote, Cloud और PC कनेक्शन की आवश्यकताएँ ।
7. डमी फ़ाइलों से सत्यापन
“मैंने न पढ़ने को कहा”, “मैंने सेटिंग सहेजी” और “पढ़ने का अनुरोध सचमुच रोका गया”, अलग-अलग तरह के सबूत हैं। परीक्षण के लिए Codex को वास्तविक रहस्य पढ़वाने की आवश्यकता नहीं है। नीचे उपयोगकर्ता या व्यवस्थापक के लिए सत्यापन योजना है, इस डिवाइस पर परीक्षण की रिपोर्ट नहीं।
- वातावरण दर्ज करें: Codex का संस्करण, OS, निष्पादन स्थान और चुनी अनुमतियाँ नोट करें। CLI में कार्यक्षेत्र का दायरा
/statusसे और चुनी अनुमतियाँ/permissionsसे जाँचें। - कॉन्फ़िगरेशन के टकराव जाँचें: उपयोगकर्ता सेटिंग, विश्वसनीय प्रोजेक्ट की सेटिंग, चुनी प्रोफ़ाइल, स्टार्टअप फ़्लैग और व्यवस्थापक के प्रतिबंध देखें। जाँच के लिए पूरी कॉन्फ़िगरेशन फ़ाइल या गोपनीय मान बातचीत में पेस्ट न करें।
- डमी फ़ाइलें तैयार करें: रहस्य-रहित अलग कार्यक्षेत्र में अनुमत और प्रतिबंधित होने वाली फ़ाइलें बनाएँ। उनमें काल्पनिक पहचान-चिह्न रखें।
- अनुमति और रोक, दोनों सत्यापित करें: एक ही निष्पादन रास्ते से देखें कि अनुमत फ़ाइल पढ़ी जा सकती है और रोकी गई फ़ाइल पढ़ने पर त्रुटि आती है। Codex का अपनी इच्छा से फ़ाइल न पढ़ना लागू किए गए प्रतिबंध का सबूत नहीं है।
- अलग स्थानों पर जाँचें: रूट, उपफ़ोल्डर, प्रत्यय वाले नाम और शुरुआत के बाद बनी डमी फ़ाइलें जाँचें। रोक को पार करने वाली कार्रवाई मंज़ूर न करें। कोई अप्रत्याशित पढ़ना सफल हो, तो उस वातावरण का उपयोग रोककर कारण जाँचें।
- आउटपुट के रास्ते भी जाँचें: देखें कि परीक्षण या बिल्ड लॉग में रहस्य छापते हैं या वही जानकारी अन्य MCP टूल, ब्राउज़र या जुड़े ऐप को भेजते हैं।
उपलब्ध जानकारी CLI संस्करण और दृश्य के अनुसार बदलती है, इसलिए कमांड के नाम पर भरोसा करने की बजाय असली आउटपुट देखें। आधिकारिक CLI में codex sandbox के ज़रिए OS-विशिष्ट जाँच भी हैं। इन्हें समान मानने से पहले जाँचें कि सहायक कमांड में परीक्षित सेटिंग सामान्य डेस्कटॉप या IDE सत्र में लागू सेटिंग से मेल खाती है। OpenAI: सैंडबॉक्स का परीक्षण ।
बाद में रोक के नियम जोड़ना पहले पढ़ी जा चुकी सामग्री को वापस नहीं कर सकता। पुरानी बातचीत, लॉग और फ़ाइलों का भंडारण तथा प्रशिक्षण सेटिंग अलग-अलग जाँचें। केवल फ़ाइल का सफल पढ़ना तीसरे पक्ष को खुलासे का प्रमाण नहीं है। क्या पढ़ा गया, कहाँ पहुँचा और क्रेडेंशियल पर कार्रवाई चाहिए या नहीं, इन सवालों को अलग-अलग परखें।
उपयोगकर्ताओं ने Codex के सार्वजनिक मुद्दे में भी गोपनीय फ़ाइलें बाहर रखने के तरीके माँगे हैं। यह वास्तविक चिंता दर्शाता है, आज सुविधा असमर्थित होने का प्रमाण नहीं। लेख के विनिर्देश पुराने पोस्ट की बजाय मौजूदा आधिकारिक Permissions दस्तावेज़ पर आधारित हैं।
अक्सर पूछे जाने वाले सवाल
क्या केवल पढ़ने का मोड .env को भेजे जाने से रोकता है?
केवल पढ़ने का मोड बदलाव सीमित करता है; इससे यह गारंटी नहीं मिलती। पढ़ी जा सकने वाली .env की सामग्री मॉडल के संदर्भ में जाने से रोकने के लिए फ़ाइल पढ़ने का प्रतिबंध और रहस्य-रहित कार्य वातावरण अलग से जाँचें।
क्या .gitignore या AGENTS.md काफ़ी हैं?
ये लागू किए गए पढ़ने के प्रतिबंध की जगह नहीं लेते। Git के अनदेखा करने वाले नियम, काम के निर्देश और OS की लागू अनुमतियाँ अलग-अलग व्यवस्थाएँ हैं। डमी फ़ाइलों से जाँचें कि मौजूदा निष्पादन वातावरण में रोक काम करती है।
क्या नेटवर्क बंद करने से Codex पूरी तरह डिवाइस पर चलता है?
नहीं। कमांड के नेटवर्क प्रतिबंध मॉडल या प्रमाणीकरण सेवाओं से संचार नहीं रोकते। ब्राउज़र, MCP, जुड़े ऐप और क्लाउड की सेटिंग भी अलग हैं।
क्या यह उदाहरण Windows पर रहस्यों की पूरी रक्षा करता है?
पूरी सुरक्षा की गारंटी नहीं है। बीटा सुविधा का समर्थन, OS सैंडबॉक्स का तरीका, वास्तविक कॉन्फ़िगरेशन की परतें, पथ और चलाए जा रहे टूल जाँचने होंगे। लेख का उदाहरण वास्तविक मशीन पर लागू या परीक्षित नहीं है।
