ایک مرکزی نوڈ پراکسی (Node proxy) سروس کا ایک ماہ کا بجٹ راتوں رات ختم کر سکتی ہے اگر کوئی سمجھوتہ شدہ (compromised) سروس کی (key) کسی ایسے ‘تکمیلی راستے’ (completion route) پر استعمال ہو جس میں نرمی برتی گئی ہو، اور پراکسی درخواست کی باڈی میں موجود ‘کالر’ کی فراہم کردہ روٹنگ (جیسے provider=openai اور model=$OPENAI_CHAT_MODEL) پر بھروسہ کر لے۔
ہمارے فعال نظام میں، AcmeSupportApp کرایہ دار (tenant) t_acme_prod کی جانب سے گیٹ وے کو کال کرتی ہے؛ گیٹ وے درخواست کو $OPENAI_CHAT_MODEL، $ANTHROPIC_CHAT_MODEL، یا $LLAMA_CHAT_MODEL کی طرف بھیجتا ہے، اور بار بار آنے والے پرامپٹس (prompts) پر ٹوکنز کی بچت کے لیے گیٹ وے کے قریب ایک مشترکہ سیمانٹک کیشے (semantic cache) موجود ہوتا ہے۔
یہ ناکامی کسی ماڈل کی پیچیدہ خرابی نہیں ہے۔ حملہ آور کو صرف ایسی ‘کی’ (key) درکار ہوتی ہے جو موجودہ سطحی جانچ پڑتال سے گزر جائے، پھر وہ طویل پرامپٹس اور بڑی آؤٹ پٹ حدود کے ساتھ بڑی تعداد میں درخواستیں بھیجتا ہے، اور گیٹ وے انہیں آگے بڑھا دیتا ہے کیونکہ پرووائیڈر کو کال شروع ہونے سے پہلے فی کرایہ دار (per-tenant) کوئی ایسا بجٹ مختص نہیں کیا گیا تھا جس کا نفاذ ممکن ہو۔
جب پراکسی پرووائیڈر کی غیر فلٹر شدہ آؤٹ پٹ واپس کالر تک پہنچاتی ہے، تو وہی سمجھوتہ شدہ ‘کی’ ٹکٹ کے جوابات میں غیر محفوظ مواد شامل کر سکتی ہے کیونکہ گیٹ وے کی سطح پر تیار کردہ متن (generated text) پر کسی پالیسی کا نفاذ نہیں ہو رہا ہوتا۔
اس ترتیب کو دیکھتے ہوئے، کون سا مرحلہ پہلی ہی درخواست کو مسترد کر سکتا تھا—اس سے پہلے کہ کوئی خرچہ ہوتا یا کوئی غیر محفوظ آؤٹ پٹ وجود میں آتی؟
گیٹ وے واحد جزو ہے جو بیک وقت کالر کی شناخت اور پرووائیڈر کے انتخاب کو دیکھتا ہے؛ لہذا گیٹ وے ہی وہ مقام ہے جہاں ہم AcmeSupportApp کو t_acme_prod کے ساتھ منسلک کر سکتے ہیں اور پرووائیڈر کی ‘کی’ استعمال ہونے سے پہلے اس کے دائرہ کار سے باہر کسی بھی ماڈل یا راستے کو مسترد کر سکتے ہیں۔
ہر دوسرے مرحلے (hop) میں ایک اہم جزو کی کمی ہوتی ہے۔ پرووائیڈر صرف گیٹ وے کے پرووائیڈر اسناد (credentials) دیکھتا ہے، اس لیے وہ ہمارے پلیٹ فارم کے اندر موجود کرایہ داروں میں فرق نہیں کر سکتا؛ اور کیشے صرف درخواست کے مواد سے اخذ کردہ ‘کی’ دیکھتا ہے، اس لیے وہ یہ نافذ نہیں کر سکتا کہ کسے خرچ کرنے کی اجازت ہے یا کالر کس ماڈل تک رسائی حاصل کر سکتا ہے۔
غیر مصدقہ ڈیٹا متعدد مقامات پر داخل ہوتا ہے، یہاں تک کہ جب TLS کنکشن درست ہو۔ اگر ہم کالر کی فراہم کردہ ‘ٹیننٹ آئی ڈیز’ (tenant IDs) کو قبول کریں تو درخواست کے ہیڈرز شناخت کے بارے میں غلط معلومات دے سکتے ہیں؛ اگر ہم درخواست کی باڈی کو تسلیم کریں تو وہ روٹنگ اور ماڈل کے انتخاب کے بارے میں غلط بیانی کر سکتی ہے؛ اور پرووائیڈر کا جواب ایک غیر مصدقہ آؤٹ پٹ ہوتا ہے جس میں پالیسی کی خلاف ورزی کرنے والا مواد یا اسکیما (schema) کو توڑنے والے اسٹرکچرڈ فیلڈز شامل ہو سکتے ہیں۔ یہاں درخواست کا وہ راستہ دکھایا گیا ہے جس میں اعتماد کی حدود اور نفاذ کے مقامات کی نشاندہی کی گئی ہے۔
یہ خاکہ اس عملی رکاوٹ کو ظاہر کرتا ہے جس کے گرد ہم باقی کورس کی تشکیل کرتے ہیں۔ صرف گیٹ وے ہی کالر کی تصدیق (authenticate) کر سکتا ہے، فی درخواست پالیسی کا جائزہ لے سکتا ہے، مشترکہ کاؤنٹر کے خلاف کوٹہ مختص کر سکتا ہے، اور جواب کے کالر کے سسٹم میں واپس جانے سے پہلے ان پٹ اور اسٹریم شدہ آؤٹ پٹ دونوں کی جانچ (checks) کو نافذ کر سکتا ہے۔
جب ہر نفاذی مقام (enforcement point) پر انکار کا ایک ہی کوڈ ہو اور یہ کوڈ اگلے مہنگے مرحلے سے پہلے تیار کیا جائے، تو گیٹ وے حملے کے دوران بھی متوقع رویہ برقرار رکھتا ہے۔ ہم پورے کورس کے لیے انکار کا ایک ہی نقشہ استعمال کرتے ہیں تاکہ مختلف پرووائیڈرز کے درمیان لاگز، الرٹس اور کلائنٹ کا رویہ یکساں رہے۔
کالر کی اسناد (credentials) کا غائب، غلط، منسوخ شدہ یا سمجھوتہ شدہ (compromised) ہونا 401 Unauthorized کا نتیجہ بنتا ہے۔
ایک تصدیق شدہ کالر جو اپنی ‘اجازت شدہ فہرست’ (allowlist) سے باہر کسی روٹ یا ماڈل کی درخواست کرتا ہے، اسے 403 Forbidden کا سامنا کرنا پڑتا ہے، اور گیٹ وے کسی بھی پرووائیڈر ہوسٹ سے رابطہ کرنے سے پہلے ہی انکار کر دیتا ہے۔
ریٹ لمیٹ (rate limit) یا ٹوکن اور لاگت کا کوٹہ ختم ہونے پر 429 Too Many Requests کا جواب ملتا ہے جس کے ساتھ Retry-After کی ہدایت ہوتی ہے، کیونکہ کلائنٹ کو ‘بیک آف’ (backoff) کے واضح اصول کی ضرورت ہوتی ہے اور دوبارہ کوششوں (retries) سے اخراجات میں اضافہ نہیں ہونا چاہیے۔
اگر گیٹ وے محفوظ طریقے سے نفاذ نہیں کر سکتا (مثلاً مشترکہ کاؤنٹر اسٹور بند ہے یا سرکٹ بریکر نے جانچ کو روک رکھا ہے)، تو گیٹ وے 503 Service Unavailable کا جواب دیتا ہے بجائے اس کے کہ وہ بغیر کسی رکاوٹ کے آگے بڑھ جائے (failing open) اور بغیر انتساب (attribution) کے اخراجات کرے۔
اگر پرووائیڈر کال گیٹ وے کے ٹائم آؤٹ (timeout) سے تجاوز کر جائے، تو گیٹ وے 504 Gateway Timeout کا جواب دیتا ہے اور جزوی آؤٹ پٹ کو کامیاب جواب کے طور پر اسٹریم نہیں کرتا۔
اگر ہمیں منظم (structured) آؤٹ پٹ درکار ہو اور پرووائیڈر کا جواب ‘اسکیما ویلیڈیشن’ (schema validation) میں ناکام ہو جائے، تو گیٹ وے 422 Unprocessable Content کا جواب دیتا ہے تاکہ ڈاؤن اسٹریم پارسر (downstream parser) کبھی بھی غیر مصدقہ فیلڈز پر نہ چلے۔
ابتدائی مرحلے میں، انکار کا پہلا مقام گیٹ وے کی تصدیق اور پالیسی کی جانچ ہونا چاہیے—یعنی کوٹہ مختص کرنے اور پرووائیڈر کال سے پہلے—کیونکہ ایک بار جب درخواست باہر کی طرف جانا شروع ہو جائے تو بعد کے مراحل کے پاس وہ معلومات نہیں رہتیں جو اخراجات اور اجازتوں کو t_acme_prod سے منسلک کرنے کے لیے درکار ہوتی ہیں۔