या घटनेमुळे अशा एका टीमला जाग आली ज्याने आपले संपूर्ण AWS ॲक्सेस मॉडेल या विश्वासावर उभारले होते की केवळ सावध माणसेच प्रोडक्शन कीज (production keys) वापरतात. आता प्रत्येक डेव्हलपरच्या वर्कफ्लोमध्ये AI एजंट्स समाविष्ट झाल्यामुळे, हा विश्वास चुकीचा ठरला. कंपनीने यावर उपाय म्हणून एक "ॲक्सेस ब्रोकर" (access broker) तयार केला, जो कोणत्याही प्रोडक्शन-लेव्हल ऑपरेशनसाठी मानवी संमतीची (human-in-the-loop approval) पायरी अनिवार्य करतो.


हा अपघात कसा झाला

एका इंजिनिअरने AI कोडिंग एजंटला पाइपलाइन स्क्रिप्ट तयार करण्यास सांगितले. त्या एजंटला इंजिनिअरचा प्रोडक्शन IAM रोल वारसाहक्काने मिळाला—ही एक अशी AWS ओळख आहे जी CloudFormation स्टॅक्स तयार करू शकते, बदलू शकते आणि हटवू शकते. ती स्क्रिप्ट चालली, लाइव्ह एन्व्हायरमेंटमध्ये एक स्टॅक तयार केला आणि लगेचच "क्लीनअप" स्टेप म्हणून तो काढून टाकला. ही प्रक्रिया मानक CI/CD पाइपलाइनला बायपास करून घडल्यामुळे, अशा बदलांवर नियंत्रण ठेवणारे पॉलिसी इंजिन कधीच ते पाहू शकले नाहीत.

मॉनिटरिंग प्लॅटफॉर्म, जो मंजूर पाइपलाइनच्या बाहेर कोणताही विशेषाधिकार प्राप्त (privileged) कृती करणारा रोल फ्लॅग करण्यासाठी सेट केला होता, त्याने स्टॅक हटवताच अलर्ट दिला. कोणतीही सेवा बंद पडली नाही, परंतु या अलार्मने असे एक परिमाण समोर आणले जिथे चुकीचे रिसोर्स नाव किंवा त्रुटीयुक्त AI प्रॉम्प्टमुळे महत्त्वपूर्ण इन्फ्रास्ट्रक्चर नष्ट झाले असते.

टीमला जाणीव झाली की, शोधणे (Detection) म्हणजे प्रतिबंध (Prevention) नव्हे. जर AI ने चुकीचा स्टॅक हटवला असता, तर मोठी आपत्ती ओढवली असती.


जुने क्रेडेंशियल मॉडेल का अपयशी ठरले

संस्थेचा पूर्वीचा दृष्टिकोन मल्टी-फॅक्टर ऑथेंटिकेशन (MFA) द्वारे संरक्षित अल्पकालीन सेशन्सवर अवलंबून होता. सिद्धांतानुसार, डेव्हलपरने सेशनची विनंती करावी, कार्य पूर्ण करावे आणि क्रेडेंशिअल्स आपोआप कालबाह्य व्हावेत. प्रत्यक्षात, एकदा लॅपटॉपवर सेशन सुरू झाले की, ते मशीन चालू असेपर्यंत टिकून राहत असे. प्रत्येक प्रक्रिया—टेस्ट सूट्स, बॅकग्राउंड स्क्रिप्ट्स आणि आता AI एजंट्स—कोणत्याही अतिरिक्त तपासणीशिवाय त्या क्रेडेंशिअल्सचा पुन्हा वापर करत होते.

त्या "एम्बियंट क्रेडेंशियल" (ambient credential) समस्येमुळे प्रोडक्शन IAM रोल डेव्हलपरच्या वर्कस्टेशनमध्येच कायमस्वरूपी रुजला होता. त्याच शेलमध्ये सबप्रोसेस म्हणून चालणारा AI एजंट, तेच परवानग्या वारसाहichtlich प्राप्त करत होता आणि मानवाप्रमाणेच प्रोडक्शन रिसोर्सेसवर कृती करू शकत होता.


ॲक्सेस ब्रोकर: एक नवीन रक्षक

एम्बियंट क्रेडेंशिअल्सची ही साखळी तोडण्यासाठी, टीमने प्रोडक्शन रोल कोण घेऊ शकते याची रचना पुन्हा केली. कोणत्याही डेव्हलपर आयडेंटिटीला थेट विशेषाधिकार प्राप्त रोल घेऊ देण्याऐवजी, त्यांनी एक एकल, काटेकोरपणे नियंत्रित घटक सादर केला: एक अंतर्गत ॲक्सेस ब्रोकर (internal access broker).

विनंती प्रवाह

  1. वेब पोर्टल – इंजिनिअर सेल्फ-सर्व्हिस पोर्टल उघडतो, आवश्यक ॲक्सेस लेव्हल (read-only, developer, किंवा administrator) निवडतो आणि त्याचे कारण देतो.
  2. Slack approval – विनंती एका समर्पित Slack चॅनेलवर पोस्ट केली जाते, जिथे नियुक्त व्यक्तीला (approver) स्पष्टपणे परवानगी द्यावी लागते.

Slack ची ही पायरी, ज्या टर्मिनलवर AI एजंट चालतो, त्यापेक्षा वेगळ्या प्लॅटफॉर्मवरील दुसऱ्या फॅक्टरप्रमाणे काम करते. कारण मंजुरी एका वेगळ्या UI मध्ये मिळणे आवश्यक असल्याने, एखादा स्वायत्त (autonomous) स्क्रिप्ट स्वतःहून ही प्रक्रिया पूर्ण करू शकत नाही.

टियर्ड ॲक्सेस

  • Read-only – वापरकर्ते रिसोर्सेस आणि लॉग्स पाहू शकतात परंतु कशातही बदल करू शकत नाहीत.
  • Developer – सपोर्ट टास्क आणि इन्फ्रास्ट्रक्चरमधील बदलांसाठी; ही टियर स्टॅक डिलीट करणे किंवा थेट ग्राहक डेटावर प्रवेश करणे यांसारख्या विनाशकारी कृतींना रोखते.
  • Administrator – पूर्ण अधिकार, जे केवळ आपत्कालीन हस्तक्षेपासाठी आणि उच्च-स्तरीय पुनरावलोकनानंतरच दिले जातात.

सर्व प्रोडक्शन ॲक्सेस ब्रोकरद्वारे वळवल्यामुळे, टीमने विशेषाधिकार प्राप्त क्रेडेंशिअल्स प्रत्येक लॅपटॉपवर विखुरण्याऐवजी, जोखीम एकाच, जोरदार संरक्षणाने सुरक्षित केलेल्या सेवेमध्ये केंद्रित केली.


ब्रोकर प्रत्यक्षात काय रोखतो

ब्रोकरचा मुख्य उद्देश एम्बियंट क्रेडेंशिअल्स थांबवणे हा आहे ज्याचा AI एजंट्स शांतपणे गैरफायदा घेऊ शकतात. जरी एखाद्या मानवाने विनंती मंजूर केली तरी, ती मंजुरी एक जाणीवपूर्वक घेतलेला निर्णय असतो; AI ही पायरी स्वतः तयार करू शकत नाही. परिणामी:

  • अनावधानाने होणारी डिलीशन (Unintended deletions) – जोपर्यंत एखादा माणूस सेशनला स्पष्टपणे अधिकृत करत नाही, तोपर्यंत AI आता डिलीट कमांड देऊ शकत नाही.
  • क्रेडेंशियल स्प्राउल (Credential sprawl) – प्रोडक्शन कीज आता डेव्हलपरच्या मशीनवर राहत नाहीत, ज्यामुळे दुर्भावनापूर्ण इनसाइडर्स आणि लॅपटॉप हॅक करू शकणाऱ्या बाह्य घटकांसाठीचा अटॅक सरफेस (attack surface) कमी होतो.

टीम यावर भर देते की ही प्रणाली मानवी चुका पूर्णपणे काढून टाकत नाही; चुकीच्या मंजुरीमुळे अजूनही नुकसान होऊ शकते. तथापि, हे कोणत्याही मानवी तपासणीशिवाय प्रोडक्शन रिसोर्सेसवर स्वायत्त कोड कृती करण्याचा "शांत" धोका काढून टाकते.


निष्कर्ष

जेव्हा AI एजंट्सना मानवी अभियंत्यांप्रमाणेच तेच अनियंत्रित क्रेडेंशियल्स मिळतात, तेव्हा त्यांना प्रोडक्शनमध्ये बिघाड करण्याची क्षमता प्राप्त होते—अनेकदा कोणाच्याही लक्षात न येता. एका ब्रोकरच्या माध्यमातून विशेषाधिकार प्राप्त प्रवेश (privileged access) मध्यवर्ती करून आणि एक स्वतंत्र मानवी मंजुरी मार्ग अनिवार्य करून, एखादी टीम स्वायत्त स्क्रिप्ट्सना गुपचूप नुकसान करण्यापासून रोखू शकते, जरी मानवी चुकीमुळे अजूनही समस्या निर्माण होऊ शकतात. खरी सुरक्षा उपलब्धी ही 'ambient credentials' काढून टाकण्यात आहे, प्रत्येक वैयक्तिक निर्णयावर देखरेख ठेवण्यात नाही.