AI एजेंट में सीक्रेट लीक होने पर क्या करें: एक्सेस रिवोकेशन, ऑडिटिंग और काम पर लौटना

निर्देशों का सत्यापन 16 सितंबर, 2026 को दस्तावेज़ों के आधार पर किया गया है।

जब कोई ऑटोनॉमस एजेंट git diff जैसे कमांड चलाता है, स्थानीय कॉन्फ़िगरेशन फ़ाइलों को पढ़ता है, या अनजाने में एनवायरनमेंट वेरिएबल्स के डंप सीधे मॉडल प्रॉम्प्ट में शामिल कर देता है, तो सीक्रेट्स ट्रस्टेड पेरिमिटर से बाहर चले जाते हैं। ऐसी स्थिति में, आपको बैकग्राउंड स्क्रिप्ट्स को रोकना होगा, कॉम्प्रोमाइज्ड क्रेडेंशियल्स को ब्लॉक करना होगा, उनकी सीमाओं को ध्यान में रखते हुए लॉग्स का ऑडिट करना होगा, और न्यूनतम विशेषाधिकार (least privilege) के सिद्धांत का पालन करते हुए परिवेश को पुनः प्रारंभ करना होगा।

सामान्य कॉन्फ़िगरेशन और संदर्भ लीक (Context Leak) में अंतर समझना

इंसिडेंट रिस्पॉन्स शुरू करने से पहले, सामान्य API उपयोग और वास्तविक कॉम्प्रोमाइज़ के बीच अंतर करना अत्यंत महत्वपूर्ण है।

सामान्य संचालन में लैंग्वेज मॉडल के लिए टूल रिक्वेस्ट्स को प्रमाणित करने हेतु API की केवल इच्छित मॉडल प्रदाता के ऑथराइजेशन फ़ील्ड में (उदाहरण के लिए, OPENAI_API_KEY या ANTHROPIC_API_KEY वेरिएबल्स के माध्यम से) पास की जाती है। ANTHROPIC_BASE_URL या OPENAI_BASE_URL जैसे वेरिएबल्स नेटवर्क एंडपॉइंट एड्रेस (endpoint/base URL) को परिभाषित करते हैं, न कि किसी सीक्रेट या ऑथेंटिकेशन टोकन को।

मॉडल के माध्यम से लीक तब माना जाता है, जब बुनियादी ढांचे के असंबंधित सीक्रेट्स—जैसे GitLab पर्सनल एक्सेस टोकन, दीर्घकालिक AWS IAM कीज़, प्राइवेट SSH कीज़, डेटाबेस क्रेडेंशियल्स या कॉर्पोरेट नेटवर्क टोकन—उपयोगकर्ता के प्रॉम्प्ट, बातचीत के संदर्भ, अटैच की गई फ़ाइलों, या यूटिलिटीज़ के आउटपुट स्ट्रीम (stdout/stderr) में आ जाते हैं और वास्तव में किसी बाहरी सेवा को बाहर भेज दिए जाते हैं। हालांकि किसी को सभी मध्यवर्ती प्रॉक्सी या गेटवे को स्वाभाविक रूप से दुर्भावनापूर्ण नहीं मानना चाहिए, लेकिन किसी अलग-थलग (isolated) परिवेश से बाहर सीक्रेट भेजना तत्काल रोकथाम की मांग करता है।

प्रारंभिक कदम: प्रक्रियाओं को रोकना और घटना का दस्तावेजीकरण करना

पहली प्राथमिकता आगे के डेटा ट्रांसमिशन को रोकना है:

1. स्थानीय एजेंट प्रक्रिया को समाप्त करें और संबंधित बैकग्राउंड कार्यों (cron जॉब्स, CI/CD ऑटोमेशन स्क्रिप्ट्स) को अक्षम करें।
2. स्वयं सीक्रेट की नकल किए बिना स्थानीय रिपोर्ट में घटना के मेटाडेटा को दर्ज करें: कॉम्प्रोमाइज्ड क्रेडेंशियल का प्रकार, पहले अनुरोध का अनुमानित समय (timestamp), टास्क/सेशन पहचानकर्ता, और प्राप्तकर्ता का नेटवर्क एंडपॉइंट एड्रेस।
3. सत्यापन के लिए सपोर्ट चैट चैनलों में या न्यूरल नेटवर्क के फॉलो-अप प्रश्नों में उजागर हुए सीक्रेट को प्लेनटेक्स्ट में न भेजें।

सभी कीज़ को रद्द करने (revocation) और बदलने के कार्य केवल एक विश्वसनीय वर्कस्टेशन से आधिकारिक प्रदाता प्रबंधन कंसोल का उपयोग करके ही किए जाने चाहिए।

सेवा प्रकार के अनुसार एक्सेस रद्द करना

विभिन्न प्लेटफ़ॉर्म अलग-अलग आर्किटेक्चरल नियमों के अनुसार आइसोलेशन और ऑथराइजेशन रिवोकेशन लागू करते हैं।

मॉडल एक्सेस कीज़ (OpenAI API)

आधिकारिक OpenAI की API की सुरक्षा संबंधी सर्वोत्तम कार्यप्रणालियों के अनुसार, कॉम्प्रोमाइज़ का संदेह होने पर की को रोटेट करना और संसाधन खपत की समीक्षा करना आवश्यक है।

लीक का संदेह होने पर, कॉम्प्रोमाइज्ड की को सबसे पहले रद्द किया जाना चाहिए:

1. तुरंत OpenAI API की प्रबंधन वेब इंटरफ़ेस पर जाएं और कॉम्प्रोमाइज्ड की को रद्द (Revoke/Delete) करें। यह निर्भर सेवाओं के नियंत्रित अस्थायी डाउनटाइम की कीमत पर आगे की अनधिकृत कॉल्स को ब्लॉक करता है; पूर्ण ऑडिट या सभी उपभोक्ताओं में लंबे समय तक चलने वाले अपडेट के पूरा होने तक रिवोकेशन को टाला नहीं जाना चाहिए।
2. एक नई की जनरेट करें और उसे सेवा कॉन्फ़िगरेशन में अपडेट करें।
3. Usage डैशबोर्ड खोलें और अपेक्षित संचालन के साथ तुलना करते हुए निर्धारित एक्सपोज़र विंडो के भीतर की गतिविधि का विश्लेषण करें।

GitLab पर्सनल एक्सेस टोकन

Personal Access Tokens पर GitLab दस्तावेज़ के अनुसार, किसी पर्सनल एक्सेस टोकन को रद्द करने से वह तुरंत अमान्य हो जाता है:

1. GitLab इंटरफ़ेस में, ऊपरी दाएं कोने में अपने अवतार पर क्लिक करें > Edit profile > Access > Personal access tokens।
2. सक्रिय टोकन की तालिका में, कॉम्प्रोमाइज्ड टोकन पहचानकर्ता ढूंढें और Revoke पर क्लिक करें।

GitLab में Rotate फ़ंक्शन पुराने टोकन को अमान्य कर देता है, लेकिन पिछले स्कोप्स (scopes) को बनाए रखता है। यदि कॉम्प्रोमाइज्ड टोकन के पास अत्यधिक अनुमतियां थीं, तो उसे पूरी तरह से रद्द कर दिया जाना चाहिए और न्यूनतम स्कोप्स के साथ एक नया टोकन बनाया जाना चाहिए। टोकन विवरण पृष्ठ पर अंतिम उपयोग की तारीख और पिछले पांच अद्वितीय IP पते प्रदर्शित होते हैं। ध्यान रखें कि ये मेट्रिक्स सिस्टम में थोड़ी देरी के साथ अपडेट होते हैं।

AWS एक्सेस कीज़ (IAM Access Keys)

IAM कीज़ को निष्प्रभावी करने की प्रक्रिया एक्सेस कीज़ को सुरक्षित करने पर AWS गाइड और IAM यूज़र्स के लिए एक्सेस कीज़ के प्रबंधन संबंधी दस्तावेज़ों द्वारा नियंत्रित होती है:

1. AWS Management Console में साइन इन करें, IAM > Users पर जाएं, और Security credentials टैब खोलें।
2. Access keys अनुभाग में, कॉम्प्रोमाइज्ड की का पहचानकर्ता खोजें और उसकी स्थिति को Deactivate में बदलें।
3. नियंत्रण पुनः प्राप्त होने के बाद, Delete का चयन करके की को हटा दें।

[!IMPORTANT] किसी की को Deactivate पर सेट करने से इस दीर्घकालिक क्रेडेंशियल के साथ हस्ताक्षरित नए अनुरोधों की स्वीकृति रुक जाती है, लेकिन यह पहले जारी किए गए अस्थायी क्रेडेंशियल्स (AWS STS tokens) को अमान्य नहीं करता है और सक्रिय सत्रों को स्वचालित रूप से समाप्त नहीं करता है। Revoke active sessions की कार्रवाई केवल संबंधित IAM भूमिका के सत्रों पर लागू होती है; सक्रिय IAM Identity Center सत्रों और अन्य प्रकार के STS टोकन को उनके विशिष्ट प्रमाणीकरण तंत्र के माध्यम से अलग से रद्द करने की आवश्यकता होती है। सुरक्षा व्यवस्थापक को AWS CloudTrail और get-access-key-last-used ऑपरेशन का उपयोग करके API कॉल्स का मिलान भी करना चाहिए। किसी सक्रिय घटना के दौरान अप्रमाणित, विनाशकारी बल्क डिलीशन CLI कमांड न चलाएं।

OpenSSH कीज़ और ऑथराइजेशन

OpenSSH प्रमाणीकरण प्रक्रियाओं का विवरण संदर्भ नियमावली man sshd(8) और sshd_config(5) में दिया गया है:

1. व्यवस्थापकों को सभी सर्वरों पर ऑथराइजेशन फ़ाइल से कॉम्प्रोमाइज्ड पब्लिक की को हटाना होगा। फ़ाइल का पथ AuthorizedKeysFile निर्देश द्वारा निर्धारित किया जाता है (डिफ़ॉल्ट रूप से ~/.ssh/authorized_keys, हालांकि बुनियादी ढांचे में केंद्रीकृत फ़ाइलें या SSH CA के माध्यम से प्रमाणपत्र सत्यापन कॉन्फ़िगर किया जा सकता है)।
2. संशोधन करने से पहले, सुनिश्चित करें कि अपने स्वयं के एक्सेस को ब्लॉक होने से बचाने के लिए एक स्वतंत्र बैकअप एक्सेस पथ (जैसे प्रदाता वेब कंसोल या out-of-band management) उपलब्ध है।
3. पब्लिक की को हटाने से नए कनेक्शन स्थापित होने से रुक जाते हैं, लेकिन यह पहले से सक्रिय सत्रों को समाप्त नहीं करता है।

who कमांड केवल स्यूडोटर्मिनल (TTY) आवंटित उपयोगकर्ताओं को प्रदर्शित करता है और यह सत्रों की पूरी सूची प्रदान नहीं करता है: यह टनल, पोर्ट फ़ॉरवर्डिंग या गैर-इंटरैक्टिव कमांड नहीं दिखाएगा। रूट sshd प्रक्रिया को आंख मूंदकर समाप्त करना अस्वीकार्य है, क्योंकि यह चाइल्ड सत्रों के समाप्त होने की गारंटी नहीं देता है और व्यवस्थापक को सर्वर से डिस्कनेक्ट करने का जोखिम उठाता है। व्यवस्थापकों को विशेष रूप से प्रोसेस ट्री, सक्रिय नेटवर्क कनेक्शन और ऑथराइजेशन लॉग की जांच करनी चाहिए, और विशिष्ट संदिग्ध सत्रों को समाप्त करना चाहिए। स्थानीय रूप से प्राइवेट की को हटाने या उसके पासफ़्रेज़ (passphrase) को बदलने का उस की पर कोई प्रभाव नहीं पड़ता है जिसे पहले ही बाहर कॉपी किया जा चुका है।

Tailscale नेटवर्क और कॉर्पोरेट VPN

Auth Keys पर Tailscale दस्तावेज़ के अनुसार, एक ऑथेंटिकेशन की पूरी तरह से नोड्स के पंजीकरण के लिए बनाई गई है:

1. Tailscale कंसोल में, Keys पर जाएं और कॉम्प्रोमाइज्ड auth key को रद्द करें। इससे नए उपकरण पंजीकृत नहीं हो सकेंगे।
2. auth key को रद्द करने से पहले से पंजीकृत नोड्स डिस्कनेक्ट नहीं होते हैं। व्यवस्थापक को Machines टैब पर जाना चाहिए, उपकरण सूची की समीक्षा करनी चाहिए और किसी भी अनधिकृत डिवाइस को मैन्युअल रूप से हटाना (Remove/Delete) चाहिए।

पारंपरिक कॉर्पोरेट VPN (IPsec, OpenVPN, WireGuard, और प्रोप्राइटरी समाधान) के लिए, CRL के माध्यम से कोई एकल सार्वभौमिक निरसन प्रक्रिया नहीं है: विशिष्ट तंत्र उपयोग की जाने वाली ऑथराइजेशन योजना (x509 प्रमाणपत्र, स्टैटिक preshared keys, RADIUS/IdP टोकन) पर निर्भर करता है। कई गेटवे पर, खाता पासवर्ड बदलने से सक्रिय टनल तुरंत समाप्त नहीं होती है। प्रक्रिया को नेटवर्क व्यवस्थापक को सौंप दिया जाना चाहिए ताकि प्रमाणपत्र/खाता रद्द किया जा सके और विशिष्ट VPN गेटवे प्रबंधन कंसोल के माध्यम से सक्रिय सत्रों को जबरन समाप्त किया जा सके।

परिणामों का विश्लेषण: लॉग्स, टाइम विंडो और अपरिवर्तनीय जोखिम

घटना को सिस्टम लॉग्स के साथ सहसंबंधित करते समय, टेलीमेट्री की तकनीकी सीमाओं को ध्यान में रखें:

• एक्सपोज़र विंडो (Exposure window): एजेंट को सीक्रेट के पहले ट्रांसमिशन से लेकर पुष्ट की-रिवोकेशन और सक्रिय सत्र समाप्ति के बीच का सटीक समय अंतराल स्थापित करें।
• लॉग की सीमाएं (Log limitations): इवेंट इनजेशन में देरी (ingestion delay), लॉग रिटेंशन अवधि (retention period), और टेलीमेट्री ब्लाइंड स्पॉट्स (जैसे कुछ API में विस्तृत पैरामीटर ऑडिट की कमी, या बिना TTY वाले सत्रों के लिए लॉगिंग की अनुपस्थिति) को ध्यान में रखें।
• सबूत के अभाव का सिद्धांत (Absence of evidence principle): सुलभ लॉग विंडो के भीतर किसी असामान्य प्रविष्टि का न होना या शून्य टोकन उपयोग यह साबित नहीं करता है कि सीक्रेट को किसी तीसरे पक्ष द्वारा इंटरसेप्ट नहीं किया गया था या बाद में उपयोग के लिए संग्रहीत नहीं किया गया था।

कीज़ को रद्द करना भविष्य के अनुरोधों को रोकता है, लेकिन यह बाहरी सेवा को पहले ही भेजे जा चुके डेटा, सोर्स कोड या एनवायरनमेंट वेरिएबल्स को वापस नहीं लाता है। एजेंट या प्लेटफ़ॉर्म वेब इंटरफ़ेस में बातचीत को हटाना ट्रांसक्रिप्ट को छुपा देता है, लेकिन यह इस बात की कोई तकनीकी गारंटी नहीं देता है कि डेटा को डाउनस्ट्रीम प्रदाता के लॉग या कैश से हटा दिया गया है।

सुरक्षित रीस्टार्ट: जोखिमों को कम करना और आइसोलेशन का सत्यापन करना

एजेंट को परिचालन स्थिति में वापस लाने से घटना की पुनरावृत्ति का जोखिम कम होना चाहिए:

1. अल्पकालिक टोकन (Short-lived tokens): जहां भी प्लेटफ़ॉर्म और बुनियादी ढांचे द्वारा समर्थित हो, समय-सीमित सत्र क्रेडेंशियल्स का लाभ उठाएं।
2. कार्यक्षेत्र की सीमाएं (Workspace boundaries): एजेंट के वर्कस्पेस से .env फ़ाइलों, प्राइवेट कीज़ और सीक्रेट्स वाली निर्देशिकाओं को बाहर रखें; सीक्रेट्स को वर्कस्पेस से बाहर ले जाना पूर्ण आइसोलेशन की गारंटी नहीं देता है और ऑपरेटिंग सिस्टम-स्तरीय एक्सेस नियंत्रणों का विकल्प नहीं है।
3. नेटवर्क कैनरी के बिना सीमाओं का परीक्षण (Testing boundaries without network canaries): अनुमतियों का परीक्षण करने के लिए, वास्तविक सीक्रेट्स से रहित एक अस्थायी पृथक निर्देशिका बनाएं। अंदर मॉक प्लेसहोल्डर सामग्री वाली एक डमी फ़ाइल रखें और सत्यापित करें कि क्या एजेंट फ़ाइल एक्सेस, शेल कमांड निष्पादन और env के माध्यम से वेरिएबल्स को पढ़ने से रोकता है। बुनियादी अनुमति सत्यापन के लिए बाहरी नेटवर्क canary tokens सेवाओं पर भरोसा न करें।
4. गहन सुरक्षा (Defense in depth): किसी एकल पथ पर पढ़ने को सफलतापूर्वक रोकना पूर्ण प्रक्रिया अलगाव को साबित नहीं करता है यदि एजेंट टर्मिनल या नेटवर्क तक अप्रतिबंधित पहुंच बनाए रखता है।

सिस्टम कॉल्स को प्रतिबंधित करने और अनुमतियों को अलग करने के विस्तृत आर्किटेक्चरल दृष्टिकोण पर Claude Code में अनुमतियों और सीक्रेट्स के प्रबंधन पर गाइड में चर्चा की गई है। न्यूनतम विशेषाधिकार लागू करना और स्थिर सीक्रेट्स को समाप्त करना ऑटोनॉमस AI टूल्स को कार्य सौंपते समय जोखिम को कम करता है।