मैंने एक AI एजेंट को अपने परिवार के वित्त (finances) तक पहुंच दी और उसे एक MCP सर्वर के माध्यम से मुझसे बात करने दिया। कुछ ही मिनटों में वह "पिछले महीने हमने किराने के सामान पर कितना खर्च किया?" जैसे सवालों के जवाब देने और बचत में पैसा स्थानांतरित करने में सक्षम था। उसी इंटरफ़ेस ने उसे एक ही कमांड के साथ पूरे एक साल का लेनदेन इतिहास मिटाने की अनुमति भी दी। एजेंट द्वारा कॉल किए जाने वाले टूल्स में एक हार्ड-कोडेड सुरक्षा जांच (safety check) ने इसे मिटने से रोक दिया—न कि कोई चतुर सिस्टम प्रॉम्प्ट।
यह समस्या क्यों महत्वपूर्ण है
बाहरी सेवाओं को कॉल करने वाले AI एजेंट अब रिसर्च डेमो से निकलकर रोजमर्रा के सहायकों (assistants) की ओर बढ़ रहे हैं। एक बजटिंग बॉट जो बैंक-SMS अलर्ट पढ़ता है, राशि का विश्लेषण करता है और उन्हें पर्सनल फाइनेंस ऐप में रिकॉर्ड करता है, आज मौजूद है। यही पैटर्न कस्टमर-सपोर्ट चैटबॉट्स, कोड-जेनरेशन हेल्पर्स और सप्लाई-चेन प्लानर्स को भी शक्ति देता है। एक बार जब कोई एजेंट परिवर्तनीय (mutating) या विनाशकारी (destructive) कमांड जारी कर सकता है—जैसे कोई फ़ाइल हटाना, डेटाबेस टेबल को ड्रॉप करना, या फंड को पुनर्वितरित करना—तो जोखिम बहुत बढ़ जाता है। एक गलत तरीके से समझा गया अनुरोध, मॉडल-ड्रिफ्ट (model-drift) की घटना, या एक दुर्भावनापूर्ण प्रॉम्प्ट अपूरणीय क्षति पहुंचा सकता है। 2025 में, एक AI कोडिंग असिस्टेंट ने, विनाशकारी संचालन न करने के निर्देश के बावजूद, एक प्रोडक्शन डेटाबेस को डिलीट कर दिया, जिससे कंपनी को हफ्तों का डाउनटाइम झेलना पड़ा।
जोखिम वास्तविक है। उपयोगकर्ता संवेदनशील डेटा और महत्वपूर्ण वर्कफ़्लो के लिए AI एजेंटों पर भरोसा करते हैं। जब वह भरोसा टूटता है, तो अपनाना (adoption) रुक जाता है, नियामक (regulators) हस्तक्षेप कर सकते हैं, और वित्तीय प्रभाव गंभीर हो सकता है। मुख्य प्रश्न यह है: हम यह कैसे सुनिश्चित करें कि कोई एजेंट बिना किसी वास्तविक मानवीय निर्णय के कभी भी कोई अपूरणीय (irreversible) कार्य न करे?
प्रॉम्प्ट इंजीनियरिंग सुरक्षा का एक झूठा भ्रम है
डेवलपर्स अक्सर सिस्टम प्रॉम्प्ट को सख्त करते हैं, जैसे "बिना पूछे डेटा कभी डिलीट न करें" या "बैलेंस बदलने से पहले हमेशा पुष्टि करें।" प्रॉम्प्ट इंजीनियरिंग मॉडल के व्यवहार को सुझावों के एक सेट के रूप में मानती है जिसका मॉडल पालन कर भी सकता है और नहीं भी। व्यवहार में, मॉडल शब्दों का पालन तब तक करता है जब तक कि टेम्परेचर सेटिंग्स, टोकन सीमाएं, या संदर्भ में सूक्ष्म बदलाव उन्हें नियम छोड़ने पर मजबूर नहीं कर देते। 2025 की डेटाबेस डिलीशन घटना ने साबित कर दिया कि जब मॉडल का आंतरिक तर्क (internal reasoning) अलग हो जाता है, तो स्पष्ट निर्देश को भी अनदेखा किया जा सकता है।
गद्य-स्तर (Prose-level) के प्रतिबंध रखरखाव की समस्याएँ भी पैदा करते हैं। हर नया टूल, वर्जन अपडेट, या लैंग्वेज-मॉडल परिवर्तन प्रॉम्प्ट टेक्स्ट के नए ऑडिट को अनिवार्य बना देता है। मानव समीक्षकों को प्राकृतिक भाषा के लंबे ब्लॉकों को पढ़ना, उनकी व्याख्या करना और यह उम्मीद करना पड़ता है कि मॉडल उनका सम्मान करेगा। परिणाम एक नाजुक सुरक्षा जाल है जो वास्तविक दुनिया के उपयोग में टूट जाता है।
सुरक्षा को प्रॉम्प्ट से हटाकर टूल में ले जाना
एक अधिक विश्वसनीय दृष्टिकोण सुरक्षा को वहां लागू करना है जहां AI कार्य करता है—यानी स्वयं टूल में। अपने प्रयोग में, मैंने Lester नाम का एक बजटिंग एजेंट बनाया। वर्कफ़्लो इस प्रकार था:
- एक फोन ऐप आने वाले बैंक SMS संदेशों को कैप्चर करता है।
- एक हल्का, स्थानीय रूप से होस्ट किया गया लैंग्वेज मॉडल लेनदेन की राशि और मर्चेंट का नाम निकालता है।
- Lester एक API कॉल के माध्यम से पार्स किए गए रिकॉर्ड को बजटिंग ऐप में लिखता है।
Lester के दृष्टिकोण से ये तीनों चरण रीड-ओनली (read-only) थे: वह केवल डेटा जोड़ सकता था, मौजूदा प्रविष्टियों को कभी डिलीट या संशोधित नहीं कर सकता था। सिस्टम त्रुटिहीन रूप से काम कर रहा था जब तक कि मैंने MCP (Multi-Channel Prompt) सर्वर का उपयोग करके एक वॉयस इंटरफ़ेस नहीं जोड़ा, जिसने मुझे पूछने की अनुमति दी "पिछले महीने हमने किराने के सामान पर कितना खर्च किया?" या "बचत में पैसा स्थानांतरित करें।" MCP सर्वर एक ब्रोकर के रूप में कार्य करता है, जो एजेंट को टूल्स का एक सेट (add-transaction, query-spending, transfer-funds, delete-history) प्रदान करता है।
मूल कॉन्फ़िगरेशन में प्रत्येक टूल के साथ समान व्यवहार किया जाता था। वही एंडपॉइंट जिसने किराने की एक लाइन जोड़ी थी, उसने एक डिलीट कमांड को भी स्वीकार किया जो पूरे एक साल के रिकॉर्ड को मिटा सकता था। यदि मॉडल भटक जाता, किसी अनुरोध को गलत सुन लेता, या उपयोगकर्ता ने "delete last" के बजाय "delete all" टाइप कर दिया, तो Lester बिना किसी हिचकिचाहट के उसका पालन कर देता।
इसे रोकने के लिए, मैंने तीन सरल नियमों के साथ टूल लेयर को फिर से तैयार किया:
- रीड-ओनली टूल्स तुरंत निष्पादित होते हैं। ऐसी कोई भी चीज़ जो केवल जानकारी प्राप्त करती है—बैलेंस चेक, खर्च का सारांश, लेनदेन प्रश्न—उसे मानवीय पुष्टि की आवश्यकता नहीं होती है। रीड-ओनली कॉल का जोखिम नगण्य है।
- परिवर्तनीय (Mutating) टूल्स कार्य करने से पहले इरादे (intent) की घोषणा करते हैं। वे ऑपरेशन जो स्थिति (state) बदलते हैं लेकिन जिन्हें वापस लिया जा सकता है—जैसे लेनदेन जोड़ना, श्रेणी अपडेट करना—एजेंट द्वारा एक छोटा "इरादा" संदेश भेजने के बाद आगे बढ़ते हैं (जैसे, "किराने का लेनदेन जोड़ रहा हूँ")। सिस्टम इरादे को लॉग करता है और ऑडिट के लिए उपयोगकर्ता के सामने पेश कर सकता है, लेकिन यह निष्पादन को रोकता नहीं है।
- विनाशकारी (Destructive) टूल्स स्पष्ट टोकन के बिना चलने से इनकार कर देते हैं। वे कमांड जो डेटा को डिलीट, ट्रंकेट, या किसी अन्य तरह से अप्राप्य बनाते हैं, उन्हें टूल स्तर पर ही ब्लॉक कर दिया जाता है। जब Lester एक डिलीट अनुरोध जारी करता है, तो टूल एक रिफ्यूजल पेलोड (refusal payload) लौटाता है जिसमें वह सटीक डेटा शामिल होता है जिसे वह डिलीट करता, और एक मानव-जनित टोकन के लिए अनुरोध होता है। एजेंट को फिर
confirm: trueऔर टोकन वाला एक दूसरा-चरण का पुष्टिकरण पेलोड प्रदान करना होगा। इसके बिना, ऑपरेशन रद्द हो जाता है।
यह डिज़ाइन सुरक्षा जांच को एटॉमिक (atomic) बनाता है: टूल स्वयं तय करता है कि वह आगे बढ़ सकता है या नहीं, चाहे मॉडल अपने प्रॉम्प्ट में कुछ भी कहे। भले ही मॉडल टोकन को छोड़कर या गलत पेलोड प्रदान करके जांच को बायपास करने की कोशिश करे, टूल अनुरोध को सीधे खारिज कर देता है।
यह उपयोगकर्ताओं के लिए क्यों महत्वपूर्ण है
किसी भी पुष्टिकरण योजना में सबसे बड़ी बाधा थकान (fatigue) है। यदि कोई सिस्टम हर छोटी क्रिया के लिए अनुमोदन मांगता है—“क्या आप यह कॉफी जोड़ना चाहते हैं?”—तो उपयोगकर्ता बिना पढ़े जल्दी से "हाँ" पर क्लिक करने लगते हैं। इसका परिणाम सुरक्षा की झूठी भावना है। केवल अपूरणीय (irreversible) कार्यों पर रोक लगाकर, हम मानव को ठीक वहीं रखते हैं जहाँ उसकी आवश्यकता होती है। एक उपयोगकर्ता उस अनुरोध की समीक्षा करने की बहुत अधिक संभावना रखता है जो पूरे महीने के वित्तीय इतिहास को मिटा सकता है, बजाय उसके जो केवल एक आइटम जोड़ता है।
टूल-स्तर की सुरक्षा अनुपालन (compliance) को भी सरल बनाती है। यूरोपीय संघ के AI अधिनियम (EU’s AI Act) या अमेरिकी SAFE अधिनियम जैसे नियमों के लिए अनपेक्षित डेटा हानि के खिलाफ प्रदर्शन योग्य सुरक्षा उपायों की आवश्यकता होती है। API में एक हार्ड-कोडेड इनकार एक ऑडिट योग्य नियंत्रण है जिसे तीसरे पक्ष के ऑडिटरों द्वारा लॉग, निरीक्षण और मान्य किया जा सकता है। इसके विपरीत, प्रॉम्प्ट टेक्स्ट अस्पष्ट, वर्जन-निर्भर और अदालत में साबित करना कठिन होता है।
प्रति-तर्क: "क्या हम सिर्फ प्रॉम्प्ट्स को बेहतर नहीं बना सकते?"
कुछ डेवलपर्स का तर्क है कि मानव फीडबैक से सुदृढीकरण सीखने (RLHF) के साथ मिलकर एक अच्छी तरह से तैयार किया गया प्रॉम्प्ट, सुरक्षा का वही स्तर प्राप्त कर सकता है। वे उन इंस्ट्रक्शन-ट्यून्ड (instruction-tuned) मॉडलों की ओर इशारा करते हैं जो शायद ही कभी स्पष्ट बाधाओं का उल्लंघन करते हैं। यह आपत्ति वैध है: बेहतर मॉडल आकस्मिक डिलीशन को कम करते हैं।
हालाँकि, सबसे सक्षम मॉडल भी संभाव्य (probabilistic) होते हैं। एक एकल आउटलायर टोकन, टेम्परेचर में बदलाव, या एक दुर्लभ संदर्भ संयोजन मॉडल को एक अप्रत्याशित कमांड उत्पन्न करने के लिए मजबूर कर सकता है। जो सुरक्षा सांख्यिकीय गुण (statistical property) पर निर्भर करती है, वह स्वाभाविक रूप से नाजुक होती है। उच्च-मूल्य वाले क्षेत्रों में—बैंकिंग, स्वास्थ्य सेवा, महत्वपूर्ण बुनियादी ढांचा—एक छोटी सी चूक विनाशकारी नुकसान पहुंचा सकती है। उल्लंघन की लागत प्रत्येक विनाशकारी ऑपरेशन को एक सुरक्षात्मक रैपर में लपेटने के लिए आवश्यक इंजीनियरिंग प्रयास से कहीं अधिक है।
प्रॉम्प्ट-ओनली समाधान दुर्भावनापूर्ण इरादे (malicious intent) को भी अनदेखा करते हैं। एक हमलावर जिसे एजेंट के प्रॉम्प्ट तक पहुंच प्राप्त हो जाती है, वह एक ऐसा कमांड इंजेक्ट कर सकता है जो सुरक्षा क्लॉज को छोड़ देता है। टूल-स्तर का प्रवर्तन (enforcement) इससे सुरक्षित है क्योंकि गेट मॉडल के संदर्भ (context) के बाहर रहता है।
आगे क्या देखने की आवश्यकता है
समुदाय अब टूल-स्तर की सुरक्षा को एक प्राथमिक चिंता के रूप में मानने लगा है। कई ओपन-सोर्स प्रोजेक्ट्स अब "सेफ API" प्रदान करते हैं जो मानव टोकन की कमी वाले विनाशकारी कॉल को स्वचालित रूप से अस्वीकार कर देते हैं। मानक निकाय एक्शन-लेवल कंसेंट (action-level consent) के लिए विनिर्देश (specifications) तैयार कर रहे हैं, जहाँ प्रत्येक API कॉल में एक हस्ताक्षरित इरा