एक सेंट्रल नोड प्रॉक्सी एक ही रात में प्रोवाइडर का पूरे महीने का बजट खत्म कर सकती है, जब कोई कॉम्प्रोमाइज़्ड सर्विस की (compromised service key) किसी ऐसे कम्प्लीशन रूट पर जाती है जिसमें ढील दी गई हो, और प्रॉक्सी रिक्वेस्ट बॉडी में कॉलर द्वारा दिए गए रूटिंग जैसे provider=openai और model=$OPENAI_CHAT_MODEL पर भरोसा करती है।
हमारे चल रहे सिस्टम में, AcmeSupportApp टेनेंट t_acme_prod की ओर से गेटवे को कॉल करती है, गेटवे $OPENAI_CHAT_MODEL, $ANTHROPIC_CHAT_MODEL, या $LLAMA_CHAT_MODEL तक रिक्वेस्ट भेजता है, और बार-बार आने वाले प्रॉम्प्ट्स पर टोकन बचाने के लिए गेटवे के पास एक शेयर्ड सिमेंटिक कैश होता है।
यह फेलियर कोई बहुत जटिल मॉडल ब्रेक नहीं है। अटैकर को बस एक ऐसी की (key) चाहिए होती है जो आज मौजूद मामूली जांच को पास कर ले, फिर वह लंबे प्रॉम्प्ट्स और बड़े आउटपुट लिमिट्स के साथ बहुत सारी रिक्वेस्ट भेजता है, और गेटवे उन्हें आगे भेज देता है क्योंकि प्रोवाइडर कॉल शुरू होने से पहले हर टेनेंट के लिए कोई लागू करने योग्य बजट रिज़र्व नहीं किया गया था।
एक बार जब प्रॉक्सी बिना फ़िल्टर किया हुआ प्रोवाइडर आउटपुट कॉलर को वापस भेज देती है, तो वही कॉम्प्रोमाइज़्ड की (key) डाउनस्ट्रीम टिकट रिप्लाई में असुरक्षित कंटेंट भेज सकती है क्योंकि गेटवे बाउंड्री पर जेनरेट किए गए टेक्स्ट पर कोई पॉलिसी लागू नहीं होती है।
उस क्रम को देखते हुए, कौन सा स्टेज सबसे पहली रिक्वेस्ट को ही मना कर सकता था, इससे पहले कि कोई खर्च हो या कोई असुरक्षित आउटपुट बने।
गेटवे ही एकमात्र ऐसा कंपोनेंट है जो कॉलर की पहचान और प्रोवाइडर की पसंद को एक साथ देखता है, इसलिए गेटवे ही वह जगह है जहाँ हम AcmeSupportApp को t_acme_prod से जोड़ सकते हैं और प्रोवाइडर की (key) का इस्तेमाल होने से पहले उसके दायरे से बाहर के किसी भी मॉडल या रूट को मना कर सकते हैं।
हर दूसरे हॉप (hop) में एक ज़रूरी जानकारी गायब होती है। प्रोवाइडर केवल गेटवे का प्रोवाइडर क्रेडेंशियल देखता है, इसलिए प्रोवाइडर हमारे प्लेटफ़ॉर्म के अंदर टेनेंट्स में अंतर नहीं कर सकता, और कैश केवल रिक्वेस्ट कंटेंट से बनी की (key) देखता है, इसलिए कैश यह लागू नहीं कर सकता कि किसे खर्च करने की अनुमति है या कॉलर किस मॉडल तक पहुँच सकता है।
TLS कनेक्शन सही होने पर भी कई जगहों से अनट्रस्टेड डेटा आता है। अगर हम कॉलर द्वारा दिए गए टेनेंट ID को स्वीकार करते हैं तो रिक्वेस्ट हेडर पहचान के बारे में गलत जानकारी दे सकते हैं, अगर हम रिक्वेस्ट बॉडी को मानते हैं तो वह रूटिंग और मॉडल सिलेक्शन के बारे में गलत जानकारी दे सकती है, और प्रोवाइडर का रिस्पॉन्स अनट्रस्टेड आउटपुट होता है जिसमें पॉलिसी का उल्लंघन करने वाला कंटेंट या स्कीमा को तोड़ने वाले स्ट्रक्चर्ड फ़ील्ड हो सकते हैं। यहाँ रिक्वेस्ट पाथ दिया गया है जिसमें उन ट्रस्ट बाउंड्रीज़ और एनफोर्समेंट पॉइंट्स को मार्क किया गया है।
यह डायग्राम उस व्यावहारिक सीमा को दिखाता है जिसके आधार पर हम बाकी कोर्स तैयार करते हैं। केवल गेटवे ही कॉलर को ऑथेंटिकेट कर सकता है, हर रिक्वेस्ट के लिए पॉलिसी का मूल्यांकन कर सकता है, शेयर्ड काउंटर के खिलाफ कोटा रिज़र्व कर सकता है, और रिस्पॉन्स के कॉलर के सिस्टम में वापस जाने से पहले इनपुट और स्ट्रीम किए गए आउटपुट दोनों की जाँच लागू कर सकता है।
जब हर एनफोर्समेंट पॉइंट पर एक ही रिफ्यूज़ल कोड होता है और कोड अगले महंगे स्टेप से पहले जेनरेट किया जाता है, तो हमले के दौरान गेटवे का व्यवहार अनुमानित रहता है। हम पूरे कोर्स के लिए एक ही रिफ्यूज़ल मैप का इस्तेमाल करते हैं ताकि सभी प्रोवाइडर्स के बीच लॉग, अलर्ट और क्लाइंट का व्यवहार एक जैसा रहे।
गायब, अमान्य, रद्द या कॉम्प्रोमाइज़्ड कॉलर क्रेडेंशियल के कारण 401 Unauthorized रिस्पॉन्स मिलता है।
अगर कोई ऑथेंटिकेटेड कॉलर अपनी अलाउलिस्ट के बाहर किसी रूट या मॉडल के लिए रिक्वेस्ट करता है, तो 403 Forbidden रिस्पॉन्स मिलता है, और गेटवे किसी भी प्रोवाइडर होस्ट से संपर्क करने से पहले ही मना कर देता है।
रेट लिमिट या टोकन और कॉस्ट कोटा खत्म होने पर 429 Too Many Requests के साथ Retry-After रिस्पॉन्स मिलता है, क्योंकि क्लाइंट को एक स्पष्ट बैकऑफ़ कॉन्ट्रैक्ट की ज़रूरत होती है और दोबारा कोशिश करने से खर्च नहीं बढ़ना चाहिए।
अगर गेटवे सुरक्षित रूप से नियम लागू नहीं कर पाता है (जैसे शेयर्ड काउंटर स्टोर डाउन होने या ओपन सर्किट ब्रेकर के कारण जाँच रुकने पर), तो गेटवे 503 Service Unavailable रिस्पॉन्स देता है, न कि बिना पहचान के खर्च करते हुए ‘फेल ओपन’ होता है।
अगर प्रोवाइडर कॉल गेटवे टाइमआउट से ज़्यादा समय लेती है, तो गेटवे 504 Gateway Timeout रिस्पॉन्स देता है और सफल रिस्पॉन्स के तौर पर आंशिक आउटपुट स्ट्रीम नहीं करता है।
अगर हमें स्ट्रक्चर्ड आउटपुट चाहिए और प्रोवाइडर का रिस्पॉन्स स्कीमा वैलिडेशन में फेल हो जाता है, तो गेटवे 422 Unprocessable Content रिस्पॉन्स देता है ताकि डाउनस्ट्रीम पार्सर कभी भी अनट्रस्टेड फ़ील्ड पर न चले।
शुरुआती घटना में, पहला रिफ्यूज़ल पॉइंट गेटवे ऑथेंटिकेशन और पॉलिसी चेक होना चाहिए—कोटा रिज़र्वेशन और प्रोवाइडर कॉल से पहले—क्योंकि एक बार रिक्वेस्ट बाहर की ओर जाने लगती है, तो बाद के चरणों में खर्च और अनुमतियों को t_acme_prod से जोड़ने के लिए ज़रूरी जानकारी नहीं रहती है।