एका AI-जनरेटेड क्रॉन जॉबने (cron job) एका स्टार्टअपमधील सर्व सक्रिय Stripe सबस्क्रिप्शन्स दहा सेकंदांच्या आत डिलीट केली, ज्यामुळे कंपनीचे मासिक आवर्ती उत्पन्न (monthly recurring revenue) थेट $38 वर आले. ही घटना दर्शवते की धोका कोड लिहिणाऱ्या लँग्वेज मॉडेलमध्ये नसून डेप्लॉयमेंट पाइपलाइनमध्ये (deployment pipeline) असतो.
काय घडले
गेल्या आठवड्यात BridgeMindAI च्या टीमला डॅशबोर्डवर केवळ $38 मासिक आवर्ती उत्पन्न (MRR) असल्याचे दिसून आले. एका AI मॉडेलने कोडची एक ओळ तयार केली जी शेड्युलरने (scheduler) आपोआप रन केली. त्या ओळीने प्रत्येक ग्राहक रेकॉर्डसाठी Stripe च्या subscription-cancellation endpoint ला कॉल केला. हा कॉल सात सेकंदात पूर्ण झाला आणि संपूर्ण ग्राहक डेटाबेस पुसला गेला.
त्या स्क्रिप्टने रिकाम्या डिलीशन क्यू (deletion queue) ला सर्व काही डिलीट करण्याचा सिग्नल म्हणून चुकीच्या पद्धतीने वाचले. "empty = all" हा पॅटर्न जनरेटिव्ह AI च्या खूप आधीपासून, म्हणजे १९८० च्या दशकापासूनच प्रोडक्शन कोडमध्ये अस्तित्वात आहे.
मॉडेल दोषी का नाही
लोकांनी लगेचच AI मॉडेलवर विश्वासार्हतेचा अभाव असल्याचा आरोप केला. मॉडेल बदलल्याने ही घटना थांबली नसती, कारण दोष मानवी तर्कशास्त्रात (logic) होता, कोणत्याही 'हॅलुसिनेशन' (hallucination) किंवा पूर्वग्रहामध्ये (bias) नव्हता.
खरे अपयश आर्किटेक्चरल (architectural) होते:
- त्या स्क्रिप्टमध्ये लाईव्ह प्रोडक्शन Stripe API की साठवली होती, ज्याद्वारे सबस्क्रिप्शन्स रद्द करता येत होते.
- ती कोणत्याही रनटाइम सुपरव्हिजनशिवाय (runtime supervision) चालली.
- कोड जनरेशन आणि एक्झिक्युशन (execution) दरम्यान कोणताही मानवी चेकपॉइंट (human checkpoint) नव्हता.
या त्रुटींमुळे एका सिंगल बगने काही सेकंदात महसूल प्रवाह नष्ट केला.
कोणत्याही ऑटोनॉमस पाइपलाइनसाठी तीन सुरक्षा प्रश्न
कोणत्या क्रिया अपरिवर्तनीय (irreversible) आहेत? सबस्क्रिप्शन रद्द करणे, रेकॉर्ड डिलीट करणे किंवा रिफंड देणे या गोष्टी पुन्हा पूर्ववत करता येत नाहीत. त्यांना 'रीड-ओन्ली' (read-only) क्वेरीजपेक्षा अधिक संरक्षणाची गरज असते.
एजंटकडे कोणती क्रेडेंशियल्स (credentials) आहेत? एखाद्या ऑटोनॉमस प्रोसेसला मास्टर Stripe की देणे म्हणजे त्याला अमर्याद अधिकार देणे होय. 'लिस्ट-प्रिव्हलेज' (least-privilege) तत्त्व लागू करा: केवळ आवश्यक कार्य करू शकतील अशा 'स्कोप्ड कीज' (scoped keys) वापरा.
मानवी चेकपॉइंट कुठे आहे? केवळ कोड रिव्ह्यू पुरेसा नाही. कोड जनरेशन नंतर आणि कोणतीही विनाशकारी कृती करण्या पूर्वी एक गेट (gate) ठेवा.
व्यावहारिक सुरक्षा उपाय (Practical safety rails)
- ड्राय-रन गेट (Dry-run gate) – कोणतीही डिलीट किंवा कॅन्सल कॉल करण्यापूर्वी, लक्षित (intended) टार्गेट्स लॉग करा. जर यादी रिकामी असेल किंवा असामान्यपणे मोठी असेल, तर प्रक्रिया थांबवा आणि मानवाला सूचित करा.
- स्कोप्ड क्रेडेंशियल्स (Scoped credentials) – डीफॉल्टनुसार 'रीड-ओन्ली' की वापरा. जेव्हा एखादे कार्य सबस्क्रिप्शन रद्द करणे आवश्यक असेल, तेव्हा अशी प्रतिबंधित की तयार करा जी एका वेळी केवळ एकाच कस्टमर आयडीवर काम करू शकेल.
- ह्युमन-इन-द-लूप प्रॉम्प्ट (Human-in-the-loop prompt) – एखाद्या चॅनेलवर (उदा. Slack) “मी ४७ सबस्क्रिप्शन्स रद्द करणार आहे. खात्री करा?” असा छोटा संदेश पाठवा. याचा खर्च नगण्य आहे; परंतु सुरक्षिततेचा फायदा मोठा आहे.
हे उपाय कोड कोणता मॉडेल लिहितो यावर अवलंबून नसतात, कारण ते जनरेटरचे नाही तर एक्झिक्युशन एन्व्हायरमेंटचे (execution environment) संरक्षण करतात.
ऑटोनॉमस एजंट्ससाठी प्रोडक्शन चेकलिस्ट
- प्रत्येक ऑपरेशनचे read, reversible, किंवा irreversible असे वर्गीकरण करा.
- सर्व irreversible कृतींसाठी स्पष्ट मानवी मंजुरी आवश्यक करा.
- क्रेडेंशियल्स केवळ कार्यासाठी आवश्यक असलेल्या किमान परवानग्यांपर्यंत मर्यादित ठेवा.
- रेकॉर्ड्स डिलीट किंवा मॉडिफाय करणाऱ्या लूप्सवर (loops) आकाराची मर्यादा (size limits) लागू करा.
- एजंट्सना प्रथम प्रोडक्शन डेटाचे अनुकरण करणाऱ्या सँडबॉक्समध्ये (sandbox) चालवून पहा; लाईव्ह डेटाला स्पर्श करण्यापूर्वी निकालाची खात्री करा.
- एक्झिक्युशनपूर्वी एजंटची योजना साध्या भाषेत लॉग करा, जेणेकरून रिव्ह्यूअरला ती एका दृष्टीक्षेपात समजेल.
या चेकलिस्टचे पालन केल्यामुळे "एकदा चालवा आणि विसरून जा" (run-once-and-forget) अशी स्क्रिप्ट एका नियंत्रित वर्कफ्लोमध्ये रूपांतरित होते, ज्याचे ऑडिट केले जाऊ शकते आणि काही चुकीचे वाटल्यास ती थांबवता येते.
धडा स्पष्ट आहे: प्रक्रियेवर विश्वास ठेवा, मॉडेलवर नाही.