ٹیننٹ (tenant) acme کے لیے ایک سپورٹ چیٹ بوٹ کو ریفنڈ (رقم کی واپسی) کی درخواست موصول ہوتی ہے۔ کال کرنے والا صرف چیٹ کا متن بھیجتا ہے، لیکن assist-api ماڈل کو payments.refund کی درخواست تیار کرنے کی اجازت دیتی ہے اور سروس کے وسیع پیمنٹ کریڈینشلز (ادائیگی کے اختیارات) کا استعمال کرتے ہوئے وہ درخواست بھیج دیتی ہے۔ بیک اینڈ ایک ایسی ریفنڈ تجویز جاری کرتا ہے جسے کرنے کا حق u_123 کے پاس کبھی نہیں تھا۔ اس کے لیے کسی پیچیدہ عمل کی ضرورت نہیں تھی۔ غیر مصدقہ متن کال کرنے والے کے پیغام سے ایک عملی اقدام (action) میں تبدیل ہو گیا، جبکہ ماڈل کے پاس یہ فیصلہ کرنے کا کوئی اختیار نہیں تھا کہ آیا وہ اقدام جائز ہے یا نہیں۔
گارڈ ریل (Guardrail) نفاذ کا وہ مقام ہے جو LLM ایپلی کیشن کے قبول کرنے، خرچ کرنے، واپس کرنے یا عمل درآمد کرنے کے دائرہ کار کو محدود کرتا ہے۔ اس ناکامی کی صورت میں، سب سے سادہ اور مفید گارڈ ریل ریفنڈ کی درخواست کو مسترد کر دے گی جب تک کہ تصدیق شدہ صارف (principal) کے پاس مطلوبہ دائرہ کار (scope) نہ ہو اور سرور کی جانب سے منظوری کا مرحلہ (approval gate) ریفنڈ کے حقیقی پیرامیٹرز کو قبول نہ کر لے۔ پرامپٹ (prompt) کے الفاظ یہ تحفظ فراہم نہیں کر سکتے کیونکہ ماڈل صرف اس متن کی پیروی کرتا ہے جو اس تک پہنچتا ہے؛ یہ نہ تو کال کرنے والوں کی تصدیق کرتا ہے، نہ بجٹ کا انتظام کرتا ہے اور نہ ہی ٹولز (tools) کو استعمال کرنے کی اجازت دیتا ہے۔
چلتے ہوئے سسٹم میں ایک راستہ ایسا ہے جسے ہم تبدیل نہیں کریں گے۔ اینڈ یوزر u_123 کا تعلق ٹیننٹ acme سے ہے اور وہ llm-gateway کے ذریعے assist-api کو کال کرتا ہے۔ FastAPI سروس ایک پرامپٹ تیار کرتی ہے، $CHAT_MODEL کا استعمال کرتے ہوئے chat روٹ پر پرووائیڈر providerA کو کال کرتی ہے، اور ٹول ایکشن کی درخواست کر سکتی ہے۔ u_123 کے پاس chat:invoke اور payments:refund:propose کے اختیارات ہیں، نہ کہ ادائیگی کے لامحدود اختیارات۔
ادائیگی کا معاہدہ (payment contract) محدود اور واضح رہتا ہے۔ ادائیگی کا واحد ٹول payments.refund ہے، جس میں invoice_id (جیسے inv_987)، amount_cents بطور انٹیجر (جیسے 1299)، اور reason بطور سٹرنگ (string) شامل ہیں۔ تجویز کردہ ریفنڈ کا مطلب ریفنڈ پر عمل درآمد کرنے کی اجازت نہیں ہے۔ سرور کسی بھی ناقابلِ واپسی ادائیگی کے عمل کے چلنے سے پہلے ٹیننٹ کی ملکیت، دائرہ کار، دلائل (arguments) اور منظوری کی جانچ کرتا ہے۔
متن پر مشتمل ہر حد (boundary) غیر مصدقہ سمجھی جاتی ہے، بشمول کال کرنے والے کا پیغام، حاصل کردہ دستاویزات، ٹول کے نتائج، اور ماڈل کا آؤٹ پٹ۔ حاصل کردہ سپورٹ دستاویز میں ایسی ہدایات ہو سکتی ہیں جو ایپلی کیشن کی پالیسی سے متصادم ہوں، اور ماڈل کے آؤٹ پٹ میں ایسے فیلڈز ہو سکتے ہیں جو تصدیق (validation) کے بغیر پیمنٹ API کو بھیجے جانے پر غیر محفوظ ہو سکتے ہیں۔ یہ نومبر 2024 میں OWASP GenAI سیکیورٹی پروجیکٹ کی طرف سے شائع کردہ “LLM ایپلی کیشنز 2025 کے لیے OWASP Top 10” میں شامل LLM01 Prompt Injection ہے۔ بنیادی اصول اٹل ہے: کوئی بھی ٹول کال اس سے زیادہ اختیار کے ساتھ نہیں چلائی جا سکتی جتنا اختیار u_123 نے اسے فراہم کیا ہو۔
مقررہ راستہ (fixed path) ناقابلِ اعتماد ان پٹس اور نفاذ کی حدود کو ایک ہی منظر میں یکجا کرتا ہے۔
گیٹ وے (gateway) یہ تعین کرتا ہے کہ کال کس نے کی، جبکہ assist-api صارف کے ٹیننٹ (tenant)، اسکوپس (scopes)، ٹول کنٹریکٹ اور منظوری کی ضرورت کا نفاذ کرتی ہے۔ پرووائیڈر providerA اپنی پرووائیڈر اسناد (credentials) کے تحت آؤٹ پٹ تیار کرتا ہے، لیکن وہ اسناد u_123 کی جانب سے رقم کی واپسی (refund) کا اختیار ہرگز نہیں بن سکتیں۔ کسی ایسے صارف کے لیے سروس کے وسیع تر اختیارات کا استعمال جن کے پاس وہ اختیارات نہیں ہیں، “کنفیوزڈ ڈیپٹی” (confused deputy) کی صورتحال پیدا کرتا ہے۔
حد بندی کا اصول (Boundary rule)
ماڈل
payments.refund(ادائیگی کی واپسی) کی تجویز دے سکتا ہے؛ صرف سرور سائیڈ پر ہونے والی جانچ پڑتال ہی اس کی اجازت دے سکتی ہے یا اسے انجام دے سکتی ہے۔
چونکہ ہر حد (boundary) کا کام مختلف ہوتا ہے، اس لیے انکار کی صورت میں اس مرحلے کی نشاندہی ہونی چاہیے جو محفوظ طریقے سے جاری نہیں رہ سکا۔ llm-gateway غائب، غلط، منسوخ شدہ، یا سمجھوتہ شدہ (compromised) اسناد کے لیے 401 Unauthorized کا جواب دیتا ہے۔ تصدیقِ شناخت (authentication) کے بعد، اگر کال کرنے والے کے پاس مطلوبہ اسکوپ (scope) نہ ہو تو گیٹ وے یا ایپلی کیشن 403 Forbidden کا جواب دیتی ہے۔ ٹول فیچ (tool fetch) کے لیے بلاک شدہ منزل (destination) کی صورت میں بھی 403 Forbidden کا جواب ملتا ہے، اور بلاک شدہ منزل سے کبھی رابطہ نہیں کیا جاتا۔
providerA کے جواب دینے کے بعد، assist-api ماڈل کے آؤٹ پٹ کی توثیق کرتی ہے اس سے پہلے کہ کوئی پارسر (parser)، پیمنٹ API، یا کوئی اور ڈاؤن اسٹریم سنک (downstream sink) اسے وصول کرے۔ اسکیما (schema) کے لحاظ سے غلط آؤٹ پٹ پر 422 Unprocessable Content کا جواب ملتا ہے؛ یہ RFC 9110 کی اصطلاح ہے جسے پرانی دستاویزات میں Unprocessable Entity کہا جاتا ہے۔ مختلف ریفنڈ پیرامیٹرز کے ساتھ آئیڈیمپوٹنسی کی (idempotency key) کا دوبارہ استعمال بھی 422 Unprocessable Content کا نتیجہ دیتا ہے؛ جبکہ پہلی درخواست کے فعال رہنے کے دوران اسی کی (key) کا دوبارہ استعمال 409 Conflict کا جواب دیتا ہے۔
باقی نتائج ماڈل کے فیصلے کے بجائے آپریشنل حد بندی کو بیان کرتے ہیں۔
202 Accepted کا جواب تب ملتا ہے جب ناقابلِ واپسی ریفنڈ کو منظوری کے لیے روکا جاتا ہے، اور ساتھ ہی منظوری کے منتظر ہونے کا شناخت کنندہ (identifier) بھی فراہم کیا جاتا ہے۔429 Too Many Requests (مع Retry-After) کا جواب تب ملتا ہے جب مشترکہ کوٹہ یا ریٹ لمیٹ (rate limit) ختم ہو جائے۔503 Service Unavailable کا جواب تب ملتا ہے جب نفاذ کا اسٹور (enforcement store) دستیاب نہ ہو اور ایپلی کیشن محفوظ طریقے سے پالیسی کا نفاذ نہ کر سکے۔504 Gateway Timeout کا جواب تب ملتا ہے جب providerA پرووائیڈر کال کے ٹائم آؤٹ (timeout) کی حد سے تجاوز کر جائے۔یہ نتائج کلائنٹس کو اس بات سے روکتے ہیں کہ وہ انکار کو ماڈل کی کسی مبہم ناکامی کے طور پر سمجھیں۔ یہ اس بات کی بھی نشاندہی کرتے ہیں کہ کہاں تحقیق کی جائے؛ آیا غائب کنٹرول llm-gateway پر شناخت کا معاملہ ہے، assist-api میں توثیق کا، یا پھر کسی ایسی پرووائیڈر کال کا جو مکمل نہیں ہو سکی۔
ابتدائی ناکامی میں، حملہ آور کے پاس صرف ایک چیٹ میسج ہوتا ہے لیکن وہ ناقابلِ واپسی ریفنڈ کی تجویز کا سبب بنتا ہے۔ کس مرحلے پر سب سے پہلے انکار (refusal) کیا جانا چاہیے: A، llm-gateway پر کالر کی تصدیق اور ٹیننٹ بائنڈنگ (tenant binding)؛ B، assist-api پر ٹول کی اجازت اور منظوری؛ یا C، ماڈل کے بعد آؤٹ پٹ کی جانچ پڑتال؟
[ذرائع][/ذرائع]