Ledgerline एक कर्मचारी के सपोर्ट अनुरोध को असिस्टेंट API, मॉडल प्रोवाइडर और रिफंड टूल के ज़रिए भेजता है। एक Jira टिकट में कस्टमर रिफंड का अनुरोध करने वाला टेक्स्ट था; असिस्टेंट ने उस टेक्स्ट को एक निर्देश माना, फिर टूल एक्ज़ीक्यूटर ने इसे जारी करने के लिए एक शेयर्ड पेमेंट सर्विस अकाउंट का इस्तेमाल किया। अनुरोध करने वाले के पास रिफंड की अनुमति नहीं थी, लेकिन बैकएंड ने कभी भी कार्रवाई के समय अनुरोध करने वाले की जाँच नहीं की। किसी मैलवेयर या चोरी किए गए क्रेडेंशियल की ज़रूरत नहीं थी। अविश्वसनीय टिकट टेक्स्ट एजेंट लूप में दाखिल हुआ और एक ऐसे विशेषाधिकार प्राप्त ऑपरेशन तक पहुँचा जिसे एप्लिकेशन ने पहले ही उपलब्ध कराया था।
यह विफलता प्रॉम्प्ट इंजेक्शन (जहाँ अविश्वसनीय टेक्स्ट एप्लिकेशन के मॉडल-निर्देशित व्यवहार को बदल देता है) और एक्सेसिव एजेंसी (जहाँ एप्लिकेशन उस व्यवहार को मूल कर्मचारी के अधिकारों से परे अधिकार देता है) का मिश्रण है। OWASP नवंबर 2024 में OWASP GenAI सिक्योरिटी प्रोजेक्ट द्वारा प्रकाशित अपनी 2025 गाइडेंस में इन्हें LLM01 प्रॉम्प्ट इंजेक्शन और LLM06 एक्सेसिव एजेंसी कहता है। प्रॉम्प्ट की शब्दावली रिफंड को अधिकृत नहीं कर सकती क्योंकि मॉडल केवल टेक्स्ट बनाता है; सर्वर तय करता है कि पेमेंट की कार्रवाई होगी या नहीं।
रिफंड इसलिए मंज़ूर हो गया क्योंकि Ledgerline ने एक अनुरोध को कई ट्रस्ट बाउंड्री पार करने की अनुमति दी, बिना यह रिकॉर्ड किए कि इसे किसने शुरू किया था। कर्मचारी का संदेश अविश्वसनीय होता है। रिट्रीव किया गया सपोर्ट डॉक्यूमेंट अविश्वसनीय होता है, भले ही Ledgerline ने उसे स्टोर किया हो। टूल का परिणाम अगले मॉडल कॉल के लिए अविश्वसनीय इनपुट होता है। मॉडल का आउटपुट भी अविश्वसनीय होता है, क्योंकि प्रस्तावित रिफंड कार्रवाई इस बात का सबूत नहीं है कि कर्मचारी इसे कर सकता है।
असिस्टेंट API प्रॉम्प्ट बनाने से पहले कर्मचारी को प्रमाणित करता है। रिट्रीवल ऑथराइज़ेशन डॉक्यूमेंट टेक्स्ट के प्रॉम्प्ट में शामिल होने से पहले डॉक्यूमेंट को कर्मचारी के टेनेंट और अधिकारों तक सीमित करता है। टूल एक्ज़ीक्यूटर प्रमाणित प्रिंसिपल और अनुरोधित पैरामीटर प्राप्त करता है, फिर पेमेंट सिस्टम से संपर्क करने से पहले कार्रवाई नीति लागू करता है। ऑडिट लॉग प्रिंसिपल, अनुरोधित कार्रवाई, निर्णय और परिणाम को रिकॉर्ड करता है। मॉडल प्रोवाइडर एक संभावित कार्रवाई बनाता है, लेकिन कभी भी अनुमति नहीं देता है। रिक्वेस्ट पाथ हर बाउंड्री को दिखाई देने लायक बनाता है:
यह तरीका टेक्स्ट प्रोसेसिंग को अथॉरिटी (अधिकार) से अलग करता है। ऑथेंटिकेशन किसी अनजान कॉलर को रिजेक्ट कर सकता है, रिट्रीवल किसी अनऑथराइज़्ड कस्टमर रिकॉर्ड को रोक सकता है, और टूल गेट रिफंड देने से मना कर सकता है, भले ही मॉडल ने इसकी ज़ोरदार सिफारिश की हो। ऑडिट रिकॉर्ड इस कार्रवाई को रोक नहीं सकता, लेकिन यह Ledgerline को यह पता लगाने में मदद करता है कि किस प्रिंसिपल, पॉलिसी फ़ैसले और पैरामीटर के कारण यह नतीजा निकला।
क्योंकि हर बाउंड्री अलग-अलग तरह की विफलता को रिजेक्ट करती है, इसलिए Ledgerline हर इनकार को मॉडल की गलती मानने के बजाय एक स्टेबल स्टेटस कॉन्ट्रैक्ट देता है। 401 Unauthorized का मतलब है कि रिक्वेस्ट में क्रेडेंशियल गायब है, अमान्य है, रद्द कर दिया गया है या कॉम्प्रोमाइज़्ड (सुरक्षित नहीं) है। 403 Forbidden का मतलब है कि ऑथेंटिकेटेड कर्मचारी के पास ज़रूरी स्कोप नहीं है, जैसे कि रिफंड अथॉरिटी के बिना रिफंड की रिक्वेस्ट करना या कर्मचारी के अधिकार क्षेत्र से बाहर जानकारी निकालने की कोशिश करना।
दूसरे स्टेज ज़्यादा सटीक नतीजों का इस्तेमाल करते हैं:
409 Conflict का मतलब है कि आइडेंपोटेंसी की (idempotency key) का इस्तेमाल करने वाली पहली रिक्वेस्ट अभी भी चल रही है।422 Unprocessable Content का मतलब है कि मॉडल का आउटपुट Ledgerline के ज़रूरी एक्शन स्कीमा पर खरा नहीं उतरा, या अलग-अलग पैरामीटर के साथ आइडेंपोटेंसी की का दोबारा इस्तेमाल किया गया।429 Too Many Requests के साथ Retry-After का मतलब है कि टेनेंट ने रेट या खर्च की सीमा खत्म कर दी है।503 Service Unavailable का मतलब है कि Ledgerline ज़रूरी काउंटर लागू नहीं कर सकता या ओपन सर्किट ब्रेकर प्रोवाइडर कॉल को रोक रहा है।504 Gateway Timeout का मतलब है कि मॉडल प्रोवाइडर ने Ledgerline की समय-सीमा पार कर ली है।स्टेटस कोड उस बाउंड्री की पहचान करता है जिसने फ़ैसला लिया। अगर प्रॉम्प्ट असेंबली से पहले कस्टमर लुकअप से इनकार किया जाता है, तो Ledgerline 403 Forbidden देता है; कोई भी निकाला गया डॉक्यूमेंट प्रोवाइडर तक नहीं पहुँचता। अगर प्रस्तावित रिफंड में गलत पैरामीटर हैं, तो टूल एग्जीक्यूटर के पेमेंट से संपर्क करने से पहले सर्वर 422 Unprocessable Content देता है। ये नतीजे इनकार को सिस्टम प्रॉम्प्ट में लिखे एक वाक्य के बजाय, बैकएंड के देखे जा सकने वाले व्यवहार में बदल देते हैं।
अथॉरिटी नियम एक शेयर्ड सर्विस आइडेंटिटी रिक्वेस्ट को ले जा सकती है, लेकिन यह उस कर्मचारी प्रिंसिपल की जगह नहीं ले सकती जिसका इस्तेमाल कार्रवाई को ऑथराइज़ करने के लिए किया गया था।
शुरुआती घटना एक ‘कन्फ्यूज्ड डेप्युटी’ (confused deputy) की है। Ledgerline के रिफंड एग्जीक्यूटर के पास व्यापक सर्विस अथॉरिटी थी और उसने उस अथॉरिटी का इस्तेमाल ऐसे कर्मचारी के लिए किया जिसके पास संबंधित परमिशन नहीं थी। पेमेंट्स API भले ही Ledgerline के सर्विस क्रेडेंशियल को वैलिडेट कर ले, लेकिन वह कर्मचारी के उस अधिकार (entitlement) को वापस नहीं ला सकता जो उसके पास नहीं था, जब तक कि Ledgerline उस ‘प्रिंसिपल’ (अधिकार-प्राप्त पहचान) को साथ न रखे और उसकी जांच न करे। कंट्रोल को प्रॉम्प्ट असेंबली के शुरुआती चरण में ले जाने से बाद के टेक्स्ट, टूल के नतीजों और मॉडल के आउटपुट को प्रस्तावित कार्रवाई में बदलाव करने की गुंजाइश मिल जाती है।
लागू करने का भरोसेमंद दायरा सर्वर-साइड टूल हैंडलर है, जहां Ledgerline के पास निर्णय लेने के लिए ज़रूरी दोनों तथ्य मौजूद होते हैं: ऑथेंटिकेटेड कर्मचारी की पहचान (प्रिंसिपल) और रिफंड के ठोस पैरामीटर। प्रॉम्प्ट नियम मॉडल के व्यवहार को गाइड कर सकते हैं और प्रोवाइडर एक संभावित टूल कॉल लौटा सकता है, लेकिन इनमें से कोई भी तरीका Ledgerline की ऑथराइजेशन पॉलिसी को लागू नहीं करता है। Jira-टिकट रिफंड को किस चरण पर सबसे पहले रोकना चाहिए: प्रॉम्प्ट नियम, मॉडल, टूल हैंडलर, या पेमेंट्स API?