Chrome ने WebMCP के लिए सुरक्षा मार्गदर्शन जोड़ा है, जो साइटों द्वारा AI एजेंटों को टूल्स दिखाने का एक नया तरीका है, और यह उन टूल्स को सुरक्षित रखने की पूरी जिम्मेदारी सीधे वेबसाइट मालिकों पर डालता है। यह मार्गदर्शन चेतावनी देता है कि कोई भी साइट जो खुद को "एजेंट-रेडी" घोषित करती है, वह तैयार किए गए मैनिफेस्ट या दूषित आउटपुट के माध्यम से दुर्भावनापूर्ण हमलावरों के लिए एजेंटों को हाईजैक करने का रास्ता भी खोल देती है।

WebMCP अब क्यों महत्वपूर्ण है

डेवलपर्स लंबे समय से पूछ रहे हैं: क्या एक AI एजेंट मेरे पेज को पढ़ सकता है और कोई ट्रांजेक्शन पूरा कर सकता है? WebMCP इस परिदृश्य को बदल देता है। एक एजेंट द्वारा यह अनुमान लगाने के बजाय कि चेकआउट कैसे काम करता है, साइट एक मैनिफेस्ट प्रकाशित करती है जो एजेंट को ठीक-ठीक बताती है कि वह कौन से कार्य कर सकता है—जैसे कीमत की जानकारी देखना, कार्ट अपडेट करना, रिव्यू प्राप्त करना, इत्यादि। इसका परिणाम एक बहुत अधिक सक्षम असिस्टेंट के रूप में मिलता है, लेकिन यह एक नया अटैक सरफेस (हमले की संभावना वाला क्षेत्र) भी बनाता है: जैसे ही कोई साइट एजेंट को कोई टूल सौंपती है, वह एजेंट को निर्देशों का एक सेट सौंप देती है जिसे बदला या गलत इस्तेमाल किया जा सकता है।

वे दो हाइजैक वेक्टर जिनसे डेवलपर्स को डरना चाहिए

Malicious manifests (दुर्भावनापूर्ण मैनिफेस्ट) – एक हमलावर टूल के नाम या विवरण में छिपे हुए कमांड इंजेक्ट कर देता है। चूंकि एजेंट टेक्स्ट की हर स्ट्रिंग को संभावित निर्देश के रूप में देखते हैं, इसलिए एक चतुराई से तैयार किया गया नाम एजेंट के मूल कार्य को ओवरराइड कर सकता है और उसे कुछ अनपेक्षित करने के लिए मजबूर कर सकता है।

Contaminated output (दूषित आउटपुट) – यह अधिक सामान्य रास्ता है। एक वैध टूल यूजर-जनरेटेड डेटा लौटाता है—जैसे प्रोडक्ट रिव्यू, फोरम पोस्ट, कमेंट्स। यदि कोई दुर्भावनापूर्ण उपयोगकर्ता उस कंटेंट में कोई कमांड डाल देता है, तो टूल उस कमांड को सीधे एजेंट तक पहुँचा देता है। लार्ज लैंग्वेज मॉडल्स (LLMs) डेटा को निर्देशों से विश्वसनीय रूप से अलग नहीं कर पाते; वे पूरे स्ट्रीम को एक ही प्रॉम्प्ट के रूप में देखते हैं।

अपने मैनिफेस्ट को सुरक्षित करने के व्यावहारिक कदम

Chrome का मार्गदर्शन तीन कॉन्फ़िगरेशन नियमों में सिमटा हुआ है जिन्हें डेवलपर्स अपने WebMCP मैनिफेस्ट फाइलों में जोड़ सकते हैं।

  • कौन आपके टूल्स का उपयोग कर सकता है, इसे सीमित करें – विश्वसनीय एजेंट प्लेटफॉर्म्स को व्हाइटलिस्ट करने के लिए exposedTo नियम का उपयोग करें। उदाहरण के लिए, एक पेमेंट-प्रोसेसिंग टूल वेब पर मौजूद हर AI एजेंट को दिखाई नहीं देना चाहिए। केवल उन्हीं सटीक ओरिजिन (origins) को परिभाषित करें जो टूल को कॉल कर सकते हैं और बाकी को अस्वीकार कर दें।

  • अविश्वसनीय सामग्री को चिह्नित करें – किसी भी ऐसे टूल में untrustedContentHint फ्लैग जोड़ें जो ऐसा डेटा लौटाता है जो यूजर द्वारा दिया जा सकता है, जैसे कि रिव्यू या कमेंट्स। यह एजेंट को बताता है कि पेलोड में दुर्भावनापूर्ण निर्देश हो सकते हैं, जिससे वह टेक्स्ट पर कार्रवाई करने से पहले सख्त सुरक्षा फिल्टर लागू करने के लिए प्रेरित होता है।

  • रीड-ओनली व्यवहार घोषित करें – readOnlyHint फ्लैग आपको यह संकेत देने की अनुमति देता है कि टूल केवल डेटा पढ़ता है या वह डेटा लिख/बदल भी सकता है। जब कोई टूल रीड-ओनली होता है, तो एजेंट बिना अतिरिक्त यूजर कन्फर्मेशन के आगे बढ़ सकता है; जब वह कुछ संशोधित कर सकता है, तो एजेंट को आगे बढ़ने से पहले यूजर से पूछना चाहिए।

डेवलपर्स किस बात का विरोध कर सकते हैं

व्यापक जोखिम

आगे क्या देखें

निष्कर्ष

किसी साइट को "एजेंट-रेडी" बनाना अब केवल दृश्यता (visibility) के लिए एक चेकबॉक्स नहीं है; यह सुरक्षा के लिए एक जिम्मेदारी है। एक्सेस को सीमित करके, अविश्वसनीय आउटपुट को फ्लैग करके, और रीड-ओनली टूल्स को स्पष्ट रूप से चिह्नित करके, डेवलपर्स हमलावरों को एक सहायक AI असिस्टेंट को दुरुपयोग के माध्यम के रूप में बदलने से रोक सकते हैं। मैनिफेस्ट के साथ किसी भी अन्य सार्वजनिक API की तरह व्यवहार करें: इसे दुनिया के सामने लाने से पहले इसका ऑडिट करें, इसका वर्जन बनाएँ और इसे सुरक्षित करें।