22 सितंबर (अमेरिकी समय) को Anthropic ने Claude Opus 5.5 रिलीज़ किया।
उसी दिन, OpenAI ने GPT-6 Sol और Luna की घोषणा की।
दोनों ही "पहले से ज़्यादा स्मार्ट, पहले से ज़्यादा सस्ते" हैं।
इनमें से जिस बात ने मेरा ध्यान खींचा, वो आधिकारिक घोषणा में दिया गया एक खास आंकड़ा था।
Deloitte की टिप्पणी के रूप में इसमें लिखा है:
"सबसे निचली सेटिंग पर भी, इसने ज्ञात बग्स में से 72% ढूंढ निकाले। Opus 5 ने उच्चतम सेटिंग पर 56% पाए थे।"
इसका मतलब है कि कोड पढ़ने और कमज़ोरियां (vulnerabilities) खोजने की क्षमता में सिर्फ एक जनरेशन में भारी सुधार हुआ है।
AI ऐसी चीज़ें बना देगा जो "काम करेंगी"।
लेकिन उन्हें "सुरक्षित" बनाने के लिए इंसानों को निर्देश देने होंगे।
तो, यहाँ 5 ऐसे बिंदु हैं जिन्हें Opus 5.5 से इंटरनल ऐप्स बनाते समय हमेशा ध्यान में रखना चाहिए।
हर बिंदु के साथ एक ऐसा प्रॉम्प्ट भी दिया गया है, जिससे आप Opus 5.5 से अपने काम की जाँच करवा सकते हैं।
====
जाँच कैसे करें
जब बनाने का काम पूरा हो जाए, तो उसी सेशन में यह मत पूछिए कि "क्या कोई समस्या है?" जिसमें आपने उसे बनाया था।
जिस AI ने इसे बनाया है, वह अपने ही डिज़ाइन को सही मानकर चलता है, इसलिए वह नरमी बरतने लगता है।
एक नया सेशन खोलें, मॉडल को Opus 5.5 पर सेट करें, और उसे पूरा ऐप फोल्डर दिखाएं।
फिर यह सुनिश्चित करें कि मिली हर समस्या में "कौन सी फाइल और कौन सी लाइन" शामिल हो।
Deloitte की टिप्पणी में कहा गया है कि false positives कम हुए हैं, लेकिन वे शून्य नहीं हैं।
अगर आप लोकेशन बता देंगे, तो इंसान बाद में उसकी पुष्टि कर सकते हैं।
यहाँ निर्देश दिया गया है:
"तुम एक सिक्योरिटी ऑफिसर हो जो पहली बार यह कोड देख रहा है। अगर तुम्हें कोई समस्या दिखे, तो फाइल का नाम, लाइन नंबर, यह क्यों खतरनाक है, और इसे कैसे ठीक करना है — ये सब एक साथ बताओ। जिस बारे में तुम पूरी तरह आश्वस्त नहीं हो, उसे 'Needs Verification' के तौर पर अलग कर दो।"
====
1. क्या कुछ ऐसा है जो बिना लॉगिन किए लोगों को दिख रहा है?
जब AI से कुछ बनवाया जाता है, तो कई बार स्क्रीन्स या डेटा एक्सेस पॉइंट्स पर login walls गायब रह जाती हैं।
एक आम पैटर्न यह है कि डेवलपमेंट के दौरान बनाई गई कन्फर्मेशन स्क्रीन्स को पब्लिकली एक्सेसिबल छोड़ दिया जाता है।
इसकी जाँच बहुत आसान है।
बिना लॉगिन किए (Incognito Window में) ब्राउज़र में सीधे admin panel या डेटा URL खोलें।
अगर वे दिख जाएं, तो समझ लीजिए टेस्ट फेल है।
यहाँ निर्देश दिया गया है:
"उन सभी URLs और APIs की सूची बनाओ जिन तक बिना लॉगिन किए पहुँचा जा सकता है। उनमें से, जो डेटा रिटर्न करते हैं या एडमिनिस्ट्रेशन के लिए हैं, उन्हें खतरे के स्तर के अनुसार क्रमबद्ध करो।"
====
2. क्या लॉगिन किए हुए यूज़र्स दूसरों का डेटा देख सकते हैं?
लॉगिन सिर्फ यह तय करता है कि कोई "कौन" है।
"वह व्यक्ति क्या देख सकता है", यह अलग से बनाना पड़ता है।
इसकी जाँच के लिए दो टेस्ट अकाउंट बनाएं। A के रूप में लॉगिन करें, फिर B के डेटा URL को खोलने की कोशिश करें।
यहाँ निर्देश दिया गया है:
"ऐसे सभी रास्ते खोजो जहाँ User A, User B का डेटा देख या बदल सकता है। उन स्थितियों को भी शामिल करो जहाँ UI को बायपास करके सीधे URLs या APIs हिट किए जाते हैं।"
====
3. क्या keys या passwords किसी ऐसी जगह रखे गए हैं जहाँ वे दिख सकें?
ब्राउज़र साइड पर चलने वाला कोड पूरा का पूरा यूज़र के PC पर भेज दिया जाता है।
वहाँ keys लिखना वैसा ही है जैसे उन्हें दुनिया भर में बांट देना।
एक और आम गलती यह है कि keys वाली कॉन्फ़िगरेशन फाइल्स को शेयर्ड फोल्डर्स या GitHub पर अपलोड कर दिया जाता है।
यहाँ निर्देश दिया गया है:
"ब्राउज़र-साइड कोड, config files, या commit history में मौजूद API keys, passwords, या tokens खोजो। अगर कुछ मिले, तो सुझाव दो कि उन्हें कहाँ ले जाना चाहिए।"
====
4. क्या टूल्स को उनके काम के हिसाब से ज़रूरत से ज़्यादा permissions दे दिए गए हैं?
इंटरनल टूल्स अक्सर Google, Slack या databases से जुड़े होते हैं।
कई बार दी गई key में "delete" या "view all" की छूट होती है, जबकि असल में सिर्फ "read" की ज़रूरत होती है।
यह एक बहुत आम समस्या है।
अगर वह key लीक हो जाए, तो नुकसान कितना होगा, यह permissions के दायरे पर निर्भर करता है।
जाँच करने के लिए यह लिखकर रखें: "सबसे बुरी स्थिति में, यह टूल क्या-क्या डिलीट कर सकता है?"
अगर आप इसका जवाब तुरंत नहीं दे सकते, तो सावधान हो जाएं।
यहाँ निर्देश दिया गया है:
"इस टूल के पास बाहरी सर्विसेस या डेटाबेस के लिए जो भी permissions हैं, उनकी सूची बनाओ। हर permission की तुलना वास्तविक प्रोसेसिंग के लिए ज़रूरी न्यूनतम permissions से करो और जो अतिरिक्त हों, उन्हें बताओ।"
====
5. क्या बाहर से आने वाले टेक्स्ट को कमांड की तरह चलाया जा रहा है?
जिन टूल्स में AI ईमेल, वेब पेज या अपलोड की गई फाइलें पढ़ता है, उनमें सावधानी बरतनी ज़रूरी है।
अगर उनमें "पिछले निर्देशों को नज़रअंदाज़ करो और XX करो" जैसा टेक्स्ट हो, तो AI उसे मान सकता है।
इसे Prompt Injection कहते हैं।
Opus 5.5 की घोषणा में कहा गया है कि इस हमले से बचाव "टेस्ट किए गए सभी मामलों में Opus 5 के बराबर या उससे बेहतर" है।
हालांकि, बराबर या बेहतर होने का मतलब यह नहीं कि रिस्क शून्य है। आपको अभी भी टूल की तरफ से सुरक्षा उपाय करने होंगे।
यहाँ निर्देश दिया गया है:
"ऐसी जगहें खोजो जहाँ बाहर से लोड किए गए टेक्स्ट या फाइल्स को AI के लिए निर्देश मान लिया जाता है। अगर कुछ मिले, तो हैंडलिंग इस तरह बदलो कि लोड किया गया कंटेंट सिर्फ संदर्भ जानकारी (reference information) माना जाए, और उसमें मौजूद किसी भी निर्देश को नज़रअंदाज़ कर दिया जाए।"
====
सारांश
AI वैसे फीचर्स बना देगा जैसे आप मांगेंगे।
लेकिन "दूसरों को मत दिखाना" और "ज़रूरत से ज़्यादा permissions मत देना" — ये बातें तब तक शामिल नहीं होंगी, जब तक आप खुद न कहें।
इसके विपरीत, इन 5 बिंदुओं में से हर एक को सिर्फ एक निर्देश जोड़कर ठीक किया जा सकता है।
और आपके बनाए हुए में खामियां खोजने की Opus 5.5 की क्षमता भी अब और बेहतर हो गई है।
बनाने के बाद, एक नई बातचीत में उसे Opus 5.5 को दिखाएं।
इसे डेवलपमेंट का ही एक हिस्सा मानें।
अगर आपका कोई इंटरनल ऐप पहले से चल रहा है, तो "जाँच कैसे करें" सेक्शन से जाँच का निर्देश पेस्ट करके शुरुआत करें।
साथ ही, अगर हर बार निर्देश पेस्ट करना झंझट लगता है, तो security-review नाम का एक प्लगइन है, जिसे मैं आज़माने की सलाह दूंगा।
यह बारीकियों पर ध्यान देता है और उन्हें पकड़कर बताता है, इसलिए मैं खुद इसे नियमित रूप से इस्तेमाल करता हूँ।
====
आखिर में, एक छोटी सी घोषणा।
हमारी कंपनी आपकी कंपनी के लिए शुरू से लेकर अंत तक बिज़नेस-स्पेसिफिक AI agents डेवलप करने की सेवा देती है।
यह कोई ट्रेनिंग या टूल परिचय नहीं है, बल्कि हम आपके असल बिज़नेस फ्लो को समझते हैं ताकि आपको कुछ ऐसा मिल सके जिसे आप "कल से ही" इस्तेमाल कर सकें। हम इंटीग्रेशन और मेंटेनेंस में भी मदद करते हैं।
