सत्यापन-योग्य दावे।

पासवर्ड की ज़रूरत केवल पहला SSH कनेक्शन खोलने और एक सर्विस यूज़र इंस्टॉल करने के लिए होती है। इसे हमारे कनेक्शन के लिए SSH प्रमाणीकरण के रूप में पास किया जाता है — किसी स्क्रिप्ट आर्ग्युमेंट या एनवायरनमेंट वेरिएबल के रूप में नहीं। हमारे डेटाबेस में इसके लिए कोई फ़ील्ड नहीं है; यह स्क्रिप्ट-रन एनवायरनमेंट में नहीं जाता और लॉग में नहीं लिखा जाता (कनेक्शन एरर में केवल पता और पोर्ट होते हैं, पासवर्ड कभी नहीं)। इस्तेमाल के बाद इसे मेमोरी में (best-effort) मिटा दिया जाता है — यह बहु-परत सुरक्षा (defense in depth) है, कोई गारंटी नहीं: Go, garbage collection होने तक इस वैल्यू की प्रतियाँ heap पर रख सकता है।

ईमानदार चेतावनी: यह आपके सर्वर पर root पासवर्ड ही बना रहता है। इंस्टॉलेशन के बाद हम SSH पर पासवर्ड और root लॉगिन बंद कर देते हैं, लेकिन पासवर्ड को स्वयं नहीं बदलते — चाहें तो इसे आप खुद बदलें। 'हम इसे संग्रहीत नहीं करते' सच है; 'यह अब गुप्त नहीं रहा' सच नहीं है।

PasswordAuthentication no, PermitRootLogin no, SSH को एक ग़ैर-मानक पोर्ट पर ले जाया गया (डिफ़ॉल्ट रूप से 12011), fail2ban सक्षम (5 विफलताओं के बाद एक घंटे का बैन), केवल key से लॉगिन। सार्वजनिक key को इस्तेमाल से पहले कड़ाई से मान्य किया जाता है: नई-पंक्तियाँ (authorized_keys में अतिरिक्त keys घुसाने से सुरक्षा) और सिंटैक्स की दृष्टि से अमान्य keys अस्वीकार कर दी जाती हैं।

एंटी-लॉकआउट: पोर्ट 22 तब तक बंद नहीं किया जाता जब तक kernel (ss के ज़रिए) यह पुष्टि न कर दे कि नया SSH पोर्ट वाकई सुन रहा है; कॉन्फ़िग की जाँच sshd -t से और sudo नियम की जाँच visudo -cf से की जाती है, एरर होने पर दोनों वापस पलट (roll back) दिए जाते हैं।

पैनल आपके पासवर्ड से नहीं, बल्कि एक अलग key (ed25519) से काम करता है जिसे वह खुद जनरेट करता है। निजी हिस्सा डेटाबेस में AES-256-GCM से एन्क्रिप्टेड रहता है। एन्क्रिप्शन key (KEK) डेटाबेस से अलग संग्रहीत होती है — एक सर्वर एनवायरनमेंट वेरिएबल में — और प्रोडक्शन में यह अनिवार्य है (कोई असुरक्षित डिफ़ॉल्ट नहीं है: KEK के बिना क्रिप्टो सबसिस्टम बस चालू ही नहीं होगा)। यही एन्क्रिप्शन डेटाबेस के भारी सीक्रेट्स की रक्षा करता है — Marzban एडमिन पासवर्ड/token/JWT, Reality keys, पेमेंट-प्रोवाइडर keys, प्रॉक्सी-क्रेडेंशियल cache, बैकअप कॉन्फ़िग।

एन्क्रिप्शन डेटा को केवल छिपाता नहीं बल्कि उसे प्रमाणित भी करता है (GCM auth tag): किसी एन्क्रिप्टेड फ़ील्ड से छेड़छाड़ डिक्रिप्शन के समय पकड़ी जाती है और अस्वीकार कर दी जाती है। हर फ़ील्ड को एक नए यादृच्छिक nonce के साथ एन्क्रिप्ट किया जाता है; KEK की वैल्यू कभी लॉग तक नहीं पहुँचती — केवल उसका छोटा id पहुँचता है।

क्षमता-token (capability tokens) के बारे में: /sub सब्सक्रिप्शन token एक bearer सीक्रेट है। लुकअप के लिए हम केवल उसका SHA-256 संग्रहीत करते हैं, जबकि पहले से जारी किए गए लिंक को दोबारा दिखाने के लिए ज़रूरी प्रति को AES-GCM ciphertext के रूप में रखा जाता है। पुराने plaintext रिकॉर्ड HTTP सर्वर शुरू होने से पहले, fail-closed तरीके से, नए फ़ॉर्मैट में माइग्रेट कर दिए जाते हैं। पेमेंट-webhook URL पहचानकर्ता को सादे रूप में संग्रहीत किया जाता है लेकिन वह अपने आप किसी इवेंट को प्रमाणित नहीं करता: प्रामाणिकता की पुष्टि अलग से एक HMAC हस्ताक्षर द्वारा की जाती है।

Partner API keys के सीक्रेट अपरिवर्तनीय हैं: पूरी key केवल एक बार, जारी करते समय दिखाई जाती है, और डेटाबेस में उसके सीक्रेट हिस्से का SHA-256 रहता है। कनेक्ट किए गए AI के access और refresh token भी सादे रूप में संग्रहीत नहीं होते; कनेक्शन चुने गए एक्सेस स्तर तक सीमित होता है और अकाउंट का मालिक उसे रद्द कर सकता है।

key को केवल सर्वर पर, मेमोरी में डिक्रिप्ट किया जाता है; सामान्य API इसे कभी वापस नहीं देते। इसे पाने का एकमात्र तरीका एक जानबूझकर बनाया गया एक्सपोर्ट फ़ंक्शन है ('अपनी key ले जाएँ'), जो साइन-इन के साथ-साथ एक एक-बार वाले email कोड से सुरक्षित है (कोड केवल एक HMAC हैश के रूप में संग्रहीत होता है, स्थिर समय (constant time) में तुलना की जाती है, 10-मिनट का TTL, 5 प्रयास)। यानी key को जानबूझकर निकाला जा सकता है, लेकिन किसी सामान्य अनुरोध के ज़रिए इसे 'लीक' नहीं किया जा सकता।

सर्वर की स्थिति बदलने से पहले और किसी भी बैकग्राउंड नेटवर्क ऑपरेशन से पहले, प्रबंधन key रखने वाले फ़ील्ड सिंक्रोनस रूप से शून्य (zero) कर दिए जाते हैं। यदि डेटाबेस साफ़ किए जाने की पुष्टि नहीं करता, तो ऑपरेशन एक एरर लौटाता है और उसे दोबारा आज़माया जा सकता है। हटाना 'soft' ही रहता है: पंक्ति और ग़ैर-गुप्त सर्विस डेटा सुरक्षित रखे जाते हैं। इसका मतलब पहले से बनाए गए बैकअप का भौतिक मिटाया जाना नहीं है — उनका जीवनचक्र बैकअप रिटेंशन नीति द्वारा नियंत्रित होता है।

पैनल के रूट में partner_id हस्ताक्षरित सत्र से प्राप्त किया जाता है, और Partner API में — सत्यापित API key या AI के OAuth कनेक्शन से। मालिक का पहचानकर्ता पथ (path), query पैरामीटर या अनुरोध के body से नहीं लिया जाता। API keys अतिरिक्त रूप से scope, वैधता अवधि और प्लान द्वारा सीमित होती हैं; कनेक्ट किए गए AI के लिए अनुमतियों का सेट हर अनुरोध पर मालिक द्वारा चुने गए स्तर के आधार पर निकाला जाता है।

कुछ भी लौटाने या बदलने से पहले, सिस्टम दोबारा जाँचता है कि सर्वर, क्लस्टर, inbound, रूट, VPN यूज़र या पेमेंट इसी अकाउंट का है। डेटाबेस क्वेरी partner_id तक सीमित होती हैं, और कंपोज़िट यूनीक व फ़ॉरेन keys अमान्य क्रॉस-पार्टनर लिंक अस्वीकार कर देती हैं। टेस्ट में प्राधिकरण मैट्रिक्स संसाधन पहचानकर्ता वाले हर endpoint के लिए एक स्पष्ट IDOR परिदृश्य की माँग करता है।

ईमानदार चेतावनी: यह अनुरोध-पथ के आर-पार एक कोड ऑडिट द्वारा सत्यापित है, किसी सार्वजनिक पेनिट्रेशन टेस्ट द्वारा नहीं — इसलिए SR-16, बाकी सबकी तरह, bug bounty में खंडन के लिए खुला है।

सब कुछ स्वचालित रूप से कॉन्फ़िगर करने के लिए (Xray+Reality इंस्टॉल करना, कॉन्फ़िग लागू करना, मेट्रिक्स पढ़ना) पैनल के पास सर्वर पर पूर्ण प्रशासनिक एक्सेस होता है (root-समकक्ष, बिना-पासवर्ड sudo वाले एक सर्विस यूज़र के ज़रिए)। यह प्रबंधन के लिए आवश्यक है, और हम इसे 'सीमित' नहीं कहते।

जोखिम को क्या कम करता है: सीक्रेट्स सर्वर को केवल प्रोसेस के stdin के ज़रिए भेजे जाते हैं (कमांड आर्ग्युमेंट के रूप में नहीं — वे प्रोसेस सूची में नहीं दिखते); शुरुआती इंस्टॉल के बाद, हर प्रबंधन कनेक्शन सर्वर की पिन-की-गई host key सत्यापित करता है — 'बीच में' किया गया सर्वर-स्वैप अस्वीकार कर दिया जाता है। आप क्या नियंत्रित करते हैं: एक्सेस एक ऐसी key पर टिका है जिसे आप किसी भी समय रद्द कर सकते हैं — सर्वर हटाकर (key शून्य कर दी जाती है) या बस अपने होस्ट पर VPS हटाकर (तब सब कुछ ग़ायब हो जाता है)।

VPN अकाउंट स्वयं (VLESS/Reality) आपके मास्टर सर्वर पर Marzban में बनाए जाते हैं और वहीं रहते हैं। केंद्रीय रूप से हम केवल वही संग्रहीत करते हैं जो एक सब्सक्रिप्शन लिंक जारी करने के लिए आवश्यक है: एक यादृच्छिक सब्सक्रिप्शन token और प्रॉक्सी क्रेडेंशियल का एक एन्क्रिप्टेड snapshot (एक cache; सत्य का स्रोत आपका Marzban है)। हमारे पास कोई ट्रैफ़िक, IP, या यूज़र विज़िट इतिहास नहीं है।

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

इन सेवा-संबंधी डेटा को हम केवल आवश्यक समय तक रखते हैं और स्वतः साफ़ कर देते हैं: ईमेल भेजने के तुरंत बाद भेजने की कतार से हटा दिया जाता है, भुगतान इवेंट का बॉडी संसाधन के बाद, और पुनः प्रयास की प्रतीक्षा कर रहे इवेंट 90 दिनों की अवधि के भीतर। आप “उन्नत सेटिंग” में अपने ईमेल पर आए कोड से पुष्टि करके अपना अकाउंट उसके सारे डेटा सहित खुद हटा सकते हैं (विवरण के लिए जोखिम 7 देखें)। हम इसे अस्पष्ट शब्दों के पीछे छिपाने के बजाय खुलकर बताते हैं।

CreateYourVPN प्लेटफ़ॉर्म यह जानकारी न प्राप्त करता है और न संग्रहीत करता है कि आप या आपके यूज़र कौन-सी साइटें देखते हैं। मेट्रिक्स-इनजेस्ट स्कीमा बंद है: इसमें IP, डोमेन, या विज़िट के लिए भौतिक रूप से कोई फ़ील्ड नहीं है — केवल समुच्चय (अद्वितीय ऑनलाइन गिनती, कुल bytes, CPU/RAM/लोड)। हर नोड अपने ही id से बंधे एक HMAC token से प्रमाणित होता है और केवल अपने लिए ही मेट्रिक्स लिख सकता है। नोड-पर मौजूद बैलेंसर (HAProxy) SNI के आधार पर एक TCP राउटर की तरह काम करता है और ट्रैफ़िक को डिक्रिप्ट नहीं करता। सर्वर पर स्वयं, सिस्टम जर्नल लगभग एक घंटे से अधिक नहीं रखे जाते और syslog को फ़ॉरवर्ड नहीं किए जाते।

प्लेटफ़ॉर्म स्तर से परे, सर्वर भी कोई विज़िट जर्नल नहीं रखते: हर कॉन्फ़िग पुश पर Xray की access logging ज़बरन बंद कर दी जाती है (प्लेटफ़ॉर्म log.access को none पर सेट करता है), इसलिए edge proxy यह रिकॉर्ड नहीं करता कि उपयोगकर्ता किन पतों से जुड़ते हैं। यह कोड में लागू किया गया है और पूरे fleet में तैनात किया गया है।

साइट और पैनल का उपयोग कैसे होता है यह समझने के लिए हम Google Analytics लगाते हैं (cookie बैनर cookie और आँकड़ों के संग्रह के बारे में चेतावनी देता है; विवरण गोपनीयता नीति में हैं)। OAuth सहमति पेजों पर एनालिटिक्स को लोड होने से अनिवार्य रूप से रोका जाता है: URL में AI कनेक्शन अनुरोध का एक अल्पकालिक पहचानकर्ता होता है, जिसे किसी थर्ड-पार्टी को नहीं भेजा जाना चाहिए। कोई अन्य थर्ड-पार्टी ट्रैकर नहीं है: न Sentry, न PostHog, न Mixpanel, और न कोई विज्ञापन pixel। बैकएंड में कोई थर्ड-पार्टी टेलीमेट्री नहीं है, और end-user स्टोरफ्रंट एनालिटिक्स से कवर नहीं होते।

चेतावनी: GA आपका IP (Google की तरफ़) और देखे गए पैनल पेजों के पते प्राप्त करता है; पैनल के URL में केवल एक क्लस्टर पहचानकर्ता होता है, कोई email नहीं।

पेमेंट और सभी कार्ड डेटा कनेक्ट किए गए प्रोवाइडर की तरफ़ (lava.top) संभाले जाते हैं। हमें केवल एक सत्यापित webhook इवेंट मिलता है: बैलेंस या एक्सेस में कोई बदलाव होने से पहले उसकी प्रामाणिकता उसी तरीके से स्थापित की जाती है जिसे संबंधित प्रोवाइडर सपोर्ट करता है। हमें पूरा कार्ड नंबर (PAN) या CVV नहीं मिलता। उसी इवेंट का दोबारा भेजा जाना दोहरा ग्रांट नहीं कराता: इवेंट डी-डुप्लिकेट कर दिए जाते हैं।

चेतावनी: प्रोवाइडर webhook body में कार्ड मेटाडेटा (ब्रांड और अंतिम 4 अंक) और भुगतानकर्ता का नाम व email शामिल कर सकता है। प्रोसेसिंग पूरी होने तक worker को मूल body की ज़रूरत होती है; सफल प्रोसेसिंग के बाद इसे email संकेत सहित हटा दिया जाता है। पुनः-प्रयास या मैन्युअल समीक्षा की प्रतीक्षा कर रहे इवेंट मूल body को केवल रिटेंशन विंडो के अंत तक (बिना गतिविधि के 90 दिन) रखते हैं, जिसके बाद कार्ड मेटाडेटा और भुगतानकर्ता का email स्वतः मिटा दिया जाता है। 'कोई पूरा कार्ड नंबर नहीं है' सच है, लेकिन यह प्रोवाइडरों का गुण है (हम स्वयं body को फ़िल्टर नहीं करते); 'हम कार्ड के बारे में बिल्कुल कुछ नहीं देखते' सच नहीं है।

अकाउंट के लिए email, आख़िरी साइन-इन का समय, इंटरफ़ेस मोड और सेटिंग्स संग्रहीत होती हैं; बिलिंग के लिए — बैलेंस और Telegram, यदि वह टॉप-अप के लिए दिया गया हो। अकाउंट की सुरक्षा के लिए सक्रिय सत्र में उसके बनने और आख़िरी गतिविधि का समय, IP पता और user-agent होता है। सफल और असफल साइन-इन प्रयासों का इतिहास, उन्हीं तकनीकी संकेतों के साथ, 90 दिनों तक रखा जाता है।

पैनल में क्लिकों का कोई सामान्य इतिहास नहीं है। अलग से विशिष्ट उद्देश्य वाले लॉग मौजूद हैं: Partner API अनुरोध — अधिकतम आख़िरी 500 प्रविष्टियाँ और लगभग 25 घंटे, इन्फ्रास्ट्रक्चर इवेंट और डायग्नोस्टिक परिणाम — अधिकतम 7 दिन, कनेक्ट किए गए AI की कार्रवाइयाँ — अकाउंट के साथ ही। AI की कार्रवाइयाँ दर्ज करने से पहले पासवर्ड, token, keys और सब्सक्रिप्शन लिंक हटा दिए जाते हैं, और उपयोगकर्ताओं के email मास्क किए जाते हैं।

फ़ायरवॉल डिफ़ॉल्ट रूप से आने वाले कनेक्शन अस्वीकार करता है। बाहर की ओर खुले: 443 (VPN, Xray+Reality), एक ग़ैर-मानक पोर्ट पर SSH (डिफ़ॉल्ट रूप से 12011), और — मास्टर सर्वर पर — Marzban एडमिन पैनल पोर्ट, केवल control-plane IP के लिए। पोर्ट 80 केवल Let's Encrypt मोड में HTTP-01 के लिए अलग से खोला जाता है। SSH स्थानांतरित होने के बाद पोर्ट 22 बंद कर दिया जाता है।

नोड के प्रबंधन पोर्ट केवल मास्टर सर्वर के IP के लिए खुले होते हैं, बाहर की ओर नहीं (इस binding की विफलता इंस्टॉल को रोक देती है)। यदि फ़ायरवॉल सक्रिय नहीं होता, तो इंस्टॉलेशन विफल हो जाता है। ICMP echo केवल IPv4 के लिए सीमित है; हम यह वादा नहीं करते कि सर्वर 'अदृश्य' है, और IPv6 के सही ढंग से काम करने के लिए IPv6 ICMP संरक्षित रखा जाता है।

Unattended upgrades सुरक्षा पैकेज अपडेट स्वचालित रूप से इंस्टॉल करता है। चेतावनी: स्वचालित reboot जानबूझकर बंद रखा गया है (ताकि कोई असत्यापित kernel अपने आप reboot न हो जाए) — इसका मतलब है कि reboot माँगने वाले फ़िक्स (kernel, कभी-कभी OpenSSH) केवल किसी मैन्युअल या निर्धारित reboot के बाद ही लागू होते हैं। 'ऑटो-पैचिंग' userland के लिए सच है, उसके लिए नहीं जिसे reboot चाहिए।

हम यह दावा नहीं करते कि सर्वर 'अदृश्य' है या 'स्कैन नहीं किया जा सकता'। पोर्ट 443 खुला है और किसी भी वेब सर्वर की तरह एक TCP कनेक्शन का जवाब देता है। यह गुण कि 'ग़लत कनेक्शन पर यह एक साधारण असंबंधित वेबसाइट जैसा दिखता है' — Xray के भीतर Reality प्रोटोकॉल द्वारा प्रदान किया जाता है — एक अलग घटक जिसे हम निरपेक्ष रूप में नहीं बदलते।

पार्टनर साइन-इन email पर भेजे गए एक-बार वाले 6-अंकीय कोड से होता है। कोई अकाउंट पासवर्ड नहीं है। यह प्रबंधित घटकों के आंतरिक क्रेडेंशियल पर लागू नहीं होता, जैसे सर्वर का जनरेट किया गया एडमिन पासवर्ड। कोड एक क्रिप्टोग्राफ़िक जनरेटर द्वारा बनाए जाते हैं; केवल उनका HMAC हैश संग्रहीत होता है, और तुलना स्थिर-समय में होती है। सफल होने पर कोड तुरंत हटा दिया जाता है, और 5 ग़लत प्रयासों के बाद उसे समय से पहले रद्द कर दिया जाता है। जारी करने की rate limit पूरे पते और भौतिक मेलबॉक्स, दोनों के आधार पर गिनी जाती है: IP बदलने, Gmail में बिंदु जोड़ने या plus-टैग लगाने से अलग सीमा नहीं मिलती।

सेशन token एक HttpOnly और Secure cookie में रहता है (JS इसे नहीं पढ़ सकता), जिसकी पुष्टि बैकएंड पर होती है (केवल edge पर नहीं)। निष्क्रियता पर idle टाइमआउट और ऑटो-लॉगआउट क्लाइंट पर लागू किए गए हैं, सर्वर पर नहीं। token को HS256 से हस्ताक्षरित किया जाता है; सत्यापन पर हम किसी भी अन्य एल्गोरिदम ('none' सहित) को कड़ाई से अस्वीकार करते हैं — क्लासिक एल्गोरिदम-स्वैप हमला पास नहीं होता। स्टोरफ्रंट token और पार्टनर-पैनल token audience के आधार पर अलग किए गए हैं: एक end-user token तकनीकी रूप से पार्टनर API तक नहीं पहुँच सकता (और इसका उलटा भी)। एक हटाया गया पार्टनर जीवित token के साथ भी अस्वीकार कर दिया जाता है।

हर पार्टनर सत्र का एक स्थिर सर्वर-साइड पहचानकर्ता होता है, जो token के नवीनीकरण पर भी बना रहता है। सामान्य साइन आउट पूरे मौजूदा सत्र को रद्द करता है, न कि केवल एक जारी token को। “खाता सत्र” अनुभाग में डिवाइस, IP पता, साइन-इन का समय और आख़िरी गतिविधि दिखती है; किसी भी सत्र को अलग से समाप्त किया जा सकता है। “सभी डिवाइस से साइन आउट करें” कार्रवाई सभी सत्र समाप्त करती है और कनेक्ट किए गए AI को डिस्कनेक्ट कर देती है।

साइन-इन इतिहास 90 दिनों तक रखा जाता है और उसमें सफल साइन-इन, ग़लत और समाप्त कोड, तथा प्रयासों की सीमा पार होना दिखता है। पहले से एक्सचेंज हो चुके token के दोबारा उपयोग के संकेत मिलने पर सिस्टम सत्र को कॉपी किया गया मानता है, सभी सत्र और AI कनेक्शन समाप्त कर देता है और मालिक को सूचना भेजता है।

ब्राउज़र के local storage में कोई सत्र token नहीं होते, केवल इंटरफ़ेस सेटिंग्स। token को HttpOnly cookie में Next.js की सर्वर लेयर रखती है; ब्राउज़र को बैकएंड का आंतरिक पता नहीं मिलता और वह Server Actions के ज़रिए उस तक पहुँचता है। CORS दूसरे origin को प्राधिकृत डेटा वाले API रिस्पॉन्स पढ़ने की अनुमति नहीं देता।

कुछ जानबूझकर रखे गए अपवाद हैं, जिन्हें मालिक स्वयं नियंत्रित करता है: email से मिले कोड के बाद निजी SSH key का एक्सपोर्ट (SR-4) और नई Partner API key, जिसका पूरा सीक्रेट बनाते समय ब्राउज़र में एक बार दिखाया जाता है। इसके बाद इसे डेटाबेस से वापस नहीं पाया जा सकता — वहाँ केवल हैश रहता है। सार्वजनिक API डोमेन डिज़ाइन के अनुसार इंटरनेट से पहुँच योग्य है, लेकिन वैध सत्र, API key या OAuth token के बिना यह कोई संरक्षित डेटा नहीं लौटाता।

CreateYourVPN के सार्वजनिक होस्ट HTTPS पर HSTS (max-age दो साल, includeSubDomains) के साथ सर्व किए जाते हैं। हमारे द्वारा होस्ट किया गया हर वेब फ़्रंटेंड — प्लेटफ़ॉर्म साइट, पार्टनर पैनल और पार्टनर स्टोरफ़्रंट, चाहे वे हमारे सबडोमेन पर हों या पार्टनर के अपने डोमेन पर — और API डोमेन, सभी सुरक्षा हेडर का एक ही सेट भेजते हैं: Content-Security-Policy (API पर default-src 'none'; फ़्रंटेंड पर यह iframe में एम्बेड करना रोकती है और base-uri तथा form-action को तय कर देती है), X-Content-Type-Options: nosniff, X-Frame-Options और सख़्त Referrer-Policy (API पर no-referrer; फ़्रंटेंड पर strict-origin-when-cross-origin, जो प्रतिबंधात्मक Permissions-Policy भी भेजते हैं)।

यह इन सभी होस्ट पर प्रोडक्शन में चल रहा है और स्वतंत्र रूप से जाँचा जा सकता है — किसी भी HTTP हेडर इंस्पेक्टर से या SSL Labs जैसी सेवा से।

AI ऐप OAuth के ज़रिए कनेक्ट होता है और आपके पैनल की cookie प्राप्त नहीं करता। सहमति पेज पर आप तीन में से एक स्तर चुनते हैं: केवल देखना; देखना और कॉन्फ़िगर करना; हटाना और एक्सेस देना। हर कॉल पर सर्वर अनुमतियों की जाँच करता है। महत्वपूर्ण डिलीट कार्रवाइयों के लिए email से मिले एक अतिरिक्त एक-बार वाले कोड की आवश्यकता होती है, और पूरे कनेक्शन को “कनेक्ट किए गए AI” अनुभाग में रद्द किया जा सकता है।

टूल का हर कॉल मालिक को दिखने वाले लॉग में परिणाम और आर्ग्युमेंट की सुरक्षित प्रति के साथ दर्ज होता है। पासवर्ड, token, API keys, निजी keys और सब्सक्रिप्शन लिंक दर्ज करने से पहले हटा दिए जाते हैं; उपयोगकर्ताओं के email मास्क किए जाते हैं। साथ ही, चुना गया AI ऐप एक थर्ड-पार्टी सेवा ही रहता है: जो डेटा आपने जानबूझकर उसे पढ़ने या बदलने के लिए सौंपा है, वह उसके प्रदाता के नियमों के अनुसार भी संसाधित होता है।