سپورٹ چیٹ (support chat) اس وقت رقم کی منتقلی کے عمل میں تبدیل ہو سکتی ہے جب FastAPI کا بیک اینڈ ماڈل کے آؤٹ پٹ کو حتمی اختیار (authority) کے طور پر قبول کر لے۔
اس کورس میں زیرِ بحث خرابی (failure) کے منظرنامے میں، ایک کالر ایپ POST /v1/chat پر ایک عام سا نظر آنے والا پیغام بھیجتی ہے، FastAPI سروس اس متن کو ماڈل فراہم کرنے والے (model provider) کو بھیجتی ہے، اور ماڈل ایک ایسی ‘ٹول انسٹرکشن’ (tool instruction) واپس کرتا ہے جو رقم کی واپسی (refund) کی درخواست سے مشابہت رکھتی ہے۔
بیک اینڈ ماڈل کی تجویز کردہ ‘ٹول کال’ (tool call) کو فوراً انجام دیتا ہے، بغیر اس بات کی جانچ کیے کہ آیا آخری صارف (end user) کو وہ عمل کرنے کی اجازت ہے یا نہیں، اور بغیر ماڈل کے آؤٹ پٹ کو ناقابلِ اعتماد متن سمجھے۔
اس خرابی کے لیے کسی غیر معمولی چیز کی ضرورت نہیں ہے۔ بیک اینڈ بالکل وہی کام کرتا ہے جس کے لیے اسے بنایا گیا تھا، لیکن یہ سب سے زیادہ اختیارات والا مرحلہ—یعنی ٹول کا عمل—ایک ایسے اسٹرنگ (string) کی بنیاد پر چلاتا ہے جو ‘اعتماد کی حد’ (trust boundary) کے باہر سے آیا ہے۔
جب ناقابلِ واپسی عمل (irreversible action) پہلے ہی انجام پا چکا ہو، تو بعد میں آنے والا کوئی بھی فلٹر اس کے ضمنی اثر (side effect) کو ختم نہیں کر سکتا؛ لہٰذا ہمیں یہ طے کرنا ہوگا کہ پہلا مؤثر روک تھام کا مقام (effective stop) کہاں ہونا چاہیے۔
ایک ہی درخواست کئی حدود کو عبور کرتی ہے جہاں ناقابلِ اعتماد متن اخراجات یا ضمنی اثرات میں تبدیل ہو جاتا ہے، اور یہ کورس اسی ایک راستے پر مرکوز رہتا ہے تاکہ ہر کنٹرول (control) اپنی مخصوص جگہ پر قائم رہے۔
ناقابلِ اعتماد متن تین جگہوں سے داخل ہوتا ہے، تب بھی جب کالر درست رویہ اختیار کر رہا ہو۔ کالر کا پیغام HTTP درخواست کے ذریعے آتا ہے، حاصل کردہ دستاویزات بیک اینڈ کے اپنے ڈیٹا اسٹورز سے آتی ہیں، اور ٹول کے نتائج دوسرے سسٹمز سے واپس آتے ہیں جو غلط یا نقصان دہ (hostile) ہو سکتے ہیں۔
رقم اور ڈیٹا کا استعمال دو مقامات پر ہو سکتا ہے۔ ماڈل فراہم کرنے والے کو کی جانے والی کال ٹوکنز اور لاگت کا استعمال کرتی ہے، اور ٹول کا عمل (execution) ایسے حقیقی وسائل کو پڑھ یا تبدیل کر سکتا ہے جن کا مالک صارف نہ ہو۔
نفاذ کے واحد قابلِ اعتماد مقامات (enforcement points) FastAPI سروس میں ان اخراجاتی مقامات کے گرد موجود ‘سرور سائیڈ چیکس’ ہیں۔ یہ کورس تصدیقِ شناخت (authentication)، ٹیننٹ بائنڈنگ (tenant binding)، کوٹاز (quotas)، ان پٹ اور آؤٹ پٹ فلٹرز، ٹول کی اجازت (authorization)، سینڈ باکسنگ (sandboxing)، اور آڈٹ لاگنگ کو واضح ‘گیٹس’ (gates) کے طور پر تشکیل دیتا ہے؛ پرامپٹ (prompt) کے الفاظ ان میں سے کسی کا بھی نفاذ نہیں کر سکتے کیونکہ سسٹم پرامپٹ پڑھنے کے قابل ہوتا ہے اور ماڈل صرف متن کی پیروی کرتا ہے۔
نیچے دیا گیا خاکہ اس واحد درخواست کے راستے پر ہر ناقابلِ اعتماد ان پٹ اور نفاذ کے ہر مقام کی نشاندہی کرتا ہے جسے ہم مسلسل بڑھا رہے ہیں۔ آئیے اس بات کا تعین کریں کہ متن کہاں اختیار (authority) بن جاتا ہے اور ہم کہاں انکار کر سکتے ہیں۔
یہ خاکہ ایک اصول کو واضح کرتا ہے۔ متن لے جانے والا ہر تیر (arrow) ناقابلِ اعتماد ہے، اور صرف ہماری سروس میں موجود خانے ہی درخواست کو مسترد، محدود، توثیق، مجاز اور ریکارڈ کر سکتے ہیں۔
ایک محفوظ API معاہدے کے لیے مستقل ‘انکار کے کوڈز’ (refusal codes) کی ضرورت ہوتی ہے، کیونکہ جب کوئی گیٹ (gate) درخواست کو مسترد کرتا ہے تو کلائنٹس اور ڈیبگنگ (debugging) دونوں ہی متوقع نتائج پر انحصار کرتے ہیں۔
ہم انکار کے نقشے کو ایک بار بیان کرتے ہیں اور پھر اسے دوبارہ استعمال کرتے ہیں، اور ہر انکار کو ماڈل کے بجائے اس حد (boundary) سے منسلک کرتے ہیں جو اسے نافذ کرتی ہے۔
401 Unauthorized: کال کرنے والے کے غائب، غلط، منسوخ شدہ، یا سمجھوتہ شدہ (compromised) اسناد (credentials) کو مسترد کرتا ہے؛ سروس کوٹہ خرچ کرنے یا فراہم کنندہ (provider) کو کال کرنے سے پہلے ہی یہ جواب واپس بھیج دیتی ہے۔403 Forbidden: تصدیق شدہ کالر کو اس کے مجاز دائرہ کار سے باہر ہونے پر مسترد کرتا ہے (بشمول مسترد شدہ یا میعاد ختم ہونے والی منظوری)؛ یہ ایسے ‘ٹول فیچ’ (tool fetch) کو بھی مسترد کرتا ہے جو کسی مسدود منزل (blocked destination) کے لیے ہو جس سے کبھی رابطہ نہیں کیا جانا چاہیے۔422 Unprocessable Content (RFC 9110): ماڈل کے اس آؤٹ پٹ کو مسترد کرتا ہے جو ‘اسکیما ویلیڈیشن’ (schema validation) میں ناکام ہو جائے، کیونکہ غیر تصدیق شدہ آؤٹ پٹ محض متن ہوتا ہے جب تک کہ سرور یہ ثابت نہ کر دے کہ یہ ٹول کے معاہدے سے مطابقت رکھتا ہے۔429 Too Many Requests (مع Retry-After): شرح کی حد (rate limit) یا کوٹہ ختم ہونے پر مسترد کرتا ہے؛ اس کے لیے کاؤنٹر کا مشترکہ ہونا ضروری ہے تاکہ ریپلیکاز (replicas) خاموشی سے حد میں اضافہ نہ کر دیں۔503 Service Unavailable: اس وقت مسترد کرتا ہے جب کوٹہ کاؤنٹر اسٹور بند ہو یا ‘اوپن سرکٹ بریکر’ نفاذ میں رکاوٹ بنے، کیونکہ سروس محفوظ طریقے سے یہ فیصلہ نہیں کر سکتی کہ آیا خرچ کی اجازت ہے۔504 Gateway Timeout: اس وقت مسترد کرتا ہے جب فراہم کنندہ (provider) کو کی جانے والی کال سروس کے ٹائم آؤٹ سے تجاوز کر جائے، کیونکہ معلق (hanging) کالز لامحدود وسائل کے استعمال کا باعث بنتی ہیں۔کورس کو عملی اور ٹھوس رکھنے کے لیے، ہم ایک فعال آرٹیفیکٹ (artifact) تیار کرتے ہیں اور اسے مرحلہ وار مضبوط بناتے ہیں۔ یہ آرٹیفیکٹ ایک ‘ٹیننٹ سے آگاہ’ (tenant-aware) POST /v1/chat روٹ ہے جو صرف ایک ٹول کو کال کر سکتا ہے، اور بعد کا ہر سبق اس راستے پر ایک نیا گیٹ (gate) شامل کرتا ہے۔
ابتدائی ناکامی کی صورت میں، کالر جائز بھی ہو سکتا ہے؛ اس کا مطلب ہے کہ تصدیق (authentication) تو کامیاب ہو سکتی ہے لیکن درخواست پھر بھی کسی غیر مجاز ٹول ایکشن (tool action) کا باعث بن سکتی ہے۔
اگر سروس ٹول کال کو انجام دینے کے بعد ماڈل کے آؤٹ پٹ کی توثیق کا انتظار کرتی ہے، تو ‘اسکیما ویلیڈیشن’ خراب ساخت والے پے لوڈ (malformed payload) کو تو مسترد کر سکتی ہے، لیکن وہ ایسے بظاہر درست عمل کو واپس نہیں کر سکتی جس کی اجازت کبھی نہیں دی جانی چاہیے تھی۔ اہم فیصلہ یہ ہے کہ ٹول (tool) کا کوئی ایسا عمل انجام پانے سے پہلے، جسے پلٹا نہ جا سکے، کس مرحلے پر اسے روکا جا سکتا ہے۔ ناکامی کو روکنے والا سب سے پہلا مرحلہ کون سا ہے: تصدیقِ شناخت (authentication)، ٹول کے استعمال کی اجازت (authorization)، یا آؤٹ پٹ کی جانچ پڑتال (validation)؟