सबसे सुरक्षित सीमा वह है जिसे एजेंट पार न कर सके

यदि कोई AI एजेंट कई संगठनों के लिए इंफ्रास्ट्रक्चर चलाता है, तो सुरक्षा एक दुःस्वप्न बन जाती है।

खतरा एजेंट द्वारा कोई चतुर गलती करने में नहीं है। खतरा एजेंट द्वारा किसी गलत व्यक्ति के लिए कोई सामान्य काम करने में है।

कस्टमर A के बजाय कस्टमर B के लिए टिकट लिखना या सीक्रेट रोटेट करना एक उल्लंघन (breach) है। आप उल्लंघन को पैच नहीं कर सकते। आपको इसका खुलासा करना ही होगा।

अधिकांश लोग इसे परमिशन (permissions) के माध्यम से हल करने की कोशिश करते हैं। वे एक सूची बनाते हैं कि एजेंट किन चीजों को छू सकता है। वे हर क्रिया की उस सूची के विरुद्ध जाँच करते हैं।

यह विफल हो जाता है। परमिशन यह मान लेती हैं कि रिसोर्स मौजूद है और आप बस 'ना' कह देते हैं। यदि आपके नियम में कोई बग है या कोई केस छूट गया है, तो एजेंट गलत डेटा तक पहुँच जाता है।

मैं एक अलग मॉडल का उपयोग करता हूँ। मैं गलत डेटा को संरचनात्मक रूप से अनुपस्थित (structurally absent) बना देता हूँ।

कस्टमर A के सत्र (session) में, कस्टमर B के रिसोर्स मौजूद ही नहीं होते। क्रेडेंशियल्स लोड नहीं होते। एंडपॉइंट्स मैप में नहीं होते। माँगने के लिए कुछ है ही नहीं, इसलिए मना करने के लिए भी कुछ नहीं है।

नियमों में बग हो सकते हैं। सिस्टम की भौतिक संरचना में नहीं।

मैंने यह कठिन अनुभव से सीखा। मुझे लगा कि एक सीक्रेट्स मैनेजर (secrets manager) काफी है। मुझे लगा कि सीक्रेट्स को अलग करने से टेनेंट्स (tenants) भी अलग हो जाएंगे। मैं गलत था।

एक सीक्रेट्स मैनेजर सीक्रेट्स को अलग करता है, लेकिन यह एंडपॉइंट्स को अलग नहीं करता है। एक एजेंट के पास कस्टमर A के लिए सही टोकन हो सकता है, लेकिन फिर भी वह कस्टमर B के पते पर अनुरोध भेज सकता है यदि वह पता कॉन्फ़िगरेशन में मौजूद है।

लीक सीक्रेट में नहीं है। लीक राउटिंग (routing) में है।

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

आप मालिक को प्राप्त किए बिना पता प्राप्त नहीं कर सकते। डेटा भेजने वाली लाइब्रेरी काम करने से मना कर देती है यदि टेनेंट सत्र (session) से मेल नहीं खाता है। आप इसे हार्डकोड (hardcode) करके बायपास नहीं कर सकते क्योंकि पता तभी मौजूद होता है जब वह अपने मालिक के साथ मजबूती से जुड़ा हो।

मैं सुरक्षा की तीन परतों का उपयोग करता हूँ:

  • स्ट्रक्चरल आइसोलेशन (Structural isolation) ताकि गलत डेटा मौजूद ही न हो।
  • एक बाईपास ब्लॉक (bypass block) ताकि एजेंट चेक को छोड़ने के लिए रॉ टूल्स (raw tools) का उपयोग न कर सके।
  • एग्रेस स्कोपिंग (Egress scoping) ताकि सत्र केवल अनुमत पतों से ही बात कर सके।

यह एक ऐसा सिस्टम बनाता है जो 'फेल क्लोज्ड' (fails closed) होता है।

अपने पिछले काम में, मैंने 'फेल ओपन' (failing open) का समर्थन किया था। यदि किसी एजेंट को यकीन नहीं है कि कोई क्रिया सुरक्षित है या नहीं, तो उसे आगे बढ़ना चाहिए। एक एजेंट जो हर संदेह पर रुक जाता है, वह बेकार है।

लेकिन टेनेंट की सीमाएं अलग होती हैं। यदि एजेंट को यकीन नहीं है कि वह किसके डेटा को छू रहा है, तो उसे रुकना ही चाहिए।

कार्य में अनिश्चितता गति की ओर ले जाती है। स्वामित्व में अनिश्चितता को स्थिरता की ओर ले जाना चाहिए।

ऐसे चेक न बनाएँ जो 'ना' कहें। उन आकृतियों को हटा दें जिन्हें जाँचने की आवश्यकता हो।

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

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi