𝗧𝗵𝗲 𝗦𝗮𝗳𝗲𝘀𝘁 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗜𝘀 𝗧𝗵𝗲 𝗢𝗻𝗲 𝗧𝗵𝗲 𝗔𝗴𝗲𝗻𝘁 𝗖𝗮𝗻'𝘁 𝗥𝗲𝗮𝗰𝗵 𝗔𝗰𝗿𝗼𝘀𝘀

जर एखादा AI agent अनेक संस्थांसाठी इन्फ्रास्ट्रक्चर चालवत असेल, तर सुरक्षा ही एक भयानक समस्या (nightmare) बनते.

धोका एजंटने एखादी हुशार चूक करणे हा नाही. धोका हा आहे की एजंट एखाद्या चुकीच्या व्यक्तीसाठी एखादी सामान्य गोष्ट करतो.

Customer A ऐवजी Customer B साठी तिकीट लिहिणे किंवा सीक्रेट (secret) रोटेट करणे हा डेटा ब्रीच (breach) आहे. तुम्ही ब्रीच 'पॅच' करू शकत नाही. तुम्हाला तो उघड करावा लागतो.

बहुतेक लोक हे परवानग्यांच्या (permissions) मदतीने सोडवण्याचा प्रयत्न करतात. एजंट काय वापरू शकतो याची ते एक यादी तयार करतात. ते प्रत्येक कृती त्या यादीनुसार तपासतात.

हे अपयशी ठरते. परवानग्या असे गृहीत धरतात की रिसोर्स (resource) अस्तित्वात आहे आणि तुम्ही फक्त 'नाही' म्हणता. जर तुमच्या नियमात काही त्रुटी (bug) असेल किंवा एखादी केस सुटली असेल, तर एजंट चुकीच्या डेटापर्यंत पोहोचतो.

मी एक वेगळे मॉडेल वापरतो. मी चुकीचा डेटा संरचनात्मकदृष्ट्या (structurally) अनुपस्थित करतो.

Customer A च्या सेशनमध्ये, Customer B चे रिसोर्सेस अस्तित्वात नसतात. क्रेडेंशियल्स (credentials) लोड केलेले नसतात. एंडपॉइंट्स (endpoints) मॅपमध्ये नसतात. तिथे मागण्यासाठी काहीच नसते, त्यामुळे नाकारण्यासाठीही काहीच नसते.

नियमांमध्ये त्रुटी असू शकतात. पण सिस्टमच्या भौतिक संरचनेत (physical structure) नसतात.

मी हे कठीण अनुभवातून शिकलो. मला वाटले की सीक्रेट्स मॅनेजर (secrets manager) पुरेसा आहे. मला वाटले की सीक्रेट्स वेगळे केल्यामुळे टेनंट्स (tenants) देखील वेगळे होतील. मी चुकत होतो.

सीक्रेट्स मॅनेजर सीक्रेट्स वेगळे करतो, पण तो एंडपॉइंट्स वेगळे करत नाही. एजंटकडे Customer A साठी योग्य टोकन असूनही, जर तो पत्ता कॉन्फिगरेशनमध्ये असेल, तर तो Customer B च्या पत्त्यावर विनंती (request) पाठवू शकतो.

गळती (leak) सीक्रेटमध्ये नसते. गळती राउटिंगमध्ये (routing) असते.

मी प्रत्येक रिसोर्स एकाच रेकॉर्डमध्ये बांधून (binding) हे ठीक केले: • Resource • Endpoint • Credential • Owning tenant

मालकाशिवाय (owner) तुम्ही पत्ता मिळवू शकत नाही. जर टेनंट सेशनशी जुळत नसेल, तर डेटा पाठवणारी लायब्ररी काम करण्यास नकार देते. तुम्ही हे हार्डकोड करून टाळू शकत नाही कारण पत्ता तेव्हाच अस्तित्वात असतो जेव्हा तो त्याच्या मालकाशी जोडलेला असतो.

मी संरक्षणाचे तीन स्तर वापरतो:

  • स्ट्रक्चरल आयसोलेशन (Structural isolation) जेणेकरून चुकीचा डेटा अस्तित्वात राहणार नाही.
  • बायपास ब्लॉक (Bypass block) जेणेकरून एजंट तपासणी टाळण्यासाठी रॉ टूल्स (raw tools) वापरू शकणार नाही.
  • एग्रेस स्कोपिंग (Egress scoping) जेणेकरून सेशन फक्त परवानगी दिलेल्या पत्त्यांशीच संवाद साधू शकेल.

यामुळे अशी सिस्टम तयार होते जी 'फेल क्लोज्ड' (fails closed) होते.

माझ्या मागील कामात, मी 'फेल ओपन' (failing open) साठी युक्तिवाद केला होता. जर एजंटला एखादी कृती सुरक्षित आहे की नाही याबद्दल शंका असेल, तर त्याने पुढे जावे. प्रत्येक शंकेवर थांबणारा एजंट निरुपयोगी असतो.

पण टेनंट सीमा (tenant boundaries) वेगळ्या असतात. जर एजंटला तो कोणाचा डेटा हाताळत आहे याबद्दल शंका असेल, तर त्याने थांबले पाहिजे.

कृतीमधील अनिश्चितता हालचालीकडे नेते. मालकीमधील अनिश्चिततेमुळे स्थिरता येणे आवश्यक आहे.

'नाही' म्हणणारे निर्बंध तयार करू नका. ज्या आकारांची तपासणी करण्याची गरज आहे, ते काढून टाका.

स्रोत: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

पर्यायी शिक्षण समुदाय: https://t.me/GyaanSetuAi