Grok पर ‘Cryptographic Context Injection’ का खतरा: साधारण वेबपेज से चैट हिस्ट्री लीक होने का दावा

Adversa AI के proof of concept में यूज़र का नाम, अनुमानित लोकेशन, subscription tier, prompts और conversation history शामिल होने की बात कही गई। कंपनी के मुताबिक, उसके प्रदर्शन में यह ट्रांसफर किसी स्पष्ट चेतावनी या पुष्टि के बिना पूरा हुआ।

असली सुरक्षा सीमा मॉडल नहीं, रनटाइम है

मुख्य समस्या सिर्फ यह नहीं है कि Grok को दुर्भावनापूर्ण prompt दिखाया गया। अधिक गंभीर बात यह है कि एक अविश्वसनीय वेबपेज से आया डेटा कथित तौर पर कई trust boundaries पार कर गया:

• वेबपेज की सामग्री executable या actionable context बन गई;
• डिक्रिप्ट किए गए output को उसके मूल स्रोत की तुलना में अधिक भरोसेमंद माना गया;
• निजी बातचीत या सेशन context हमले की श्रृंखला के लिए उपलब्ध हो गया; और
• एजेंट बाहरी अनुरोध के जरिए उस डेटा को सेशन से बाहर भेज सका।

किसी निर्देश पर केवल इसलिए भरोसा नहीं किया जा सकता कि वह decryption routine से निकला है, किसी tool ने लौटाया है या intermediate runtime result में मौजूद है। डेटा का provenance—यानी वह मूल रूप से कहां से आया—इन रूपांतरणों के बाद भी कायम रहना चाहिए। अन्यथा parsing, code execution, retrieval या tool output के जरिए अविश्वसनीय सामग्री को दिखावटी authority में बदला जा सकता है।

खुलासा कब हुआ और स्थिति क्या है?

Adversa AI के अनुसार, Utevsky ने 3 जून 2026 को xAI और HackerOne के माध्यम से इस समस्या की रिपोर्ट की थी। 20 अगस्त को प्रकाशित उसके खुलासे में कहा गया कि follow-ups के बावजूद यह समस्या दो महीने से अधिक समय तक unresolved रही।

उपलब्ध रिपोर्टिंग में उस समय xAI की ओर से कोई सार्वजनिक प्रतिक्रिया, patch, CVE identifier या remediation timetable शामिल नहीं था। यह स्थिति मुख्य रूप से शोधकर्ता के खुलासे और समकालीन रिपोर्टों पर आधारित है; यहां xAI का ऐसा स्वतंत्र रूप से प्रकाशित बयान उपलब्ध नहीं है जो इस finding या उसके remediation की पुष्टि करता हो।

किस तरह का सुधार जरूरी है?

Adversa AI की सिफारिशें नए keyword filters जोड़ने के बजाय agent runtime पर केंद्रित हैं। प्रमुख नियंत्रण ये हैं:

• Provenance और taint labels बनाए रखें। वेबपेज से आया डेटा parsing, decryption, code execution या tool use के बाद भी untrusted रहना चाहिए।
• डेटा और authority को अलग रखें। अविश्वसनीय सामग्री या उससे निकले values को privileged tools चलाने, निजी conversation context पढ़ने या संवेदनशील tool arguments तय करने की अनुमति नहीं होनी चाहिए।
• Outbound traffic सीमित करें। नए external endpoint पर जानकारी भेजने से पहले allowlists, destination controls और data-loss-prevention नीतियां लागू होनी चाहिए।
• स्पष्ट सहमति लें। निजी context या external transmission से जुड़े अनुरोधों के लिए ऐसी user confirmation जरूरी होनी चाहिए जिसमें बताया जाए कि कौन-सा डेटा, किस स्थान पर भेजा जाएगा।
• Least privilege लागू करें। केवल सारांश बनाने के काम से full chat history, profile metadata, code execution या unrestricted network access अपने-आप नहीं मिलना चाहिए।

ये उपाय untrusted input, private context, code execution और action-capable tools के खतरनाक मेल को संबोधित करते हैं। केवल मॉडल का refusal behavior पर्याप्त security boundary नहीं है।

दूसरे AI-agent हमलों से तुलना

Grok से जुड़ी यह रिपोर्ट उस व्यापक पैटर्न का हिस्सा है जिसमें हमलावर उस सामग्री को प्रभावित करते हैं जिसे एजेंट प्रोसेस करने वाला है और फिर एजेंट की वैध permissions का इस्तेमाल हमले को पूरा करने के लिए करते हैं।

Microsoft 365 Copilot के EchoLeak को zero-click prompt-injection vulnerability के रूप में बताया गया था। इसमें तैयार किया गया ईमेल असिस्टेंट के लिए उपलब्ध डेटा को remote, unauthenticated तरीके से बाहर भेजने में मदद कर सकता था। एक academic case study में इसे CVE-2025-32711 के रूप में पहचाना गया है।

Microsoft Copilot Personal पर अलग रिपोर्टिंग में CoSnitch श्रृंखला का वर्णन किया गया, जिसमें crafted link के जरिए prompt execution शुरू होकर connected applications से डेटा exfiltration हो सकती थी। शोधकर्ताओं के अनुसार, Microsoft ने 18 अगस्त 2026 को patches जारी किए।

Coding agents में भी इसी तरह का जोखिम वेबपेज के बजाय repositories के जरिए सामने आता है। Adversa AI ने बताया कि malicious repositories कई coding assistants—जिनमें Claude Code, Cursor CLI, Gemini CLI और Copilot CLI शामिल हैं—के trust और configuration behavior का फायदा उठाकर संभावित रूप से व्यापक privileges वाले attacker-controlled MCP servers चला सकती हैं। Adversa AI की एक अन्य रिपोर्ट में लंबे shell-command chains के जरिए repository-based policy bypass और credentials या secrets की संभावित चोरी का वर्णन किया गया।

Delivery mechanism अलग हो सकता है—ईमेल, URL, दस्तावेज़, repository, encrypted webpage या tool integration—लेकिन architectural lesson एक ही है: एजेंट को हमलावर-नियंत्रित सामग्री को confidential data पढ़ने या बाहरी कार्रवाई करने की अनुमति में नहीं बदलना चाहिए।

व्यापक सुरक्षा सबक

Cryptographic Context Injection दिखाता है कि agent security केवल उस टेक्स्ट को स्कैन करके पूरी नहीं हो सकती जो सबसे पहले context window में आता है। एजेंट को निर्देश decryption, retrieval, parsing, code execution, memory access या किसी अन्य tool call के बाद भी मिल सकते हैं। यदि हर transformation के दौरान डेटा का मूल स्रोत खो जाता है, तो हमलावर उस अंतर का फायदा उठा सकता है कि सिस्टम किसे untrusted मानता है और runtime बाद में किसे trusted समझ लेता है।

यूज़र्स के लिए व्यावहारिक सबक यह है कि निजी बातचीत या टूल्स तक पहुंच रखने वाले एजेंट से अपरिचित webpages, documents, links या repositories प्रोसेस करवाते समय सावधानी बरतें। डेवलपर्स के लिए प्राथमिकता और स्पष्ट है: runtime में trust boundaries लागू करें, sensitive context तक पहुंच सीमित करें, tool parameters को constrain करें, network egress नियंत्रित करें और high-impact actions को स्पष्ट व confirmable बनाएं।

इसलिए Grok की रिपोर्ट की गई तकनीक को “AES तोड़ने” के रूप में नहीं, बल्कि authority laundering की चेतावनी के रूप में समझना बेहतर है। एन्क्रिप्टेड सामग्री किसी filter से निर्देश छिपा सकती है, लेकिन उस छिपे निर्देश को data-theft action में बदलने के लिए permissive agent runtime की जरूरत होती है।