Ledgerline کسی ملازم کی سپورٹ کی درخواست کو ایک اسسٹنٹ API، ماڈل فراہم کنندہ، اور ریفنڈ ٹول کے ذریعے آگے بڑھاتا ہے۔ ایک Jira ٹکٹ میں گاہک کو ریفنڈ دینے کی درخواست پر مبنی متن موجود تھا؛ اسسٹنٹ نے اس متن کو ایک ہدایت کے طور پر لیا، اور پھر ٹول ایگزیکیوٹر (tool executor) نے اسے جاری کرنے کے لیے ادائیگی کی مشترکہ سروس کا اکاؤنٹ استعمال کیا۔ درخواست دہندہ کے پاس ریفنڈ کی اجازت نہیں تھی، لیکن بیک اینڈ نے عمل درآمد کے وقت درخواست دہندہ کی تصدیق نہیں کی۔ اس کے لیے کسی میلویئر یا چوری شدہ اسناد (credentials) کی ضرورت نہیں پڑی۔ ٹکٹ کا غیر مصدقہ متن ایجنٹ کے عمل (loop) میں داخل ہوا اور ایک ایسے خصوصی اختیار والے آپریشن تک پہنچ گیا جسے ایپلی کیشن نے پہلے ہی دستیاب کر رکھا تھا۔
یہ ناکامی پرامپٹ انجیکشن (جہاں غیر مصدقہ متن ایپلی کیشن کے ماڈل پر مبنی رویے کو تبدیل کر دیتا ہے) اور ضرورت سے زیادہ اختیار (جہاں ایپلی کیشن اس رویے کو اصل ملازم کے حقوق سے بڑھ کر اختیار دے دیتی ہے) کا مجموعہ ہے۔ OWASP اپنی 2025 کی رہنمائی میں، جسے نومبر 2024 میں OWASP GenAI سیکیورٹی پروجیکٹ نے شائع کیا تھا، انہیں LLM01 پرامپٹ انجیکشن اور LLM06 Excessive Agency کا نام دیتا ہے۔ پرامپٹ کے الفاظ ریفنڈ کی اجازت نہیں دے سکتے کیونکہ ماڈل صرف متن تیار کرتا ہے؛ سرور یہ فیصلہ کرتا ہے کہ آیا ادائیگی کا عمل چلایا جائے یا نہیں۔
ریفنڈ اس لیے منظور ہو گیا کیونکہ Ledgerline نے ایک درخواست کو اعتماد کی کئی حدود (trust boundaries) عبور کرنے کی اجازت دی، بغیر اس بات کا ریکارڈ رکھے کہ اسے کس نے شروع کیا تھا۔ ملازم کا پیغام غیر مصدقہ ہوتا ہے۔ حاصل کردہ سپورٹ دستاویز بھی غیر مصدقہ ہوتی ہے، چاہے اسے Ledgerline نے ہی کیوں نہ محفوظ کیا ہو۔ ٹول کا نتیجہ اگلی ماڈل کال کے لیے ایک غیر مصدقہ ان پٹ ہوتا ہے۔ ماڈل کا آؤٹ پٹ بھی غیر مصدقہ ہوتا ہے، کیونکہ مجوزہ ریفنڈ کا عمل اس بات کا ثبوت نہیں ہے کہ ملازم اسے انجام دینے کا مجاز ہے۔
اسسٹنٹ API پرامپٹ تیار کرنے سے پہلے ملازم کی تصدیق کرتا ہے۔ دستاویز کا متن پرامپٹ میں شامل ہونے سے پہلے، دستاویزات تک رسائی کا اختیار (retrieval authorization) انہیں ملازم کے ٹیننٹ (tenant) اور استحقاق (entitlements) تک محدود کر دیتا ہے۔ ٹول ایگزیکیوٹر تصدیق شدہ صارف (principal) اور مطلوبہ پیرامیٹرز وصول کرتا ہے، اور پھر ادائیگی کے نظام سے رابطہ کرنے سے پہلے عمل کی پالیسی (action policy) کا نفاذ کرتا ہے۔ آڈٹ لاگ صارف، مطلوبہ عمل، فیصلے اور نتیجے کو ریکارڈ کرتا ہے۔ ماڈل فراہم کنندہ عمل کی تجویز (candidate action) تو تیار کرتا ہے، لیکن کبھی اجازت نہیں دیتا۔ درخواست کا راستہ ہر حد کو نمایاں کرتا ہے:
یہ طریقہ کار ٹیکسٹ پروسیسنگ کو اختیار (authority) سے الگ کرتا ہے۔ تصدیق (authentication) کسی نامعلوم کالر کو مسترد کر سکتی ہے، ڈیٹا کی بازیافت (retrieval) کسی غیر مجاز کسٹمر کا ریکارڈ روک سکتی ہے، اور ٹول گیٹ ریفنڈ سے انکار کر سکتا ہے حالانکہ ماڈل اس کی پرزور سفارش کر رہا ہو۔ آڈٹ ریکارڈ اس عمل کو روک تو نہیں سکتا، لیکن یہ Ledgerline کو یہ تعین کرنے کے قابل بناتا ہے کہ کس پرنسپل (صارف/ایجنٹ)، پالیسی فیصلے اور پیرامیٹرز کے نتیجے میں یہ نتیجہ برآمد ہوا۔
چونکہ ہر باؤنڈری (حد) ایک مختلف قسم کی ناکامی کو مسترد کرتی ہے، اس لیے Ledgerline ہر انکار کو ماڈل کی خرابی (error) سمجھنے کے بجائے ایک مستقل اسٹیٹس کنٹریکٹ (status contract) واپس کرتی ہے۔ 401 Unauthorized کا مطلب ہے کہ درخواست میں اسناد (credentials) غائب ہیں، غلط ہیں، منسوخ شدہ ہیں یا سمجھوتہ شدہ (compromised) ہیں۔ 403 Forbidden کا مطلب ہے کہ تصدیق شدہ ملازم کے پاس مطلوبہ دائرہ اختیار (scope) نہیں ہے، مثلاً ریفنڈ کے اختیار کے بغیر ریفنڈ کی درخواست کرنا یا ملازم کے استحقاق سے باہر ڈیٹا بازیافت کرنے کی کوشش کرنا۔
دیگر مراحل زیادہ مخصوص نتائج استعمال کرتے ہیں:
409 Conflict کا مطلب ہے کہ ‘آئیڈیمپوٹنسی کی’ (idempotency key) استعمال کرنے والی پہلی درخواست ابھی بھی جاری ہے۔422 Unprocessable Content کا مطلب ہے کہ ماڈل کا آؤٹ پٹ Ledgerline کے مطلوبہ ایکشن اسکیما (action schema) پر پورا نہیں اترا، یا ‘آئیڈیمپوٹنسی کی’ کو مختلف پیرامیٹرز کے ساتھ دوبارہ استعمال کیا گیا۔429 Too Many Requests (مع Retry-After) کا مطلب ہے کہ ٹیننٹ (tenant) نے ریٹ یا اخراجات کی حد ختم کر دی ہے۔503 Service Unavailable کا مطلب ہے کہ Ledgerline مطلوبہ کاؤنٹر کو نافذ نہیں کر سکتی یا ‘اوپن سرکٹ بریکر’ فراہم کنندہ (provider) کی کال کو روک رہا ہے۔504 Gateway Timeout کا مطلب ہے کہ ماڈل فراہم کنندہ نے Ledgerline کی مقررہ ڈیڈ لائن سے تجاوز کر لیا ہے۔اسٹیٹس کوڈ اس باؤنڈری کی نشاندہی کرتا ہے جس نے فیصلہ کیا ہے۔ اگر پرامپٹ (prompt) کی تیاری سے پہلے کسٹمر کی تلاش (lookup) سے انکار کیا جاتا ہے، تو Ledgerline 403 Forbidden واپس کرتی ہے؛ کوئی بھی بازیافت شدہ دستاویز فراہم کنندہ تک نہیں پہنچتی۔ اگر مجوزہ ریفنڈ کے پیرامیٹرز غلط ہیں، تو سرور ٹول ایگزیکیوٹر کے ادائیگیوں کے نظام سے رابطہ کرنے سے پہلے 422 Unprocessable Content واپس کرتا ہے۔ یہ نتائج انکار کو سسٹم پرامپٹ میں موجود محض ایک جملے کے بجائے بیک اینڈ کے قابلِ مشاہدہ رویے میں تبدیل کر دیتے ہیں۔
اختیار کا اصول (Authority rule) مشترکہ سروس کی شناخت (shared service identity) درخواست کو منتقل کر سکتی ہے، لیکن اسے اس ملازم پرنسپل کی جگہ نہیں لینی چاہیے جسے عمل کی اجازت دینے کے لیے استعمال کیا گیا تھا۔
ابتدائی واقعہ ایک “کنفیوزڈ ڈپٹی” (confused deputy) کی صورتِ حال ہے۔ Ledgerline کے ریفنڈ ایگزیکیوٹر (refund executor) کے پاس وسیع سروس اتھارٹی تھی اور اس نے یہ اختیار ایسے ملازم کے لیے استعمال کیا جس کے پاس متعلقہ اجازت (permission) موجود نہیں تھی۔ اگرچہ Payments API اب بھی Ledgerline کے سروس کریڈینشل کی توثیق کر سکتا ہے، لیکن یہ ملازم کے اس “حق” (entitlement) کی تلافی نہیں کر سکتا جو اس کے پاس موجود نہیں تھا، الا یہ کہ Ledgerline خود اس “پرنسپل” (صارف کی شناخت/اختیار) کو ساتھ لے کر چلے اور اس کی جانچ کرے۔ کنٹرول کو “پرامپٹ اسمبلی” (prompt assembly) کے مرحلے پر منتقل کرنے سے بعد میں آنے والے متن، ٹول کے نتائج اور ماڈل کی آؤٹ پٹ کو اس بات کا موقع مل جاتا ہے کہ وہ مجوزہ کارروائی میں تبدیلی کر سکیں۔
نفاذ کا قابلِ اعتماد مقام (boundary) سرور سائیڈ پر موجود “ٹول ہینڈلر” (tool handler) ہے، جہاں Ledgerline کے پاس فیصلے کے لیے درکار دونوں حقائق موجود ہوتے ہیں: تصدیق شدہ ملازم کا “پرنسپل” (شناخت) اور ریفنڈ کے ٹھوس پیرامیٹرز۔ پرامپٹ کے اصول ماڈل کے رویے کی رہنمائی کر سکتے ہیں اور فراہم کنندہ (provider) ممکنہ ٹول کال واپس بھیج سکتا ہے، لیکن ان میں سے کوئی بھی طریقہ کار Ledgerline کی اجازت کی پالیسی (authorization policy) کا نفاذ نہیں کرتا۔ Jira-ٹکٹ کے ریفنڈ کو کس مرحلے پر سب سے پہلے روکا جانا چاہیے: پرامپٹ کے اصول، ماڈل، ٹول ہینڈلر، یا Payments API؟