आपका AI-संचालित सहायक लगभग 99% समय अपने निर्देशों का पालन करता है, लेकिन वह छूटा हुआ 1% ही वह जगह है जहाँ हमलावर वार करते हैं। एक तैयार किया गया प्रॉम्प्ट (crafted prompt) देकर, एक दुर्भावनापूर्ण उपयोगकर्ता मॉडल को ऐसे फंक्शन चलाने के लिए मजबूर कर सकता है जिन्हें उसे नहीं चलाना चाहिए, जिससे डेटा चोरी हो सकता है या विशेषाधिकार प्राप्त (privileged) कार्य किए जा सकते हैं। इसका समाधान अधिक विनम्र शब्दों का उपयोग करना नहीं है—बल्कि इस खामी को एक ऑथोराइजेशन (authorization) समस्या के रूप में देखना और मॉडल की पहुँच से खतरनाक टूल्स को हटाना है।
प्रॉम्प्ट इंजेक्शन केवल शब्दों की समस्या क्यों नहीं है
डेवलपर्स अक्सर एजेंटों को बड़े अक्षरों (all-caps) वाली चेतावनियों, क्रमांकित नियमों, या "एडमिन फंक्शन कॉल न करें" जैसे क्लॉज़ के साथ सुरक्षित करने की कोशिश करते हैं। ये बचाव इस धारणा पर आधारित हैं कि मॉडल उस वाक्य का पालन करेगा जो कहता है "X न करें।" व्यवहार में, अनुरोध को फिर से लिखकर, एक अलग व्यक्तित्व (persona) निभाकर, या बस अतिरिक्त संदर्भ जोड़कर मॉडल को निर्देश की अनदेखी करने के लिए उकसाया जा सकता है। अंग्रेजी की सीमा पर बातचीत की जा सकती है; हमलावर का प्रॉम्प्ट असीमित है और इसे टेस्ट करने में कुछ भी खर्च नहीं होता।
असली भेद्यता (vulnerability) उस टूल लिस्ट में निहित है जो एजेंट को प्राप्त होती है। जब प्रॉम्प्ट स्कीमा में ऐसा फंक्शन शामिल होता है जो एडमिन अधिकार देता है, तो मॉडल के पास उस शक्ति का एक नक्शा आ जाता है। भले ही प्रॉम्प्ट में कहा जाए कि "ग्राहकों के लिए इसका उपयोग न करें," मॉडल को फिर भी इसे कॉल करने के लिए मनाया जा सकता है क्योंकि यह फंक्शन उसके निष्पादन वातावरण (execution environment) में मौजूद है। इसलिए समस्या एक ऑथोराइजेशन गैप (authorization gap) है: सिस्टम एक ऐसे कॉलर को विशेषाधिकार प्राप्त क्षमताएं दिखा रहा है जिसे उनका कोई अधिकार नहीं है।
एक्सपोज़र को सीमित करके एजेंटों को सुरक्षित करना
इस अंतर को पाटने का सबसे सरल तरीका मॉडल को उन टूल्स तक पहुँच देना बंद करना है जिनका उपयोग करने के लिए वह अधिकृत (authorized) नहीं है। टूल लिस्ट को एक API की (key) की तरह समझें: यदि की मौजूद नहीं है, तो कॉल नहीं हो सकती। कोई भी चतुर शब्द उस फंक्शन को नहीं बुला सकता जो वर्तमान संदर्भ (context) में नहीं है।
गलत तरीका
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
मॉडल अभी भी अपने टूलबॉक्स में adminDeleteUser देखता है और उसे कॉल करने के लिए छल किया जा सकता है।
सही तरीका
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser कभी दिखाई ही नहीं देता, इसलिए मॉडल के पास इसे कॉल करने का कोई रास्ता नहीं होता।
डेवलपर्स के लिए तीन व्यावहारिक नियम
- प्रत्येक अनुरोध के अनुसार टूल लिस्ट बनाएं – प्रमाणित कॉलर की अनुमतियों (permissions) के आधार पर फंक्शन कैटलॉग को गतिशील रूप से (dynamically) जेनरेट करें। एक ग्राहक केवल वही फंक्शन देखता है जिनकी उसे आवश्यकता है; एक एडमिन पूरा सेट देखता है।
- फेल क्लोज्ड (Fail closed) रखें – यदि उपयोगकर्ता की पहचान सत्यापित नहीं की जा सकती है, तो सामान्य "सभी टूल्स उपलब्ध हैं" जैसे विकल्प के बजाय एक खाली लिस्ट लौटाएं। यह सुनिश्चित करता है कि एक अन-ऑथेंटिकेटेड अनुरोध कभी भी अप्रत्याशित शक्ति प्राप्त न कर सके।
- शेयर्ड स्टेट (shared state) से बचें – टूल डेफिनिशन को कैश करते समय, कभी भी यूजर-विशिष्ट डेटा को किसी शेयर्ड ऑब्जेक्ट पर न लिखें। copy-on-write या प्रति-सेशन (per-session) कॉपियों का उपयोग करें ताकि एक उपयोगकर्ता की अनुमतियाँ दूसरे के अनुरोध में न मिलें।
यदि एक सामान्य उपयोगकर्ता को प्रस्तुत किया गया स्कीमा एडमिन को दिखाए गए स्कीमा के समान दिखता है, तो सुरक्षा सीमा अभी भी प्रॉम्प्ट टेक्स्ट ही है, और प्रॉम्प्ट एक विश्वसनीय सुरक्षा तंत्र नहीं हैं।
हमें यहाँ तक क्या लेकर आया
प्रॉम्प्ट इंजेक्शन तब सामने आया जब डेवलपर्स ने लार्ज लैंग्वेज मॉडल्स (LLMs) को प्रोडक्शन वर्कफ़्लो में जोड़ना शुरू किया, जिसमें मॉडल को बाहरी APIs को कॉल करने, कोड चलाने या डेटाबेस को संशोधित करने की आवश्यकता थी। मॉडल का "तर्क" (reasoning) एक प्रॉम्प्ट द्वारा निर्देशित होता है जिसमें उपलब्ध टूल्स की सूची भी शामिल होती है। शुरुआती प्रोटोटाइप ने यह मान लिया था कि मॉडल "गैर-एडमिन के लिए रिकॉर्ड डिलीट न करें" जैसे प्राकृतिक भाषा के नियम का पालन करेगा। हमलावरों ने जल्द ही यह साबित कर दिया कि कुछ अतिरिक्त वाक्य उन नियमों को दरकिनार कर सकते हैं, जिससे मॉडल को फिर भी वही डिलीट फंक्शन कॉल करने के लिए प्रेरित किया जा सकता है।
समुदाय की पहली प्रतिक्रिया प्रॉम्प्ट भाषा को सख्त करने, "X कभी न करें" जैसे क्लॉज़ जोड़ने, या संदिग्ध टोकन को हटाने वाले regex फ़िल्टर लगाने की थी। उन उपायों ने आकस्मिक दुरुपयोग को तो कम कर दिया लेकिन उस दृढ़ विरोधी को नहीं रोका जो अनुरोध को बस फिर से लिख सकता था। मूल कारण—एक अविश्वसनीय कॉलर को विशेषाधिकार प्राप्त फंक्शन दिखाना—वही बना रहा।
कौन जीतता है, कौन हारता है
वे एंटरप्राइज़ जो प्रति-अनुरोध टूल स्कोपिंग (per-request tool scoping) अपनाते हैं, उन्हें एक स्पष्ट और लागू करने योग्य सीमा प्राप्त होती है। उनके एजेंटों को बड़े पैमाने पर तैनात किया जा सकता है बिना इस डर के कि एक गलत प्रॉम्प्ट एडमिन क्षमताओं को अनलॉक कर देगा। अनुपालन (Compliance) टीमें ऑडिट ट्रेल की भी सराहना करती हैं: मॉडल को भेजी गई फंक्शन की सूची एक ठोस आर्टिफैक्ट है जिसे लॉग और समीक्षा किया जा सकता है।
वे डेवलपर्स जो केवल प्रॉम्प्ट-आधारित सुरक्षा पर निर्भर रहते हैं, उन्हें लगातार एक बदलते लक्ष्य का सामना करना पड़ता है। उनके एजेंट परीक्षण में कार्यात्मक लग सकते हैं लेकिन वास्तविक दुनिया में समझौता किए जा सकते हैं, जिससे डेटा उल्लंघन, अनधिकृत लेनदेन या अनुपालन उल्लंघन हो सकते हैं। उल्लंघन की लागत एक गतिशील टूल लिस्ट बनाने के प्रयास से कहीं अधिक है।
प्रति-तर्क: “बेहतर प्रॉम्प्ट ही काफी हैं”
कुछ लोगों का तर्क है कि पर्याप्त इंस्ट्रक्शन इंजीनियरिंग—लेयर्ड प्रॉम्प्ट्स, सिस्टम मैसेज और ह्यूमन फीडबैक से रिइन्फोर्समेंट लर्निंग—के माध्यम से मॉडल को "न करें" (do not) क्लॉज़ का पालन करने के लिए बनाया जा सकता है। वास्तविकता यह है कि लैंग्वेज मॉडल प्रोबेबिलिस्टिक जनरेटर होते हैं; वे सबसे संभावित निरंतरता का आकलन करते हैं, न कि किसी सख्त सुरक्षा नियम का। फाइन-ट्यून्ड गार्डरेल्स के बावजूद, एक नया वाक्यांश (phrasing) बच निकल सकता है, खासकर तब जब हमलावर बिना किसी लागत के बार-बार प्रयास कर सकता है। गार्डरेल्स शोर (noise) को कम करने के लिए उपयोगी हैं, लेकिन उन्हें सुरक्षा की एकमात्र पंक्ति नहीं होना चाहिए।
आगे क्या देखें
- ऐसे फ्रेमवर्क जो टूल स्कोपिंग को फर्स्ट-क्लास API के रूप में पेश करते हैं – ऐसी नई लाइब्रेरीज़ की उम्मीद करें जो आपको प्रति-उपयोगकर्ता क्षमताओं (per-user capabilities) को घोषित करने और प्रॉम्प्ट बनने से पहले फंक्शन लिस्ट को स्वचालित रूप से छाँटने (prune) की अनुमति देंगी।
- मानकीकृत "फंक्शन मैनिफेस्ट" (function manifests) – इंडस्ट्री ग्रुप्स एक JSON स्कीमा परिभाषित कर सकते हैं जो पब्लिक और प्रिविलेज्ड फंक्शन्स को अलग करता है, जिससे रिक्वेस्ट-विशिष्ट मैनिफेस्ट बनाना आसान हो जाता है।
- रनटाइम एनफोर्समेंट (Runtime enforcement) – कुछ प्लेटफॉर्म सैंडबॉक्स्ड एक्जीक्यूशन (sandboxed execution) के साथ प्रयोग कर रहे हैं जो कॉल करने वाले के टोकन की जांच इन्वोक्ड फंक्शन के विरुद्ध करता है, जिससे प्रॉम्प्ट स्कोपिंग के अलावा सुरक्षा की एक दूसरी परत जुड़ जाती है।
निष्कर्ष स्पष्ट है: प्रॉम्प्ट इंजेक्शन को एक ऑथोराइजेशन दोष (authorization flaw) के रूप में मानें। मॉडल के टूलबॉक्स से अनधिकृत टूल्स को हटाकर, आप उस अटैक सरफेस (attack surface) को खत्म कर देते हैं जिसका फायदा एक चतुराई से लिखे गए प्रॉम्प्ट द्वारा उठाने की कोशिश की जाती है। प्रॉम्प्ट व्यवहार का मार्गदर्शन कर सकते हैं; वे उचित एक्सेस कंट्रोल (access control) का स्थान नहीं ले सकते।