Word के लिए Copilot के माध्यम से दस्तावेज़-जनित AI वर्म स्वयं-प्रसारित हो सकते हैं

एक समन्वित vulnerability disclosure दिखाता है कि Word दस्तावेज़ों के भीतर छिपे हमलावर-लिखित prompts Microsoft Copilot को कैसे हाईजैक कर सकते हैं, सामग्री को चुपचाप बदल सकते हैं (जैसे वित्तीय आँकड़े), और स्वयं को नए बनाए गए दस्तावेज़ों में “AI worms” के रूप में फैला सकते हैं। टिप्पणीकार इसे उस व्यापक, अनसुलझी समस्या से जोड़ते हैं कि वर्तमान large language models निर्देशों और डेटा के बीच विश्वसनीय रूप से अंतर नहीं कर सकते, जिससे वे partial mitigations के बावजूद prompt-injection-style attacks के प्रति स्वाभाविक रूप से संवेदनशील हैं। थ्रेड ऑफिस सूट और operating systems में ऐसे agents को गहराई से embed करने को लेकर चिंताओं तक फैलता है, यह तर्क देते हुए कि मज़बूत architectural और process safeguards के बिना, संगठनों को बड़े पैमाने पर, कठिन-से-पकड़े जाने वाले document tampering का जोखिम है.

कमज़ोरी और व्यवहार

  • थ्रेड इस बात से सहमत है कि Word/Copilot की समस्या एक वास्तविक कमज़ोरी वर्ग है: दस्तावेज़-जनित प्रॉम्प्ट संपादन को हाईजैक कर सकते हैं, सामग्री (जैसे संख्याएँ) बदल सकते हैं, और छिपे हुए पेलोड डाल सकते हैं जो नए दस्तावेज़ों में फैल जाते हैं।
  • कई लोग नोट करते हैं कि Microsoft ने आंशिक mitigations जोड़े हैं, लेकिन प्रतिभागी बार-बार इस बात पर ज़ोर देते हैं कि सामान्य समस्या—LLMs का संदर्भ में हमलावर-प्रदत्त निर्देशों को निष्पादित करना—अभी भी अनसुलझी है।

निर्देश बनाम डेटा बहस

  • कई लोग इसे पुराने “code और data को कभी mix न करो” वाले सबक (SQL injection, macro viruses, in-band signaling) का AI रूप में लौटना मानते हैं।
  • अन्य तर्क देते हैं कि “code बनाम data” एक कृत्रिम, संदर्भ-निर्भर विभाजन है; सामान्य प्रणालियाँ और मानवीय संज्ञान वास्तव में इसका सम्मान नहीं करते।
  • एक मज़बूत प्रतिवाद: LLMs के ऊपर बने applications के लिए, आपको system level पर separation लागू करनी ही होगी या critical tasks के लिए इस approach को छोड़ना होगा।

छिपा हुआ टेक्स्ट और दस्तावेज़ हैंडलिंग

  • इस पर चर्चा होती है कि “hidden” content कैसे दिखाई देती है: सफ़ेद पर सफ़ेद टेक्स्ट, बहुत छोटे fonts, पेज के बाहर टेक्स्ट, images से ढका हुआ, headers/footers/comments, यहाँ तक कि metadata भी।
  • कुछ लोग render-to-image और visibility checks का सुझाव देते हैं, या model को भेजने से पहले कम-दृश्यता वाले टेक्स्ट को strip/flag करने की बात करते हैं। अन्य लोग नोट करते हैं कि यह जटिल, महँगा, और फिर भी bypassable है।

पिछले वर्म्स और वायरस से तुलना

  • कई लोग इसे 1990s–2000s के macro/VBScript worms से जोड़ते हैं, लेकिन एक मोड़ के साथ: worm payload “improvise” कर सकता है और अलग-अलग LLMs द्वारा imperfectly copy किए जाने पर संभावित रूप से evolve कर सकता है।
  • पहले के academic AI worms का भी उल्लेख होता है; इसे mainstream productivity software में इस तरह की पहली घटनाओं में से एक माना जाता है।

Mitigations और सिस्टम डिज़ाइन

  • सुझाए गए बचाव: untrusted document content को agents में न डालें; LLMs को untrusted human operators की तरह मानें; tools को sandbox करें; शक्तिशाली actions के लिए स्पष्ट human approval लें; local OS-level agents से बचें।
  • कुछ लोग multi-agent या classifier “firewall” डिज़ाइनों की ओर इशारा करते हैं, लेकिन नोट करते हैं कि वे अभी भी नाज़ुक हैं और circumvention-prone हैं।

मानवीय उपमाएँ और जोखिम-धारणा

  • एक पक्ष कहता है कि prompt injection मूलतः मनुष्यों के खिलाफ social engineering जैसा है; आप perfect immunity खोजने के बजाय blast radius सीमित करते हैं।
  • दूसरा पक्ष तर्क देता है कि LLMs uniquely vulnerable हैं (opaque payloads, scale, accountability की कमी) और मनुष्यों की तुलना में exploit करना बहुत आसान है।

व्यापक प्रतिक्रियाएँ

  • स्वर alarmed (“LLMs as reckless toddlers with bash access”) से लेकर corporate incentives और user apathy पर resigned cynicism तक जाता है।
  • कुछ लोग उम्मीद करते हैं कि दिखने वाले harms संगठनों को deeply embedded AI agents को सीमित या प्रतिबंधित करने के लिए मजबूर करेंगे; अन्य लोगों को संदेह है कि यह जल्द होगा।